У меня часто бывает, что инфолента подсовывает что-то связанное с тем, что у меня сейчас в голове "основным тредом" работает.
Так вот ко вчерашнему про "мало что меняется" подлезла статья 91 Ways to become the Coolest Developer in the World (2011 год)
Верю, что до конца даже доскролить тяжело, а уж если пройти глянуть по кросс-ссылкам, так вообще работа на неделю минимум.
Но там практически все применимо до сих пор. Возможно какие-то моменты требуется привести к реалиям современности, но по-прежнему вполне юзабельно.

Из того же времени мой творческий "перевод" "Простые правила хорошего разработчика". Там покороче, да и советы такие, лайтовые, от КО. Но самый главный и важный - "Внимание к деталям и уважение", никогда про него не забывайте.
#байки #it_философия #развитие

Эмоции на работе добро и зло одновременно. Они поддерживают твои мысли и они же не дают донести мысли ясно и доходчиво, если эмоций через край.
От чего у меня частенько "перегорает" эмоциональный предохранитель и эмоции начинают мешать?
Фразы-триггеры:
• "за качество отвечают тестировщики"
• "это зона ответственности команды Б" (любимое - "это к девопсам")
• "это копеечная фича" (речь про стоимость реализации, но что забавно, часто это же означает, что фича еще и бесполезная. И "реализация" в оценке заканчивается только оценкой кол-ва изменений в коде, без тестирования и поддержки)
• "а мы думали, что все на вашей стороне и ждали вашего ответа"
• "завтра все будет готово" (уже неделю как)
 • теоретические выкладки, вместо ответа на заданный вопрос

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

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

Performance Review
Одна из тех областей из сферы работы со своими сотрудниками, с которой у меня было меньше всего опыта: так как-то получалось, что или этот процесс был скорее формальностью, или его вообще не было. Особенно по отношению ко мне: обычно оно появлялось в той или иной форме в тот момент, когда я уже был на позиции для которой это вообще не проводилось, или для которой оно малополезно (так как быть “выше” - это уже только в рамках другой компании, а мое саморевью всегда было “жестче” того, что мне “отдавали”).
Но вот для сотрудников должно быть полезно, хотя зависит от формата проведения, затрачиваемого времени и в целом выстроенного процесса взаимодействия. Если обратная связь дается, а развитие обсуждается, только в рамках годового PerfReview - то хрень это, а не правильная работа с сотрудником.

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

Особенно в контексте смещения в сторону “внутренней big data” как входных артефактов PerfReview. Кстати, есть много вопросов и про индивидуальные ревью, потому что в основном результаты достигаются командной работой.

#management #процессы #развитие

Закроем финишным лаком историю Performance Review.
Вчера копал тему с метриками, которые можно попробовать "натянуть" на индивидуальную работу.
Ничего нового интересного, кроме давно известного и уже тут обсуждавшегося SPACE (+ ссылка на комменты) не нашел.

Зато нашел шпаргалки красивых формулировок для ревью :)
"45 Time Management Performance Review Phrases To Use"
И вопросы для самооценки "33 Self-Evaluation Questions (Plus How To Make Your Self-Evaluation Meaningful)"

#management #процессы #развитие

Интересное из комментов про шпаргалки для самооценки.
"люди, которые саморазвиваются - большую часть из этого делают неосознанно"
Согласен.
Но также они же:
"да я ничего такого и не сделал, все по работе"
"Ничего выдающегося"
"Все в рамках ожидаемого"
Именно поэтому такие шпаргалки полезны: они помогают взглянуть на свою работу с другого ракурса. Ну и в этом месте задача менеджера тоже подсвечивать эти моменты.

Микросервисы: очередной пример "256 оттенков серого".
Все по-настоящему "микросервисно" сложно, в какой-то степени дорого. Монолит (а скорее его экстремум в виде "Big Ball of Mud") - аналогично.
Всегда нужно искать середину и понимать что и для чего ты делаешь.
PS никто еще, вслед за AWS, не начал "монолитизировать" микросервисы, леча проблемы "микроминиатюризации"?

The False Dichotomy of Monolith vs. Microservices

#tech_read

"IT индустрия - это единственная производственность во всем мире, где с костылями мы становимся быстрее" (с) Максим Дорофеев
Не согласен. Просто сейчас делаю ремонт в квартире... И там... О-оо, просто эпических размеров поле для костыльного творчества.
Очень много зависит от тех, кто делает, какой бюджет и сроки.
Все по классике проектного треугольника.
Просто в IT мы чаще релизимся и типа переделывать проще, мы же software 😉
PS где-то в это время всплакнул разработчик глядя на 10-летние артефакты своего (а скорее чужого) творчества.
#байки #мысли_вслух

Копеечная фича (которую решили добавить перед релизом)
#it_memes

Нужны ли менеджеры в IT в принципе и если да, то сколько?
Лет 7 и еще чуть-чуть назад, на одном из митапов была рассказана история про IT-компанию без менеджеров. К тому моменту ей было уже 8 лет. И действительно, в компании все это время не было менеджеров, а компания при этом успешно развивалась.
Но продолжая свое развитие и реализуя амбициозные планы пришли в точку, когда без них уже было никак. Проблема была в том, что в культуру было плотно вплетена история “нам не нужны менеджеры” а руководство приняв решение о том, что они должны таки появиться, не озаботилось трансформацией “мировозрения” переложив это на плечи новоиспеченных менеджеров. Забавная была история.
И теперь, когда я слышу “нам не нужны менеджеры”, где-то в боку начинает колоть.
Но зато, теперь я точно понимаю, для чего они таки нужны.

PS Кстати, с тестировщиками у меня была аналогичная история… Не опыт, а сплошные эксперименты.

• Questionable Advice: “My boss says we don’t need any engineering managers. Is he right?”
• How many direct reports should a manager have?

#management #байки

Забавно, но какие-то достаточно полезные штуки в разработке узнаешь или видишь инфу про них очень редко. Ну то есть статей про микросервисы, архитектуру и тдтп мелькает море. А про способы выработки и фиксации решений мало инфы. Допускаю, что это "особенности" моей инфоленты.
Но, например, про то, что RFC - это не только про описание каких-то стандартов/протоколов и тп, я узнал, только в апреле прошлого года 🙂
А между тем, RFC и ADR - очень полезные практики (часто в своем применении замещающие друг друга и сильно похожие), которые, к сожалению, редко мне встречались в жизни.
Выработка решения, его фиксация, передачи знаний о том, как та или иная фича появилась/была реализована - все это про них.
• RFC best practices
• Architecture decision record (ADR)
• A thorough team guide to RFCs
• ADRs as a decision-making tool like RFCs
• How to Write Requests for Comments (RFCs) and Architecture Decision Reviews (ADRs)
• Scaling Engineering Teams via RFCs: Writing Things Down

#процессы

Умели же раньше в "много букв", которые и читать при этом нескучно.
"Регрессионный рай и ад"
"...страшный сон тестировщика, когда над нами стоит разгневанное высокое начальство и говорит: "Это работало, а теперь не работает. Почему вы это не протестировали? Вы же должны заниматься регресионными тестами!". А он же проверил все места где случались изменения! Сделал умно и правильно! И случилась какая-то мистика и сломалось там, где не должно было ломаться!
И бедный тестировщик такой: 🥹
И просыпается..."
Хороший текст про регрессионные тесты.

#testing #классика

Принес я вам сегодня чужую мудрость, такой прямо прет поделиться.

"Садись к огоньку, юный манагер. Я расскажу тебе историю. Она будет в меру поучительна, если ты уловишь смысл. Если не уловишь, то хотя бы развлечешься. Тебе понадобиться хорошее настроение, юный манагер. Твой путь будет сложен. На нем тебе встретятся странные люди. Ты даже потеряешь веру в либеральные принципы управления. Все, юный манагер, чему тебя учили, окажется лажей. Жизнь проще и жестче. Поэтому садись, садись рядом. Выкини ты эти книги. Выброси конспекты. Я расскажу тебе как будет. Всю правду, без прикрас. И начнем мы с «человека под фонарем». Что, ты не знаешь кто это? Не удивительно. Хотя это будет твоим первым и главным испытанием. Пройдешь «человека под фонарем» – станешь настоящим манагером. Может быть..."

Читайте дальше

Какая чудесная метафора: "человек под фонарем".
У меня тоже есть похожая, но сильно грубее. Как-нибудь попозже расскажу.
ЗЫ вообще Дмитрий очень красиво пишет, завидую. Были мысли попробовать писать так же, но лень победила :)
#management

Сегодня не традиционно-разгрузочный пятничный мем, а философский.
Картина называется "Подводя итоги..."
#it_memes

Меня тут иногда спрашивают вопросы формата "а что делать если..."
Хорошо, когда в статье, уже есть готовая инструкция о сложном:
How To Fix Broken Teams

#management

“Хороший тестировщик имеет сердце разработчика…”
...
“…в банке на своем столе”

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

#testing

Опытный менеджер оценивает сложность задачи по степени нытья команды, анализируя громкость, продолжительность и тональность, что в свою очередь трансформируется в продолжительность реализации, стоимость и риски по задаче.

#management #мысли_вслух

Вопросы из комментов:
• Что делать с "человеком под фонарем"?

1. Сделать эту проблему (если вы ее видите, как проблему) прозрачной и понятной для сотрудника
2. Убедиться в том, что он разделяет твою точку зрения
3. 95% сделано ✅
4. Дальше работаем по хештегу #развитие и совместно с сотрудником "делаем фонарь встроенным в его голову"

• "А как убедиться, что проблема действительно прозрачна и понятна для сотрудника, а не он просто дакает, что понимает её, чтобы от него отстали?
И второй вопрос: а если дакает, но не разделяет?"

Если он продолжает делать то, что обсуждалось, как желаемое к исправлению, то это повод к дальнейшему обсуждению. Скорее всего неоднократному. 🙂

И если он снова "да"-кает, то ты оцениваешь риски, взвешиваешь +/- и принимаешь решение по формуле "менять людей нельзя надо менять людей" 😏
Допускаю, что звучит очень прямолинейно и жестко.
Но все дело в волшебных пузырьках в рисках и +/-.
Это и есть основная работа менеджера: получить информацию, собрать контекст, его обработать и принимать решения.
Риски всегда будут разные и иногда приходится принимать компромиссные решения. Не всегда они будут правильными и помогут на периоде времени. Но у всех же есть право на ошибку. Важно уметь ее признавать и идти исправлять.

Дополнительно к работе по убеждению можно привлечь стороннего, но уважаемого сотрудником человека или ресурса.
Допускаю, что твой авторитет менеджера (а скорее твоя самооценка) в этом случае страдает, но мне обычно важен результат.

#ваши_вопросы #management #развитие

Не мемный пост, хотя и пятничный.
Я человек обычно достаточно прямолинейный и честный. Иногда (часто?) это выходит боком, но какой есть.
И афоризмы у меня такие же обычно. Те кто со мной уже давно по работе могут помнить знаменитые “натянуть презерватив на кактус” как пример выполненной, но бесполезной работы или “нога в навозе”, которая у меня заменяет красивое “человек под фонарем”.

И по-моему “нога в навозе” ярче и шире характеризует человека (чем тема с фонарем). Многие наступив, боятся вытащить ногу: запах ведь пойдет. Так и стоят в этой лепешке, не пытаясь ничего изменить.
Есть те, кто вытащат, и так и ходят - им все равно на себя и остальных.
А есть те, кто вытащат, отмоют и больше туда уже не наступают. Умные значит.
Это неточно, но весьма вероятно.

#мысли_вслух #it_memes

- А давайте добавим еще один спринт к релизу?
- Давайте, но только вам итоговую сборку надо отдать за неделю до релиза
- 🤝
.... так начинался запуск натурного эксперимента "Первый закон Паркинсона* в IT". Эксперимент признан успешным, закономерность подтверждена.

* "Работа заполняет время, отпущенное на неё."
PS любые совпадения с реальностью являются плодом вашего воображения
#байки

Want Better and Faster Results? Increase Team Size and Reduce WIP
Кажущаяся логичной история: взяли в работу N фичей одновременно (где N - количество разрабов в команде), нет проблем с синхронизацией, нет необходимости декомпозировать задачи для параллельной разработки, каждый пилит свою историю и тп, на самом деле ловушка.
Ловушка, которая приводит к тому, что высок риск получить все N задач невыполненными (недоделанными, непротестированными, несогласованными).
Меньше одновременно выполняемых задач - быстрее движение вперед.

#процессы

А вы знаете про такую практику, как Manager's ReadMe?
Это когда менеджер в коротком общедоступном виде описывает свои ожидания, формат работы и взаимодействия с ним в рабочих процессах.
Практика далеко не новая, а ее популярность то растет, то снова затихает.
Полезно или нет, не знаю. Отношусь двояко, и хотя в своей работе я никогда так не формализовывал эту информацию, но что-то подобное в виде презентации было, под названием “Встреча про GTO (для новичков)” (привет прошлой компании).
А недавно подумал, что этот канал тоже можно воспринимать как ReadMe (правда в неудобном long read и спонтанном формате), особенно на фоне того, что в подписчиках стало больше коллег.
Еще вариант такого ReadMe (от человека, которого я уважаю).

Сталкивался ли кто-то с таким в реале (делал сам или такое было у его руководителя)?

#management