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

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

В 2015 году я учился в Университете Флориды. В то время у меня преподавал профессор, чей предмет был самым сложным за весь курс. В течение семестра он давал нам несколько командных проектов. После каждого он оценивал всех студентов по отдельности. Для следующих проектов он группировал на основе предыдущих оценок лучших и худших студентов. Это было здорово. Сильные не должны были тащить слабых, а слабые могли либо стать сильными, либо не делать ничего.

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

В самом начале мы разрабатывали обычное мобильное приложение. Я работал с двумя другими программистами и одним тестировщиком. Только через несколько месяцев я понял, что оказался человеком, который тащит на себе все. Пользователям нужна новая фича? Я могу с этим справиться. Кто-то должен провести ретроспективу? Давайте я. В 22 года я играл роль ведущего разработчика в компании.

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

Фото: Unsplash

В таком состоянии я пробыл три месяца; проект, наконец, был доведен до конца. Однако никто не праздновал. Более того, я понимал, что некоторые мои коллеги не захотят работать со мной снова в будущем. Я осознал, что мое отношение повлияло не только на меня, но и на других.

Через несколько недель я попросил всех ответить на вопрос, над какими чертами характера мне следует поработать. Ответы коллег открыли мне глаза: производительность – не главное. Когда я пришел на работу, я думал, что тут надо трудиться усердно точно так же, как и в университете; мне казалось, что сильных будут награждать, а слабых – наказывать. Это представление мешало мне работать с другими, быть благодарным за их вклад, обучаться и обучать. Все думали, что я «помешан на продуктивности».

Урок 1: Ваши отношения с коллегами и технические навыки одинаково важны

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

Лучший разработчик, с которым мне доводилось работать

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

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

Фото: Unsplash

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

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

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

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

Все разработчики решают проблемы. Обучение, кодинг, общение – все это проблемы, которые нужно решить. Талантливые разработчики сначала задают вопросы, чтобы понять проблему, а затем приступают к поиску решения. Так они не только подступают к ее корню, но и проявляют уважение к чужим идеям.

Выводы

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

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

Вот какие цели я поставил перед собой сейчас:

• Быть лучшим разработчиком.
• Быть лучшим коллегой.
• Правильно расставлять приоритеты.

Источник.

Материалы по теме:

За шесть дней я прошел собеседования в шести ведущих компаниях и получил шесть офферов

Жизнь после удаленной работы – истории десяти профессионалов

Выгорание — болезнь 21 века: почему технологии только усложняют нашу жизнь

Мое худшее собеседование – истории семи успешных людей