11 прагматичных советов для разработчиков-джуниоров

0
3683
views

Перевод статьи «11 Realpolitik Career Tips for Junior Developers».

Photo by Alexandru Acea on Unsplash

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

В число советов могли бы входить следующие:

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

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

Так что в моей статье этого не будет. Клянусь!

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

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

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

Советы, которые помогут разработчику-джуниору построить успешную карьеру

Если вы находитесь на начальной стадии карьеры в программировании, перво-наперво я хочу сказать, что вам повезло.

Серьезно. Вы выбрали хорошо оплачиваемую работу, к тому же очень интересную (в последнем я уверен). Я всегда воспринимал профессиональную разработку как «люди платят мне за то, чтобы я загадки разгадывал».

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

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

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

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

Но не дайте вашему воодушевлению ослепить вас. Потому что чаще всего так и происходит.

Чтобы понять, что я имею в виду, давайте перейдем к советам.

1. Старайтесь избегать вакансий с указанием тайтла «Junior Developer» и ему подобных

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

Я не буду заново писать все, что писал в той статье. Скажу лишь, что слово «junior» в тайтле примерно равнозначно пометке «на испытательном сроке». Если работодатель приклеивает к вам этот ярлык, он сообщает всем: «Я не верю, что этот человек компетентен, и вы тоже не должны ему доверять — до последующих распоряжений».

А это дает работодателю слишком много власти.

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

Есть много вакансий «входного» уровня, где ваш тайтл будет просто Software Engineer. По возможности старайтесь выбирать среди таких.

2. Разработчики-сеньоры: доверяй, но проверяй

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

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

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

Но были они какими-то звездами? Неа.

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

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

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

3. Почаще обращайтесь за помощью: все равно от вас это ожидается

Что касается отношения сеньоров к джуниорам, следует учитывать, что они ожидают шквал вопросов от вас. Они даже будут побуждать вас к этому.

Но так будет не всю вашу карьеру.

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

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

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

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

Photo by Shridhar Gupta on Unsplash

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

Люди в сфере разработки ПО имеют уникальную тенденцию к ранжированию. Мы склонны считать, что все 20 миллионов человек, занятые в разработке, запросто могут рассчитаться на первый-второй построиться по порядку, от «самого лучшего» до «самого худшего» программиста. Например, с учетом репутации на Stack Overflow (позже мы еще поговорим о геймификации).

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

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

И вы хотите предложить это разработчикам? Пфф!

У нас есть Software Engineer I, Software Engineer II, Software Engineer III, Software Enginer IV и Software Engineer V. На пятом номере наша возможность подражать фильмам «Рокки» подходит к концу, и мы заходим на второй круг. Здесь мы встречаем Senior Software Engineer I, Senior Software Engineer II, Principal Software Engineer I, Principal Software Engineer II и т. д.

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

5. Отстаивайте свою позицию, вооружившись доказательствами

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

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

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

  • Табы или пробелы?
  • Соглашение или конфигурация?
  • TDD или не TDD — вот, в чем вопрос! (впрочем, нет, это из другой оперы).

Подобные споры в командах слишком часто заканчиваются фразами «Я здесь уже 20 лет, так что делаем, как я сказал» или «Споры со Стивом у меня уже в печенках сидят, так что пробелы, да и все».

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

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

В общем, учитесь оспаривать чужие мнения, доказывая свое («а вот несколько статей, где поддерживается моя позиция, и, кстати, я сделал проверку концепции, чтобы доказать, что я прав»).

Продолжение читайте здесь.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here