С кем из коллег хотел бы работать снова и почему

Кем я хотел бы окружить себя в команде

За 10+ лет работы я понял, что качество команды определяет качество кода и успех проекта. Не все разработчики одинаково полезны. Я хотел бы работать с людьми, у которых есть определённые качества.

1. Люди, которые думают в терминах пользователя

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

• Я предложил максимально гибкий endpoint с 50 параметрами
• Он спросил: "А как это использует мобильное приложение?"
• Оказалось, мобильное приложение может отправить максимум 10 параметров
• Результат: мы спроектировали API на основе реального использования, не на основе "что если"

Почему это важно: Люди, которые думают о конечном пользователе, пишут:

• Более простой код
• Нужные features (а не лишние)
• Лучше аргументируют архитектурные решения

Такие люди спасают проект от оверинжиниринга.

2. Люди, которые признают ошибки

Пример: Junior разработчик в моей команде написал код с N+1 query problem. Мог бы сказать:

• ❌ "Я не знал"
• ❌ "Документация была плохая"
• ✅ "Я сделал ошибку. Давай я это починю и изучу как это работает"

Он выбрал третий вариант. Через 2 месяца стал специалистом по оптимизации БД.

Почему это важно: Люди, которые признают ошибки:

• Растут быстрее (видят проблемы как learning opportunities)
• Создают psychological safety в команде (другие не боятся признавать свои ошибки)
• Помогают fix root causes (а не symptoms)

Такие люди создают healthy culture.

3. Люди, которые помогают другим без эго

Пример: На review code я часто вижу комментарии вроде:

• ❌ "Это неправильно, переделай"
• ✅ "Я попробовал подход X и заметил проблему Y. Может стоит попробовать Z?"

Второй тип комментариев идёт от людей, которые:

• Делятся знанием, не критикуют
• Предлагают solutions, а не указывают на problems
• Гордятся growth других людей

Почему это важно: Такие люди:

• Улучшают junior разработчиков (investing в людей)
• Создают совместное владение кодом (code ownership by team, не by individual)
• Не зависят от одного человека (знания распределены)

4. Люди, которые могут объяснить сложные вещи просто

Пример: Когда мы внедрили Kafka, потребовалось 2 недели обучения команды. Один senior инженер:

• Создал 1 часовую presentation (не 8 часов)
• Показал real example из нашего кода
• Ответил на вопросы (не отправил на documentation)

Теперь вся команда понимает Kafka и может её использовать.

Почему это важно: Люди, которые могут объяснить:

• Действительно понимают тему (fake it till you make it не работает в объяснении)
• Помогают team upskill быстрее
• Не создают knowledge silos (только они знают technology X)

5. Люди, которые говорят "нет" когда нужно

Пример: Давление на сроки. PM говорит: "Нужно за неделю добавить новый feature"

• ❌ Junior: "Да, конечно! потом burns out, пишет плохой код, уходит из компании"
• ✅ Senior: "Реально мы можем сделать это за 3 недели и не сломать существующий код. Или мы можем хак-code в неделю, потом 2 недели фиксить bugs. Что выбираем?"

Второй тип людей:

• Защищает качество проекта
• Защищает team от burnout
• Дает PM realistic information для решений

Почему это важно: Люди, которые говорят "нет":

• Спасают проект от collapse
• Уменьшают technical debt
• Создают sustainable pace работы

6. Люди, которые увлечены тем, что делают

Пример: Не обязательно "любить код 24/7", но люди которые:

• Интересуются как сделать лучше
• Читают код других разработчиков и учатся
• Экспериментируют с новыми technologies
• Говорят об архитектуре не потому что нужно, а потому что интересно

Такие люди заражают команду энтузиазмом.

Почему это важно: Такие люди:

• Пишут лучший код (не потому что нужно, а потому что хотят)
• Не сдаютсяя когда сложно
• Помогают team не скатиться на legacy maintenance mode

7. Люди, которые не боятся questions

Пример:

• ❌ Architection которая не любит questions: "Просто делай как я сказал"
• ✅ Architection которая любит questions: "Хороший вопрос! Давай обсудим"

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

Почему это важно: Люди, которые не боятся questions:

• Делают лучшие решения (questioning улучшает quality)
• Создают environment где junior могут расти
• Не создают hero culture ("только они знают как это работает")

8. Люди, которые заканчивают работу

Пример: В каждой команде есть люди которые:

• ❌ Пишут половину feature и переходят на следующее
• ❌ Оставляют свои PR в review на неделю
• ❌ Не фиксят bugs в своём коде
• ✅ Доводят работу до конца (из начала и до продакшена)

Люди второго типа делают проект stable.

Почему это важно: Такие люди:

• Не создают half-finished features (самый большой source of technical debt)
• Создают ownership за свою работу
• Помогают team заканчивать releases на time

Мой ideal team

Состав (для 5-7 человек team):

1. 1x Senior / Architect — думает в системах, объясняет просто, защищает качество
2. 1x Mid-level с специализацией — backend/frontend expert, deep в одной области
3. 2-3x Mid-level разработчика — растущие people, делают большинство feature work
4. 1-2x Junior — обучаются, приносят свежий взгляд, но supervised

Культура:

• Code review обязателен (качество > скорость)
• Mistakes это learning opportunities (не punishment)
• Вопросы поощряются (не запрещены)
• Sharing knowledge normalized (pairing, talks, wiki)

Почему я так думаю

Я видел:

• Проекты которые успешны потому что люди хорошие (даже с плохой архитектурой)
• Проекты которые fail потому что люди токсичные (даже с хорошей архитектурой)

Технология это инструмент. Люди это engine.

Хотелось бы окружить себя людьми которые:

• Думают о пользователе
• Признают ошибки
• Помогают другим
• Понимают что они делают
• Говорят правду
• Любят то что делают
• Заканчивают работу

Такая команда может сделать любой продукт успешным.