Выходные - время отдыха, поэтому статьи будут просто “за жизнь” и по одной в день.
В сегодняшней статье автор делится мудростью о том, как ему удалось добиться хороших результатов в своей компании, не смотря на то, что в индустрии продукты становятся все хуже, сотрудники и пользователи несчастны, а серебряные пули, типа скрама, тянут всех вниз, а происходит все это из-за плохих руководителей (что-то мне это напоминает… кстати, про негативное влияние перфоманс ревью в статье тоже есть). Статья большая, в ней много интересных мыслей (и гуглить никто не отправляет, если вы понимаете, о чем я), некоторые из них:
- Нужно настороженно относиться к топ-перформерам (чаще всего они добиваются высокой скорости разработки путем создания тех долга и выбором плохих технических решений)
- Нужно совмещать разработку с рефакторингом, иначе вы не будете успевать устранять тех долг (это похоже на правило бой-скаута: нужно оставлять после себя код лучше, чем он был)
- Поощрять владение кодом (типичная позиция тим лидов: повышать бас-фактор, окуная людей во все места в коде, но это снижает качество, инициативу и скорость разработки)
- Разработка и управление - разные вещи. Вы не лучше/умнее ваших девелоперов только потому, что вы управляете ими. Не нужно создавать у девелоперов ложное ожидание того, что “повышение” в менеджеры - это прогресс их карьеры. Они должны идти в менеджмент, только если действительно хотят этого.
https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450
В сегодняшней статье автор делится мудростью о том, как ему удалось добиться хороших результатов в своей компании, не смотря на то, что в индустрии продукты становятся все хуже, сотрудники и пользователи несчастны, а серебряные пули, типа скрама, тянут всех вниз, а происходит все это из-за плохих руководителей (что-то мне это напоминает… кстати, про негативное влияние перфоманс ревью в статье тоже есть). Статья большая, в ней много интересных мыслей (и гуглить никто не отправляет, если вы понимаете, о чем я), некоторые из них:
- Нужно настороженно относиться к топ-перформерам (чаще всего они добиваются высокой скорости разработки путем создания тех долга и выбором плохих технических решений)
- Нужно совмещать разработку с рефакторингом, иначе вы не будете успевать устранять тех долг (это похоже на правило бой-скаута: нужно оставлять после себя код лучше, чем он был)
- Поощрять владение кодом (типичная позиция тим лидов: повышать бас-фактор, окуная людей во все места в коде, но это снижает качество, инициативу и скорость разработки)
- Разработка и управление - разные вещи. Вы не лучше/умнее ваших девелоперов только потому, что вы управляете ими. Не нужно создавать у девелоперов ложное ожидание того, что “повышение” в менеджеры - это прогресс их карьеры. Они должны идти в менеджмент, только если действительно хотят этого.
https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450