Чему я научился за первые два года работы программистом

Университет и работа

Шел 2015 год, когда я был студентом Флоридского университета. Тогда я учился у профессора, который по самому сложному предмету задавал в течение семестра несколько групповых проектов. По окончании каждого проекта, он оценивал каждого студента отдельно. А на следующий проект лучших студентов он объединял в одну группу, а худших — в другую. К концу семестра студент либо пробивался в сильную команду и добивался успеха, либо оседал в слабой команде. Это было здорово. Сильным не приходилось тянуть слабых, а слабые либо становились сильнее, либо “погибали”. Самое подходящее название для такой системы — меритократия. Она вознаграждает наиболее талантливых студентов, а не особо старательные студенты отстают, но не тянут за собой других. Мне это нравилось.

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

Я начал работу над проектом, на который катастрофически не хватало ресурсов. Мы создавали приложение, которое делает то же, что и большинство других: предоставляет какие-то данные и позволяет пользователю ими управлять. Я работал с двумя другими разработчиками и с ещё одним инженером по качеству, отвечавшим за тестирование. Уже через несколько месяцев я понял, что я ключевая фигура, на которой всё держится. Пользователи хотят, чтобы появилась новая функция? Я могу это сделать. Нужно провести ретроспективу? Легко. Я быстро понял, что мало что делается без моего участия. В 22 года я был в роли ведущего разработчика в одной из 25 топ-компаний.

Но подождите… Несмотря на то, что примерно год я выполнял столько работы, я все ещё получал гораздо меньше, чем более опытные члены команды. Я не получал “5”, а они не получали “2”. Я не получал никакого поощрения. Мой отпуск был короче. Что за дела? Я заметил это довольно быстро, но ещё быстрее я начал показывать свое разочарование. Мне сложно было держать себя в руках и помогать членам команды, которые хуже разбирались в программном обеспечении. Моя апатия росла, а продуктивность снижалась. Если я работаю с кем-то паре в темпе моего партнера (даже если это всего 5% от моего), я ведь всё ещё работаю, верно?

Так я провел последние три месяца, и проект завершился не очень удачно. Командный дух был низок. Никто не был действительно рад завершению этого 14-месячного проекта. Что ещё более важно, я знал, что немало моих коллег не будут особо рады перспективе поработать со мной в дальнейшем. Я начал понимать, насколько моё отношение к работе негативно влияет на меня и на людей вокруг.

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

Урок 1: Ваши отношения с коллегами (личные/лидерские качества) и ваша техническая подкованность (профессиональные навыки) одинаково важны.

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

Лучший разработчик, с которым я работал

Одним сентябрьским утром к нашей команде присоединились два фрилансера. В нашей команде мы используем парное программирование, поэтому в итоге я сел работать с одним из них. Следующие 7 часов этот разработчик (давайте назовём его Боб) задавал вопросы. Когда мы работали над новой функцией, Боб спрашивал про язык и фреймворк, который мы используем. Когда мы улаживали детали делового регламента, Боб спрашивал о продукте и задачах, которые мы решаем. В тот день Боб написал немного кода. К концу дня я был в нем немного разочарован. Я возлагал большие надежды на его навыки разработчика и надеялся, что смогу у него поучиться.

На следующий день мы с Бобом работали над другой функцией. Я написал для этой функции предварительный тест, запустил его и улыбнулся, когда на экране появились зелёные галочки. Боб задумчиво наблюдал. После того, как тест успешно закончился, он изменил пару строчек в уже протестированном методе. Я начал спорить: “Подожди! Это неправильно!”. Он кивнул и снова запустил тесты. Все тесты прошли успешно.

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

В командных обсуждениях Боб никогда не давил на кого-то, если тот был не прав. Он задавал вопросы. Отвечая на эти вопросы, люди приходили к идее, к которой (я думаю) Боб вёл всё это время. В основе почти каждого решения, которое мы принимали по коду, я обнаруживал вопросы Боба. Боб никогда не говорил о своём вкладе в работу команды. Никогда не хвалился своими навыками программирования. Его, похоже, не беспокоило, сколько времени именно он проводит за клавиатурой, работая в паре. Боб лучший разработчик, с которым я когда-либо работал.

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

Боб редко говорил: “Мы должны делать так, потому что…”. Он задавал вопросы об идеях, предложенных другими. В конце большинства обсуждений его вопросы могли заставить остальных отмести практически все другие идеи. Боб не всегда предлагал отличные идеи. Часто после ответа на свой вопрос он говорил что-то вроде: “Хорошо. Давайте так и сделаем”. Однако пока он оказал наиболее положительное влияние на качество наших программ, потому что обладал мощной способностью влиять на ход мыслей нашей команды. При этом он гораздо чаще спрашивал мнение других, чем высказывал своё.

Урок 3: Хорошего специалиста по решению задач отличает то, что он задает множество вопросов перед тем, как начать думать о решении.

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

И ещё немного о Бобе. Его технических навыков легко бы хватило, чтобы возглавлять команду. Он бы мог заниматься разработкой архитектуры, если бы хотел. Но он не хочет. Бобу нравится писать код. Ему нравится проводить анализ домена. Ему нравится разрабатывать объекты предметной области и писать тесты надежности. Ему нравится создавать качественные программы.

Оглядываясь назад

Мои первые два года были приключением. Я создавал программы, ломал программы и чинил их. Я сидел на собраниях, где люди буквально засыпали за столом. Несколько раз мне “били по рукам” (часто это делал я же, но позже). Я полностью окунался в работу, во все её радости и тяготы.

Вот о чем я жалею, оглядываясь назад:

• О времени, когда я позволял работе быть важнее людей. С работой (продуктом) всегда можно разобраться. Установить или исправить отношения может быть гораздо сложнее.
• О времени, которое я потратил, глядя на других, а не стараясь развиваться или работать. Обращая внимание на то, в чем нужно прибавлять другим, вы сами не сможете лучше работать в команде. Но вы сможете делать это, понимая свои сильные и слабые стороны.
• О времени, которое я потратил на то, чтобы говорить, вместо того, чтобы слушать. Вы не получаете знаний и не располагаете к себе людей, когда говорите.
• О времени, когда меня что-то беспокоило, и я не говорил об этом честно и открыто с тим-лидером. Он не сможет вам помочь, если не знает, в чем проблема.
• О времени, которое я потратил на изучение AngularJS. RIP.

Если вы стараетесь и переживаете за свою работу, вы можете задеть чьи-то чувства. Возможно, вы кого-то обидите. Вы будете часто ошибаться. Когда это будет происходить, в первую очередь думайте о людях. Берите ответственность на себя, искренне извиняйтесь и двигайтесь дальше. Способность на такие поступки отличают людей, которые становятся лидерами в своей сфере от людей, останавливаются на должности “разработчик”. Отступление: скорее всего, вы относитесь к последним, если постоянно критикуете своих коллег, но не видите ошибок в своей работе.

Вот что я думаю о своей дальнейшей карьере:

• Цель: стать настолько классным разработчиком, насколько возможно. Это путешествие в тысячу миль, но совершить его можно только шагая постепенно.
• Цель: стать настолько классным членом команды, насколько это возможно. Навыки программирования значат очень мало, если я не могу построить позитивные отношения с коллегами. Сплоченная команда работает лучше отдельных талантливых разработчиков.
• Цель: расставить приоритеты. Программирование не важнее моих отношений с Богом, моего брака, моих друзей или моего здоровья. Подумайте, что важнее для вас. Я не планирую жертвовать чем-то, чтобы работать продуктивнее.

Два года назад я начал свой путь к тому, чтобы стать настолько классным разработчиком, насколько смогу. Сейчас я намного ближе к этому, чем я был тогда. Но сейчас я ещё яснее понимаю, насколько я далек от конца пути (а есть ли вообще этот конец?).

Перевод статьи Mitchell Irvin: What I Learned in My First Two Years as a Software Engineer