"Жизнь становится лучше, когда ты постоянно предполагаешь, что можешь ошибаться.
Ты больше узнаешь, меньше обижаешься. И привлекаешь умных людей.
Ваша неправота ничего не говорит о вас, как о личности.
А вот невозможность ее признать - говорит." (с) чье-то из интырнетов #мысли_вслух

Manage Your Capacity, Not Your Time
"...важно не количество времени, которым вы можете жонглировать, распределять и управлять, а качество времени, которое вы можете потратить на свои задачи..."
"...независимо от того, где вы работаете и насколько высокую позицию вы занимаете, ваши возможности ограничены: каждый день вы работаете только определенное количество часов, и только определенное количество этих часов вы можете провести в состоянии продуктивности и потока..."
#management

7 признаков звиздеца во взаимодействии PM и разработки (отсюда)
Можно "поиграть" в бинго, но не хочется.
#процессы

На следующей неделе в отпуск.
Так что у меня "давайте после НГ" уже началось :)
#it_memes

Про компромиссы или 256 оттенков серого.
Самое большое заблуждение в IT (и не только), с которым часто приходится сталкиваться, это то, что все вокруг черно-белое.
А на самом деле везде и всегда есть контекст. Всегда есть развилка, место для маневра и компромиссов. Потому что везде вокруг люди.
Попытка привести все к 0, или 1 ни к чему хорошему не приводит. Особенно если не пытаться сделать контекст ясным для всех. Но это сложно и не все умеют, поэтому и возникает история “делаем так и не иначе”.
При этом компромиссы и принимаемые в них решения опасная штука: не фиксируя плюсы/минусы и “план Б”, мы слепо доверяемся якобы истине, всем понятной и разделяемой.

Если привести простые примеры :
Перезапуск упавших тестов - многие даже не задумываются над проблемой, просто их перезапуская. Но в этот момент ты теряешь нужный тебе контекст, помогающий найти истинную причину падения. С другой стороны - разбираться долго, не всегда хватает инструментов, знаний. Проще перезапустить… Дилемма.

Завязываемся на порядок выполнения тестов - это же удобно, один раз настроил и погнал. Тесты идут в ожидаемом порядке, и последующие ориентируются на то состояние системы, в которое ее привели первые тесты. Быстро писать, такие тесты чаще всего, быстрее выполняются. Но встав на эти рельсы, вы в своем пути все дальше уходите от того состояния, в котором вы можете реально понимать, что происходит во время тестов и что проверяется в каждом конкретном случае. И, возможно, сэкономив немного времени в начале пути, вы заложили себе бомбу замедленного действия.

Добавляем очередной if-чик в функцию 100500 строк - это быстро, решение уже на уровне “паттерна”, место принятия решения локализовано. Ну вроде так. Или не так?
После какого количества if-чиков мы перестаем понимать то, что делает код? Как часто при этом перестает работать то, что до этого работало года 3 и никто проблем не видел? Когда новый if станет той каплей, когда прорвет плотину накопленного дерьма технического долга? И снова дилемма…

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

Стадии развития программиста:
- Ваш код гавно.
- Мой код гавно.
- Любой код гавно.
- Жизнь гавно.
- Выступаешь на конференции с темой: Как структурировать гавно, так чтобы оно не растекалось. (c) Danil Pismenny (@pismenny)
#мысли_вслух

Explorers are bad leaders
"Explorers are hard to follow. It’s better to let them wander alone, then hear their tales.

Explorers occasionally find a great place that would make a better home for many people. So that makes a job for a leader.

Leaders are easy to follow."
#management

"in most companies people are doing two jobs: their actual job and the job of managing others’ impressions of how they’re doing their job" (с) Ray Dalio, Principles: Life and Work

Или (если углубиться и расширить actual job)

People do 3 types of work within companies.
Produce:
Creating artifacts to serve the company’s external stakeholders.
Organize:
Creating the necessary structures & processes for Produce work.
Self-promote:
Creating a proxy for their own competence & impact.

Examples
Produce work: products, eng infra, sales deals, services, support, status updates,...
Organize work: internal processes, resource planning, status updates, re-orgs, hiring,...
Self-promote work: perf reviews, status updates, 1:1s with manager
(c) Shreyas Doshi @shreyas

#процессы #развитие #мысли_вслух

Выбираем рецепты для новогоднего стола
"Наша API документация интуитивно понятна, нам не нужны примеры кода"
#it_memes

Всех читателей с наступающим Новым годом!
Я не верю в чудеса, просто потому что это всегда результат или чьего-то труда, или чьего-то продолба.
А вот в мозг и труд верю :)
Пусть в Новом году у вас все получается, и то, что запланировали, и то, что прилетит неожиданно.
Пусть чужие продолбы вас обойдут стороной, ну а собственные будут несильными, просто как сигнал того, что мозг нужно держать включенным и на ошибках надо учиться.
Спасибо, что читаете, оставайтесь на связи.
Будем вместе продолжать не верить, но делать чудо :)
#it_memes

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

Когда ты становишься менеджером, возможности кодить у тебя становится сильно меньше. И чем выше позиция, тем меньше времени у тебя на это остается. А со временем еще и желание погружаться непосредственно в код притупляется (моя история).
При этом для многих именно возможность “писать код” и является самым важным, а может и единственным критерием “ты можешь быть техническим менеджером”.
Я не согласен. Самое важное - это сохранять способность понимать “язык” инженеров (разрабов, тестировщиков, devops-ов) и говорить с ними на этом языке.
Как это достигать?
1. Много читаем, слушаем, смотрим
2. Задаем инженерам вопросы (про особенности реализации, про возникающие сложности, про то, что они рекомендуют почитать/посмотреть)
2* попутно убеждаемся, что 80% проблем не меняется, потому что люди не склонны меняться, да и технологии/практики не так уж сильно меняются
3. Не ведемся на ловушку “ничего не меняется” и продолжаем пропускать информацию через мозг. Потому что изменения всегда есть, просто они редко революционные, а скорее эволюционные
4. Есть еще, спорный для меня вариант, “возвращаться обратно в инженеры, а потом снова в менеджеры”, но если это делать, то делать регулярно. Практическая реализация этого маятника у меня вызывает вопросы: опыт показывает, что нужно быть готовым к сложностям вида “странно, из менеджеров уходит… нам не нужны менеджеры, нам нужны инженеры” или “у него недостаточный менеджерский опыт, не рулил командой в N человек”. В общем, вариант “со звездочкой”.

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

Что еще посоветуете? Писать код по ночам/выходным не предлагать, для этого времени есть масса других, более приятных, активностей :)
Что для вас "хороший технический менеджер"? Особенно интересно мнение инженеров.

Что еще почитать по теме?
Is there a path back from CTO to engineer?
What Makes a Great Manager of Software Engineers?

#management #развитие #байки

У меня часто бывает, что инфолента подсовывает что-то связанное с тем, что у меня сейчас в голове "основным тредом" работает.
Так вот ко вчерашнему про "мало что меняется" подлезла статья 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 #байки