Уроки, которые я усвоил за 2,5 года в должности разработчика

Перевод статьи «Lessons I’ve learned from 2.5 years of Software Engineering».

Программированием я занимаюсь с 16 лет, но, если подходить к вопросу строго, в роли разработчика выступаю только последние 2,5 года. За это время я успел поработать в глобальной команде крупного инвестиционного банка, а сейчас я ведущий разработчик в революционном стартапе. Мне довелось поработать со многими потрясающими технологиями и очень многому научился.

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

Не обязательно добиваться совершенства: вполне хватит и «достаточно хорошо»

Мы, разработчики программ, любим создавать что-нибудь. И естественно, мы прикипаем душой к своим детищам.

Если вы не разработчик, вообразите, что вы с нуля создаете совершенно новый автомобиль. Представьте, как вы проводите месяцы (или даже годы), создавая эту машину при помощи силы мысли, тяжелого труда, решимости и командного духа. Она должна быть быстрее или красивее, или проще в использовании, чем другие машины (и конечно, она именно такая и есть!). И вполне понятно, что вы любите свое творение и чувствуете привязанность к нему!

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

Урок

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

Совет 1

Нужно научиться понимать, когда решение «достаточно хорошее». Собирая требования к проекту, я обязательно узнаю, какие конкретно ожидания у заказчика и что в их понимании «достаточно хорошо». Больше почитать об этом можно здесь: the MoSCoW prioritisation technique.

Совет 2

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

Никто не знает всего

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

Мой опыт

Я помню, что когда я только приступил к работе в банке, я сидел в кабинете с другими членами команды и думал: «Я еще недостаточно знаю, чтобы называться разработчиком». У меня не было достаточно уверенности, позволяющей приписывать себе этот тайтл и все, что с ним связано.

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

Мы работали над какими-то изменениями в бэкенде приложения и разговорились на тему JavaScript, продолжая обсуждение, зародившееся на общем собрании в тот же день.

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

Урок 1

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

Урок 2

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

Ваше обучение – ваша ответственность

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

Мой опыт

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

К счастью, у меня всегда была мотивация учиться и улучшать свои навыки. Когда я ступил на путь разработчика программ, я взял на себя ответственность за собственное обучение. Но я столкнулся с трудностями: сложно понять, что именно нужно учить и с чего начинать.

Совет 1

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

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

Совет 2

Есть множество статей, авторы которых уже проделали за вас всю сложную работу по отбору материалов. Вот, например:

The Complete Junior to Senior Web Developer Roadmap (2019)

Don’t be a Junior Developer: The Roadmap

Совет 3

Между пониманием того, как что-то использовать, и тем, как/почему что-то работает, есть большая разница. Фокусируйтесь на изучении последнего. Мне это очень помогло при изучении новых вещей. Например, когда я работал с AngularJS1.x, я постарался разобраться в различных подходах к тому, как движутся данные во фронтенд-фреймворках.

То, что я потратил время на изучение основ фронтенд-фреймворков в целом, позволило мне быстрее разобраться в сложностях React. Перенос знаний действительно сделал мою кривую обучения более пологой и помог мне сфокусироваться на изучении самого важного. Вот поэтому я, собственно, не беспокоюсь, что мне не довелось работать с Angular (2) или Vue.

Убедитесь, что понимаете предмет достаточно хорошо, чтобы объяснить его любому

Одна из обязанностей ведущего разработчика – умение создавать надежный и функциональный код для решения проблемы. Но от ведущего разработчика также требуется умение объяснять сложные вещи другим людям.

Мой опыт

Я отвечаю за ведение технических проектов. Частично это связано со множеством взаимодействий с клиентами и собственниками компании. Мне приходится объяснять сложные, замысловатые концепции самым разным аудиториям. Например, может возникнуть необходимость объяснить преимущества использования React по сравнению с использованием другого фреймворка. Или объяснить, почему наш компилятор выдает AVX. Эти темы сложны для понимания, а объяснять их и того труднее.

Что я понял

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

Кроме того, одно дело объяснять сложную проблему, связанную с React, другому React-разработчику, и совсем другое дело объяснять подобные концепции людям с другим бэкграундом. Например, коллеге, не имеющему опыта работы с React, или собственнику компании, который вообще не программист.

Совет 1

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

Совет 2

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

Совет 3

Уделяйте время написанию документации и разделов FAQ с ответами. Я для этого использую Gitbook и Word documents. Это помогает мне предвосхитить ряд вопросов, а следовательно, предстать во всеоружии. Также это помогает всей команде, поскольку способствует распространению знаний.

Совет 4

Пишите блоги. Я использую Medium, чтобы писать о технических вещах, с которыми работаю. Это заставляет меня описывать словами процесс работы того, о чем я пишу, а также способствует углублению моих собственных знаний.

Тормозите!

Набравшись опыта, я начал работать в более медленном темпе. Это может показаться странным. Ведь если ты как специалист стал лучше, значит, теперь работаешь быстрее? Ну, вы почти правы.

Я имею в виду, что я снизил темп, в котором я думаю и в котором пишу код. Но в целом я стал более эффективно приносить пользу команде.

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

Совет

Теперь, когда я работаю над каким-то кодом, я намеренно притормаживаю. Для этого я:

• Пишу несколько строк кода и заставляю себя написать понятные и информативные комментарии. Впоследствии это поможет мне исправлять баги, а другим людям – разбираться в моем коде. Это также заставляет меня выражать свою логику простым языком, что способствует более глубокому пониманию и помогает находить баги.
• Пишу заметки для документации. Я использую Word/Gitbook для отслеживания по каждому проекту заметок о том, что я делал и какие решения принял. Таким образом я еще раз обдумываю свои действия, чтобы убедиться, что они соответствуют моим планам. Также это облегчает написание документации в конце проекта.

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

Сначала решайте проблему, а код пишите потом

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

Совет

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

Это можно сравнить с разницей между обдумыванием рецепта и последующей физической нарезкой овощей и приготовлением блюда по этому рецепту.

Что я делаю

1. Решаю проблему логически, работая с бумагой и стикерами (липкой бумагой для заметок). Это помогает мне понять, является ли мое решение рабочим. Например, я часто использую стикеры для представления if-предложений – это позволяет мне в дальнейшем перемещать их физически.
2. Пишу понятные комментарии для своего кода, дающие представление о том, что этот код должен делать. Это каркас моей программы.
3. Теперь я готов к написанию самого кода. К этому моменту я четко понимаю свое решение.

У этого подхода есть большое преимущество. Когда я подхожу к третьему шагу, я могу сфокусироваться главным образом на написании исполняемого/поддерживаемого/понятного кода, в котором будет реализована моя логика. Мне не нужно пытаться фокусироваться на двух задачах одновременно.

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

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

Наша работа куда более творческая, чем можно было бы подумать!

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

Люди часто говорят, что они не творческие личности, потому что думают, что быть творческим человеком значит уметь рисовать картины. Но в разработке программ есть много способов задействовать мои творческие навыки. Например, креативность проявляется, когда комбинируешь существующие функции и API для создания чего-то совершенно нового. Или когда вдохновишься аккуратной drag and drop фичей чужого сайта и включаешь ее в свой проект. Или даже когда рассматриваешь предметы искусства, а думаешь о том, как создать новую визуализацию с D3.js.

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

Сфера разработки ПО больше связана с людьми, чем с кодом

По мере накопления опыта этот факт становится мне все более и более понятным.

Позаботьтесь о том, чтобы стать человеком, с которым людям приятно работать и вообще находиться рядом.

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

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

Заключение

За последние 2,5 года я достиг очень многого. Мне действительно повезло учиться у совершенно фантастических людей. Сейчас я концентрируюсь на том чтобы продолжать углублять и расширять свои знания с помощью онлайн-курсов, а по работе – брать на себя все больше ответственности в рамках технического лидерства.

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]