Чему можно научиться у x10-разработчиков

Недавно я получил вал комментариев к статье о легендарных х10-программистах. Одни хотели стать такими же, как они, другие — держаться от них подальше. Но на самом ли деле они такие чудо-богатыри — или просто мы их так воспринимаем?

В этой статье я расскажу, как мне работалось с разработчиком «модели x10» и какие уроки из этого можно извлечь.

История Гарри

Лет десять назад трудился я в одной компании. Руководитель отдела разработки ПО принял на работу сеньора — назовём его Гарри. Примерно в то же время мы наняли и мидла Митча, но об этом позже.

Первые несколько месяцев Гарри был скромен и ни с кем особо не общался. Он занимался сугубо технической фичей — анимацией воздушных и жидкостных потоков в нашем 3D-софте для обучения специалистов-механиков. Мы считали это несбыточной мечтой — задачу было сложно реализовать, и долгое время все старательно от неё отпихивались. И вот наконец кто-то взял её на себя.

Когда он подготовил фичу к QA-тесту, всё выглядело и работало куда лучше, чем мы могли себе представить. Результат был подкреплён тысячами успешно пройденых юнит-тестов — хотя никто из нас на своих задачах никогда эти тесты не проводил. Очевидно, менеджеры всех уровней были приятно удивлены результатом и рады долгожданной фиче.

Вскоре после успешного запуска фичи Гарри устроил презентацию и рассказал об архитектуре кода — жизненном цикле объекта, инверсии зависимостей, разнице между объектами с глобальным и локальным временем жизни, недостатках антипаттернов и том, как всё это связано с кучей наших внутренних проблем.

Как оказалось, мы накопили большой технический долг. Пусть не настолько огромный, чтобы мешать продуктивной работе, но в нашей кодовой базе были жуткие фрагменты, которые всех приводили в ужас. Очевидно, проблема крылась в плохих паттернах разработки — об этом и рассказал Гарри. Представьте: в один момент мы все поняли, что отчасти виноваты во всём сами.

Самое интересное, что этот чел всегда был прав. Не то чтобы он постоянно спорил и настаивал на своём, он просто знал всё — и обо всём. Да, пару раз в разговорах с ним мне удалось его переубедить, потому что я всегда проверяю всю информацию, прежде чем что-то сказать (ага, я горжусь собой :)). Но в нашей команде было много ребят, которые занимали примерно такие же позиции, как и Гарри, но при этом не обладали и сотой долей его компетенций. Мне за них неловко.

Не думаю, что ему нравилось ставить людей в неловкое положение, хотя у него это очень хорошо получалось. Скорее у него было своё представление о том, как должен работать создатель ПО. Оно базировалось на опыте, который на несколько лет опережал опыт нашей компании. У нас просто ещё не было таких навыков — и это обескураживало не только Гарри, но и всех остальных.

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

Гарри был успешен: он обладал необычайной квалификацией и выступал за более гибкие методы работы. Вскоре руководитель, который его нанял, ушёл из компании. Его уход немного шокировал нас, но шумиха быстро улеглась — компания менялась к лучшему, появились новые продукты. В итоге я, Митч (тот самый, о котором я обещал рассказать позднее) и новый тестировщик перешли под руководство Гарри и стали работать над тем, чего в нашей компании раньше никто никогда не делал.

Однажды в разговоре Гарри сказал, что всегда считал меня мидлом. Когда он узнал, что я всего лишь джун, было заметно, что он разозлился на руководство. Примерно через три недели меня повысили. В похожей ситуации оказался Митч — у него было достаточно знаний и навыков для сеньора, но официально он работал мидлом. Ему пришлось ждать заслуженного повышения чуть дольше, чем мне.

Временами Митч и Гарри были неразлучны. Помню, как они часами сидели в конференц-зале и продумывали архитектуру нового продукта. Тогда я понимал, насколько мне ещё далеко до них. Очень часто казалось, что они говорят на каком-то особенном языке. Они никогда раньше не работали вместе, но сходились во мнении о современных концепциях программирования, о которых в нашей компании ещё никто не знал. Поначалу раздражало, что им так нравится общаться друг с другом, но, когда они заканчивали свои обсуждения, оставалось только написать код — причём без особых трудностей.

Хотя я хорошо справлялся с любой технически сложной задачей, а Митч был в целом даже умнее меня, у Гарри всё равно всегда получалось писать код лучше, чем у нас обоих. При этом половину своего времени он проводил на встречах с менеджерами отдела и руководством компании, придумывал новые подходы к работе и фиксировал их в документах или помогал нам. До сих пор не понимаю, как с таким большим количеством задач ему удавалось быть таким продуктивным, — причём он никогда не позволял членам своей команды задерживаться в нерабочее время (и себе тоже).

До встречи с Гарри у меня уже было несколько лет программистского опыта. Но ключевыми для меня стали те два года, которые я провёл в его команде, — именно тогда, как мне кажется, я узнал всё то, что должен знать каждый сеньор. Мы отказались от устаревших методов работы — хоть их и часто используют, они непродуктивные, а иногда даже вредные, — и стали более требовательными, начали использовать более совершенные инструменты и повысили эффективность рабочих процессов. А ещё, чтобы достичь гармонии в команде и создать хорошую кодовую базу, важно, чтобы все разработчики разделяли одни и те же ценности.

В итоге мы разработали приложение, в котором практически не было дефектов. Оно отлично работало, его можно было легко расширить и позже переиспользовать в других проектах. Это приложение стало одним из самых успешных технических проектов в моей карьере.

Внутренние порядки в компании иногда могут свести с ума, особенно если принимать всё близко к сердцу. Подозреваю, именно из-за этого Гарри и ушёл — не в какое-то новое, более хорошее место, а тупо по личным причинам. Через год уволился и Митч. Он тоже ушёл не куда-то, а откуда-то.

Перед уходом Гарри дал мне совет: «Выражай своё мнение чаще». Я вспомнил часы, проведённые в конференц-зале, когда Гарри и Митч делились своими блестящими идеями и практически не давали мне шанса что-то сказать. Но когда мне всё-таки удавалось вставить пару слов, обычно я делал важные замечания и говорил по делу.

Гарри и Митч ушли, и мне нужно было быстро дорасти до их уровня, чтобы помогать другим справляться с задачами, которые раньше выполняли они. Хоть я достиг высоких показателей и стал примером для подражания, в итоге наши пути с компанией тоже разошлись. Она стала для меня классной стартовой площадкой — и я благодарен ей за это. Я видел её в лучшие годы, но мы просто перестали подходить друг другу.

Спустя несколько лет я продолжаю разделять принципы, которым научился за время работы в команде Гарри. Мне стало легче высказывать своё мнение. Я стал применять эти принципы в других компаниях и заметил, что, если им следовать, моя работоспособность повышается.

Наверняка вы уже сделали для себя какие-то выводы, пока читали эту историю, но я всё равно расскажу, какие уроки извлёк для себя.

Урок 1

Сложно с ходу распознать x10‑программиста — да и не нужно

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

Многие ли хоть раз завершали задачу в четыре стори-поинта в два раза быстрее, при этом делая больше юнит-тестов и создавая код с меньшим количеством багов? То есть работали в десять раз эффективнее джуниоров или даже коллег, которые занимают схожие позиции, но вынуждены бороться с серьёзным техническим долгом или обладают не такими обширными знаниями?

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

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

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

Урок 2

Стать профессионалом непросто

По опыту нашей команды могу сказать: нельзя обвинить человека в том, что он пользуется проверенными и устоявшимися методами, — фактически он всё делает правильно. Но я уверен, что Гарри считал нас непрофессионалами. Он хотел, чтобы все в его команде достигли высоких результатов и стали экспертами в своём деле, — и это объяснимо.

Не забывайте, что мы все люди, а значит, далеко не совершенны. Гарри тоже был обычным человеком и раздражался из-за того, что одна и та же дурацкая ошибка появлялась в сотый раз (при этом до его прихода такие ошибки считались в нашей команде обычным делом). А когда терпение на исходе, то не всегда можешь контролировать себя и общаться с коллегами уважительно. Такое поведение само по себе непрофессионально.

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

Если вы хотите что-то изменить, найдите баланс, будьте дипломатичны и осторожны. А слова выбирайте ещё осторожнее.

Урок 3

Развивайте хард‑ и софт‑скиллы

Я не могу гарантировать, что, следуя этим советам, вы станете в десять раз продуктивнее, но уверяю вас — как только вы начнёте ими пользоваться, станете понимать программирование в десять раз лучше:

• Строго следуйте принципам SOLID.
• Разделяйте ответственность компонентов с помощью паттерна MVC.
• Применяйте паттерн CQRS.
• Полностью покрывайте код юнит-тестами с помощью инструментов покрытия кода в режиме реального времени
• Используйте BDD, чтобы понять запрос клиента до мельчайших подробностей. Одновременно с этим пользуйтесь автоматическими UI-тестами.
• Чётко определите для себя так называемые критерии готовности (definition of done) и всегда следуйте им
• Пишите хороший код и определитесь со стратегией ветвления, чтобы система управления исходным кодом всегда оставалась чистой и производительной.
• Используйте agile-практики по максимуму, но не ведитесь на то, что пытаются вам продать скрам-мастера.

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

Урок 4

Остерегайтесь псевдо‑10х‑разработчиков

В нашей компании был ещё один разработчик другого ранга — назовём его Джеймс. Он был успешен — работал на компанию много лет и и был образцом дисциплинированности. Но он никогда не отвечал за свои ошибки, хотя на него постоянно жаловались коллеги.

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

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

Когда в команде есть такие разработчики, корень зла — их руководитель, который не заставляет их работать эффективно и считает плохие привычки своих подопечных правом на собственное мнение и «особый путь».

Заключение

Уверен, что есть х10-программисты бывают разными: эгоистичными и любезными, приятными и отпугивающими. Если вы один из x10, выбирайте сами, какие из этих качеств вы хотите проявлять.