Один из каналов…

...которые я читаю – это канал Артём Харченков | IT Инсайты от, кто бы мог подумать, Артёма Харченкова, руководителя команды разработки.

Во-первых, просто потому, что могу.

Во-вторых, общение с управленцами среднего звена – составная часть моей профессиональной деятельности. Поэтому мне нужно и важно понимать, как они решают рабочие задачи, какой у них подход к управлению людьми, что их беспокоит, а что радует итдитп. Тут, кстати, может возникнуть вопрос: «А разве C-Level общается с тимлидами? Зачем ему это? Он же ж с директорами департаментов только?» Да, общается. Поставьте каких-нибудь положительных реакций к этому посту, если хотите узнать, как, почему и с какой целью 😉

В-третьих, Артём хорошо пишет – умеет, знает, практикует. И почитать приятно написанное по интересным мне темам – отдельное удовольствие. Особенно, в случае, если ты в какой-то конкретной теме экспертом не являешься и хочешь углубить своё понимание вопроса. Либо же, наоборот: глубоко её понимая, получаешь возможность посмотреть на что-то тебе до боли знакомое свежим взглядом под другим углом.

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

– Нравится vs получается. Познавательная история из личного опыта Артёма, очень мне отзывается: подобные дилеммы передо мной стояли много раз. Правда, выбор в сторону «получается» я делал не всегда.

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

– Неожиданное про использование методик из книги «Общаться с ребёнком. Как?» в управлении командой. Давно, кстати, хотел её прочитать – вот и повод.

P.S. А ещё у Артёма бывают репосты интересного из других каналов, что позволяет минимизировать число подписок. О. Оптимизация. Которую мы, безусловно, заслужили

Italian IT Cuisine

Перед праздником и длительными выходными невозможно не затронуть гастрономическую тему. Извольте улыбнуться-с.

(Подушню) но фактологически картинка, конечно, полная ерунда, ибо её автор, очевидно, исходит из двух неверных постулатов:

– раньше-то никто в архитектуру и написание ПО не умел, не то, что сейчас;
– микросервисы лучше, чем немикросервисы.

И по рынку бегают толпы технических менеджеров с точно таким же майндсетом. Которые то ли забыли, то ли не знали, что микросервисный подход – всего лишь один из инструментов со своими достоинствами, недостатками, ограничениями и областью применения. Вместо взвешенной оценки и выбора подходящего инструмента они, ничтоже сумняшеся, в любой ситуации переводят монолит на микросервисы.

Максимально осуждаем

Особенности рынка труда

Казалось бы: ну как можно в нерабочий день постить что-то о работе? Нельзя, но если смешное, то можно. Плюс у нас здесь же интернациональная тусовочка, и не все следуют производственному календарю РФ на 2025 год.

В общем, особенности молдавского рынка труда: отдельно можно отобрать вакансии, где за работу будут даже платить. Зря я смеялся над отечественными кадровиками, добавляющими в описание вакансий для работных сайтов «молодой дружелюбный коллектив», «комфортное рабочее место, оборудованное всем необходимым» и «зарплата два раза в месяц».

Можно было короче: «с зарплатой»

И в продолжение субботней темы с внедрением современных технологий в образование. Как детское, так и юношеское и уже даже почти взрослое.

Статья, актуальность которой со времени её публикации (конец 2022 года) лишь возросла. Ибо ряд тезисов, которые на момент написания могли казаться либо преувеличением, либо в принципе спорными, получили подтверждение с течением времени.

Вытащена мною из вчерашних комментариев для воскресного душеспасительного чтения

Потихоньку приходим в себя после майских праздников.

Ура, на работу! Да здравствует понедельник!

На прошлой неделе мы поулыбались над забавной картинкой, в которой через кулинарную метафору прослеживается тридцатилетняя эволюция программных архитектур. Картинка заканчивается вопросом: «Что дальше?» Мыслями по теме с нами делятся итальянские эксперты. Их статью (не новая, но актуальная как никогда) я перевёл для публичного порицания 😂 Приятного чтения!

Каким бы ни был ответ, проблема не технологическая: она заключается в преодолении разрыва между теоретическими моделями и повседневной практикой. Подавляющее большинство программных систем, несмотря на распространение множества архитектурных стилей и специфических паттернов, сегодня по-прежнему недокументированы, недостаточно протестированы и не имеют эталонной архитектуры (а часто даже явного дизайна). Хуже всего то, что такая ситуация прослеживается не только в legacy-проектах, но и в новых! Из этого следует, что основная проблема лежит в плоскости культуры и проистекает из того, как мы относимся к программному обеспечению и профессионалам, которые его создают.

В корпоративных реалиях ПО рассматривается как commodity, своего рода сырье, которое покупается оптом. Либо полуфабрикат для производства конечного продукта, как будто речь идёт о сборке журнального столика. Товар. При наличии «правильных инструкций» вы просто возьмёте любого рабочего и получите тот же результат. Если нужно установить бойлер – вызывают сантехника. Какого сантехника вызвать, будет зависеть от его стоимости и местонахождения, а не от его навыков. Почему? Потому что предполагается, что все сантехники обладают одинаковыми навыками. В определённой степени они взаимозаменяемы.

К ПО подобный подход неприменим. Программное обеспечение – это продукт когнитивной деятельности. Два разных человека с одинаковыми техническими навыками имеют разные навыки решения проблем и по-разному работающее абстрактное мышление. Они думают по-разному. Они строят разные ментальные модели. И пишут на основе этих ментальных моделей разное ПО. Два разработчика никогда не бывают полностью взаимозаменяемыми. Человеческий фактор в разработке программного обеспечения имеет решающее значение, гораздо большее, чем в других областях.

Также наряду с разработчиком в создании ПО принимают участие и другие роли: аналитик или архитектор. Или менеджер проектов с соответствующим образованием. Если не понимать природы программного обеспечения, то получится «как всегда». Аналитиком не может быть «программист на пенсии», также, как недостаточно быть экспертом в доменной области, чтобы стать аналитиком.

Культурологическая проблема. С одной стороны, компании, а с другой – образование: в ВУЗах, на профессиональных курсах. Если компании будут продолжать рассматривать программное обеспечение как сырье, как чистые расходы, которые нужно сократить, то большинство усилий по управлению сложностью систем будут обречены на провал.

Программное обеспечение – не товар. Программное обеспечение – это asset, актив. Процессы разработки должны быть основаны на этом, стимулируя разработчиков работать над архитектурой и дизайном. Документированными. Обсуждаемыми и разделяемыми. Переведёнными в код. Переведёнными в автоматизированные тесты. Если рассуждать от обратного, то в этой позиции легко увидеть явные отсылки к технике Domain-Driven Design. Но это только часть истории. Другая часть – мы должны признать необходимость ролей архитекторов, аналитиков, тестировщиков, руководителей проекта, техписов... Это не просто вопрос ресурсов – это прежде всего вопрос зрелости индустрии.

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

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