DevSecOps или задача трех тел
Если совершенно случайно в вашей работе возникают критические ошибки на проде, которые исправляются слишком долго. А еще, возможно, специалисты по безопасности начинают выявлять уязвимости только после релиза. Или вдруг в команде используются ручные проверки, например: сборки кода выгружаются вручную, а ИБ их «бесконечно долго» сканируют и отдают вместе со своим рукописным отчетом.Эта статья по мотивам моего доклада
Технический дизайн
Эта статья будет полезна как разработчикам, так и менеджерам. Если вы представляете большую компанию с неограниченным бюджетом, возможно, она вам не пригодится.В погоне за продуктивностью часто создаются «гибкие» системы, гибкость которых на деле оказывается иллюзорной. В результате возникают простои, необходимость переделывать свеженаписанный код, а также искать и исправлять баги. При этом такие системы не освобождают нас от необходимости оставлять после себя структурированные артефакты в виде верхнеуровневой документации.
Избегайте эффекта якоря при оценке задач
Был ли у вас хоть раз в жизни подобный диалог с начальником или тимлидом?Тимлид: {name}, за сколько времени сделаешь эту задачу? За неделю успеешь?Я: Да. Может быть, чуть больше — ещё тестами надо покрыть. Дней десять, наверное.В итоге вы делаете задачу месяц.У меня такое случалось не раз. И я всегда восхищался людьми, которые могут сразу сказать: «Какая неделя? Здесь работы минимум на месяц».
