Обнаружил в своем календаре встречу по поводу согласования выделения денег на разработку графика разработки технического задания на разработку продукта.
WE NEED TO GO DEEPEER

https://habr.com/ru/articles/825880/

Когда я был юн, я ненавидел архитектурное проектирование и документацию, и считал единым источником правды код. Если вы знакомы с мемом в заголовке статьи, то конечно же знаете, к чему это привело меня в конечном счете.
Эта история про то, как я пришел к необходимости процесса обязательного технического анализа по задачам для программистов.

Верите ли вы в то, что бывают люди, у которых каша в голове?

Все вендоры западные ушли.
А вот этот израильский вендор решений кибербеза, VPN, фаерволлов и прочего остался.
Наверное они там смелые парни, не боятся санкций, за свободу предпринимательства. Других объяснений быть не может

48 причин, почему вендора средств защиты информации не спешат предлагать клиентам требуемые ФСТЭК с 1 января 2026 года средства защиты информации, работающие на отечественных процессорах.
Причина номер 26: нет никаких отечественных процессоров

Когда я слышу баззворды. типа «гибко» я всегда напрягаюсь.

И вот очередной случай. По мнению одной из команд, зашить во фронт их проекта ИД свойства, который выводится на мнемосхему, и точно так же зашить формулу вычисления этого свойства в бек — это гибко, в противоположность тому, чтобы загружать данные из свойства объектной модели (где это настраивалось бы в low code внедренцами).

Со своей точки зрения они правы. Потому что это гибко для их команды, они могут легко вносить изменения

Ну думаю все уже в курсе, что дело не в DNS, а в антивирусе .

Дежурное напоминание, что антивирусы вредны :-)

Интересно, что в индустрии мы знаем, как правильно делать, просто выдумываем себе причины этого не делать.
Мы знаем, чтобы создать продукты, нужны исследования, эксперименты, прототипы, говорить с пользователями и заказчиками.
Вместо этого надеемся, что они сами собой появятся из достаточного объема контрактной разработки.

Мы знаем, что РП с небольшой зарплатой и опытом не могут управлять сложнейшими проектами или организовать работу серьезной команды, но все таки будем держать их вилку кратно ниже, чем у разработчиков.

Мы знаем, что не иметь автоматизированных тестов для продукта это путь к плохому качеству и большим расходам, но все же придумываем причины их не писать.

Нам известно, что недоинвестирование в DevOps или тулинг для разработчиков обходится кратными расходами рабочего времени дорогостоящих спецов, но все же сейчас на это денег нет.

Могу продолжать, кажется, без конца.

Какой еще нужно вынести урок из истории Crowdstrike?
Как правильно валидировать данные.
Спойлер: валидировать данные — не правильно.
Классическая статья на эту тему
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

Буквально xkcd как есть.
Каждый баг — чья-то фича.

https://t.me/alice_yndx/1118

Алиса научилась лучше различать детскую речь, и то дисциплинирующее влияние на дикцию, которая она оказывала на старшую дочь «давай старайся иначе Алиса сказку не включит», на младшую больше не оказывает. Стараться не надо, Алиса и так поймет.

За первые 3.5 года в ЦИП мы почти убедили всех, что говорить «проект и продукт это по сути одно и то же, можно воспринимать продуктовое развитие как частный случай проекта» — это харам.
Возможно за следующие 3.5 года удастся убедить, что дублирование функционала (и как следствие — кода) не только вредно, но и чрезвычайно полезно.

Придумали удачное название канала, который мог бы вести какой-то популярный руководитель проектов.
«Смекалочка и подлог».

Интересно, как строится разговор между производством и коммерсантами.
Коммерсанты типично отвечают на наши просьбы «понимаем, что компании нужно больше денег, но мы берем на себя обязательства по плану продаж и их выполняем, больше продавать не можем».
Мы отвечаем «понимаем, что нужно больше фич, но у нас есть определенная capacity, больше делать не можем».

Решение кроется в том, чтобы делать не все фичи, а только полезные клиентам, закрывающие их потребность и приносящие большие продажи.
Дело за малым: узнать, какие это фичи.

Статья Александра Поломодова «как нанимать технических руководителей».
https://tellmeabout.tech/how-to-hire-technical-managers-dba01d91a6f2 (забаненный медиум)
https://www.youtube.com/watch?v=PxwCg_4HjLk (пока не забанненый ютуб)
Копия статьи в PDF

Из обсуждений в одном чате выяснилось, что некоторые люди не знают, что exactly once джобов не бывает

Бывают стораджи, которые выглядят так, как будто в них что-то записали exactly once.

Как понять что у вас проблемы с процессами

«В качестве нового бизнеса мы откроем разработку и внедрение красных линий.
Мы большие специалисты в их проведении и переносе.
А в России на них большой спрос.
Опять же в Иран продадим»

https://habr.com/ru/companies/kuper/articles/833474/

Можно наслаждаться тем, как в комментариях рвет происходит культурный шок между разными культурами.

Хочу сказать, что в культуре самонаводящихся инженеров мы действительно перекладываем на инженеров часть обязанностей менеджмента. И получаем, что нам нужно значительно меньше менеджеров. Следовательно, мы можем себе позволить нанимать значительно более дорогостоящих менеджеров с техническим бекграундом.
Получаем культуру дорогих инженеров (и самое печальное — многомесячного их поиска), дорогих их руководителей (вырастающих не из руководителей проектов, а из тимлидов).

Перекладывая коммуникационные и фасилитационные обязанности на прослойку менеджеров, мы получаем кучу плюсов в виде возможности более широкого найма (инженеров, которые отказываются смотреть за рамки своей задачи, найти гораздо проще чем, «самонаводящихся», а менеджеры, которые способны фасилитировать и не проебывать задачи — гораздо дешевле дорогостоящих руководителей с техническим бекграундом). Одновременно мы способны этой прослойкой изолировать инженеров от токсичной бюрократии, если она есть в нашей компании. Это дешевое и надежное решение.

Минусы наличия прослойки менеджеров также достаточно широки:
1. Непродуктивные затраты времени из-за коммуникаций не по делу (типичные получасовые встречи, где менеджеры просто запугивают друг друга приоритетностью и важностью своих задач, вместо разговора по делу, «я встречусь со своим менеджером и объясню ему, что написать в задаче»).
2. Отчуждение от результатов работы (инженеры, которым говорят «позволь управлять своим беклогом менеджеру», быстро приучаются не думать и делать то, что он просит, а также быстро выучивают беспомощность в борьбе с техническим долгом)
3. Некомпетентность менеджеров в оценке хард скиллов подчиненных приводит к необходимости выстраивания параллельной иерархии компетентных в этой оценке ресурсных руководителей, размывая по всей цепочке ответственность за качество