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

живые #it_memes со звуком

Unexpected Anti-Patterns for Engineering Leaders — Lessons From Stripe, Uber & Carta:
• anti-pattern #1: shying away from micromanagement (как мы уже обсуждали, иногда "микроменеджмент" - это единственный способ добиться результата)
• anti-pattern #2: pushing back on measuring flawed metrics (вот тут не согласен - если знаешь что меряешь фигню, то зачем?)
• anti-pattern #3: serving as the umbrella for your team (люто плюсую в этом месте)

#management #metrics

Про вчерашний анти-паттерн по метрикам.

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

• Don’t try to measure too much. Just because you can measure something doesn’t mean that you should.

• Understand the goals of your project before you determine what to measure.

• Once you determine the goals for your project, determine which metrics support these goals. Try to choose from existing metrics rather than defining new ones. The important point to note is that now you know why you are using each particular measurement.

• Don’t let your metrics define the behavior of your team. If the metrics you have chosen can be modified without showing an increase or decrease in quality, either change the metrics or choose a set of relative metrics that cannot be manipulated.

• Monitor the metrics throughout the project. Just as you measure the project to assess quality, you should measure the metrics program to define areas for improvement and identify trends you can use to provide better information to the team.

#management #metrics

И снова про "волшебников"

Регулярно наблюдаю истории веры в "волшебника":
- нам нужен аналитик (системный, бизнес, продуктовый)
- нам нужен архитектор (куча разных сценариев приложения его усилий)
- нам нужен "автоматизатор", который придет и скажет, как феншуировать автоматизацию тестирования

Вера в специализацию безгранична, ровно до того момента, когда выясняется, что
- мы не можем нанять, потому что сами ничего не понимаем в специлиазации "волшебника"
- мы не можем понять творит ли он волшебство, потому что изначально не было критериев "чуда"
- мы не верим в свои силы и отказываемся изучать/делать эту работу самостоятельно
- "волшебник" никого не пускает в свои чертоги репозитории, потому что "чего вы там, неучи, забыли" и он становится бутылочным горлышком, которое непонятно чем занимается

А чаще всего проблема, ради которой искали волшебника, решается просто выделением времени на изучение чего-то нового существующей командой, T-шейпингом и тому подобным расширением экспертизы самой команды или просто наймом еще одного "обычного" инженера, а не ботлнекера.

#мысли_вслух #байки

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

"Modern Software Engineering" Dave Farley

Учитесь учиться, господа-товарищи.

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

"Малыш и Карлсон проверяют код" сказка из древнего твиттера

#it_memes

Странно, я давно знаю про принцип Питера, но в первый раз за все время эта статья про него действительно показала мне, про что он :)

Потому что "традиционное" определение меня немного клинило, но я никогда глубже не смотрел:

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

А теперь чуть-чуть доворачиваем и вот "подсказка":

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

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

#management

Забавно бывает складывается жизнь рабочая...

Кто-то занимает C-level позицию практически в самом начале своего творческого пути и остается на ней (в той же компании*) лет уже 15. Становится ли он лучше как менеджер? ХЗ Как текущий менеджер - так себе, но ведь работает.
*за 15 лет компания конечно самоизменяется, но все равно +/- та же.

Кто-то в какой-то момент становится главой департамента разработки человек на 100-120 (опять же после лет 15 в одной компании), в котором нет менеджеров (техлиды есть) и теперь думает, что с этим делать и как собеседовать менеджеров, которых ни разу не собесил. Справится? ХЗ

Кто-то не парится и работает по учебнику. И че ты ему сделаешь, каждый пункт "по уму"?

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

А кто-то лет 20 фигачит код разрабом и ему, вроде, по кайфу (но на самом деле тоже хз, потому что кто ж с ним про это говорил).

Как вам такие примеры принципа Питера? :)

Философское однако настроение...

#байки

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

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

"Modern Software Engineering" Dave Farley

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

И снова откуда-то эта связь "софт-скилы" - это "скилы болтовни".

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

Уметь выслушать, услышать и потом понятно, кратко и емко донести свою мысль - это софт-скилы.

А болтовня - это просто болтовня.

#мысли_вслух #развитие #классика

я и знаменитый кабанчик в пятничных #it_memes (честно сперто и отретушировано)
ЗЫ эту книгу (для подготовки к собесам по системному дизайну) часто так и называют "книга с кабанчиком"

"Автоматизатор" в команде - горе для автотестов...

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

Как это работает, что за продукты, какое соотношение между кол-вом разрабов и "автоматизаторами" и, самое главное, сколько из новых фичей успеваете автоматизировать?

#holywar #test_automation

Сурово однако... 🤔

Being back in the job market again, I’ve noticed that there’s a bit of a change happening in job descriptions for Engineering Managers. Most notably, many of them specify that the successful candidate should be doing some/all of:

• Coding
• Code reviews
• Driving sprints/being a scrum master
• Breaking down work into tickets for the team
• Architecting solutions
• And many more tech-focused functions

The Engineering Manager Role

#management #развитие #holywar

Вчера набрел на свои #мысли_вслух 10-летней давности

Ваша работа как программиста — не писать код, а решать проблемы. Лучший способ решить проблему — писать как можно меньше кода.

Единственное, чем ее хочется сейчас дополнить, это продолжить через запятую "оставив этот код понятным"

Пр-р-ростите, сегодня мем, который не мем.
Я помню, что сегодня еще четверг и для пятничных #it_memes еще рано.
Настроение дня: "менеджмент - это просто"
особенно "релиз-менеджмент"...

Так как мем был внеочередной, вот полезняха (в плане "как делать не надо" или "сначала думай, потом делай").
https://youtu.be/Qd9ASypIA1s

Нашел у Жени в телеге, поржал (смахнув предварительно слезу) с каждого слайда. Теперь жду доклада Жени (🍿закуплен)

#процессы

ну, за рефакторинг 🍻

в пятничных #it_memes

Why do we underestimate how long it will take to complete a task?

А я всегда говорил, что оптимизм - это опасно :)

#оценка

Полезные ссылки по SRE:
• Курс по подготовке Site Reliability Engineer
• Интенсив SRE Week 2024 ШАД
взято тут

#развитие #tech_read

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

(c) Bjarte Bogsnes

#management #it_философия

Недавно в комментах обсуждали о причинах того, как история с CrowdStrike (когда в мире легла виндовая инфра, около 8.5млн компов) пролезла в прод.
А вот и ответ (оригинал, и на русском, тем более оригинал из РФ еще и недоступен): тула типа виновата.

И самая мякотка, что они будут делать, чтобы не повторять:

Тестировать, млин 😂

#testing