(и продолжайте свое саморазвитие, когда никому нет дела)
2 октября 2017 года я получил свою первую зарплату в качестве Rails-разработчика. Я работаю в компании по веб-разработке, которая использует только Rails уже полтора месяца. Я был взволнован, услышав о таком подходе в интервью. Но с тех пор я успокоился. Я попытался объяснить почему и проанализировать причины в этой статье.
Оглядываясь назад
Некоторое время работаю веб-разработчиком. Но я был в очень странной ситуации в начале этого года. Я работал удаленно, у меня была достойная зарплата и гибкий график, но меня это не устраивало. И последние три года моей профессиональной жизни я не был счастлив. Я прыгала с работы, искала ту, где больше зарплата и меньше плена. Я думал, что если моя работа позволит мне иметь достаточно времени для моей личной жизни, это будет хорошо для меня. Действительно, есть много людей, которые ищут радости вне своей работы: в хобби, путешествиях, семье и т.д.
Но я никуда не мог оттуда попасть. Меня еще угнетала рабочая ситуация, так как хотелось все делать хорошо, хорошо зарабатывать и получать удовольствие от процесса. А в феврале я наткнулся на статью Виктора Шепелева Три типа программистов, и прочитав ее, я полностью изменил ситуацию.
Язык программирования (точнее, язык + инструменты + инфраструктура + сообщество) навязывает определенную модель мышления, и благополучие и продуктивность программиста глубоко зависят от того, соответствует ли его модель модели языка и среды, в которой он работает. работать с.
Может дело в этом? Мне нравится, когда мой текст хорошо выглядит, будь то статья или программный код. Когда я учился в университете, я читал Code Complete с абсолютным восхищением.
Но когда я начал работать, то понял, что для клиента неважно, чтобы код был красивым, лишь бы он работал. Ему было все равно, как все работает. Ему нужно было вот что:
- Он работал правильно;
- Это было в свое время (что обычно означает «вчера»);
- Это было красиво снаружи (интерфейс).
Таким образом, вместо радости от создания красивых текстов и идеального кода я получил только будничную рутину и тлен. Вот что мы получили:
- Если он падает, вы его чините;
- «Мы должны запустить рекламное предложение в понедельник», и вы сидите и делаете это все свои выходные;
- «Мы переехали на новый сервер, интеграция будет работать, да?» — «Дайте доступ, я проверю все настройки».
И все это вы делаете на PHP, что заставляет вас нервничать и подозревать, и вдобавок ко всему еще и повторяться.
Я хочу быть Rails-разработчиком!
Поэтому я начал изучать Ruby, вдохновленный статьей Виктора. Он помог мне вернуть радость программирования.
Кривая обучения была крутой, что означало, с одной стороны, меньше вакансий, а с другой стороны, меньше плохих рабочих мест и более высокие зарплаты. Потом я познакомился с Rails, который считается любовью всех стартаперов. Оказалось, что можно сделать то, что работает быстро и как нормальный человек.
Я пришел к пониманию, что мне следует начать работать с Rails вместо PHP. Я как бы хотел начать свой путь программиста с чистого листа и, наконец, перестать жертвовать качеством кода в угоду жестким бизнес-требованиям. Перейдя на новый язык, я решил выработать привычку использовать лучшие практики. Это означало постоянное тестирование кода, выделение достаточного количества времени на обдумывание любого решения и использование передовых технологий. Таким образом, я, наконец, начну оттачивать свои навыки, а не просто разнорабочий. Я также стану более счастливым и более ценным активом, повысив свои навыки. Это был мой план.
Во время учебы мои надежды лелеяли многие опытные люди. Начали с Виктора, который 10 недель тщательно отчитывал меня и показывал красоту Руби. Потом Антон познакомил меня с Rails, и оказалось, что если у меня есть задача, я могу сам создать работающую вещь в разумные сроки.
Что ж, пришло время мне снова работать. Мне потребовалось некоторое время, чтобы найти работу, и мне пришлось довольствоваться более низкой зарплатой, чем я ожидал. Мне пришлось забыть обо всех хороших вещах и проектах, которые я делал в прошлом. Но я был уверен, что передо мной работа мечты!
У меня было собеседование в среду вечером, а в четверг в 10 утра. Я должен был появиться в офисе с ноутбуком. Мне сказали, что моих знаний «чуть-чуть не хватает для позиции джуниор» и пригласили на проект со словами типа «у нас прострелены руки и было бы круто, если бы ты справился».
А потом все мои идеи начали рушиться одна за другой, как песчаные замки на пляже разрушаются приливными волнами.
Срок годности
Мой первый рабочий день был полон неприятных сюрпризов. Оказалось, что проект, на который меня пригласили, стартовал еще в 2014 году. Как вы думаете, это значит, что он большой и сложный? Тогда ты прав. А еще он действительно старый. Я просмотрел код проекта и нашел там Rails 4.1 и Ruby 2.2.3.
Прежде всего я создал пустую базу данных. Но моей ошибкой было попытаться избавиться от переноса данных. Когда база данных была восстановлена из дампа, я попытался установить гемы. И я снова потерпел неудачу. В Gemfile есть несколько ссылок на этот конкретный коммит с пометкой «исправить при коммите в ветку master». Прошел год с момента коммита, но он не был исправлен. А когда я открыл тестовую папку, то обнаружил, что давно никто ничего не тестировал. Есть некоторые тесты, но их немного и очевидно, что они были сделаны на ранних стадиях этого проекта.
К концу первого дня удалось наконец-то увидеть страницу входа в браузере. Следует отметить, что с тех пор мы обновились до Rails 4.2.7. Хотя и не без трудностей.
Помимо технических проблем, были некоторые проблемы с управлением. Процесс разработки был разделен между несколькими командами, что привело к ситуации, когда сроки и требования игнорируют реальные возможности программистов. У разработчика есть время только на код. Фаза стратегического обдумывания, тестирования и отладки откладывается в пользу дедлайна. При этом задача завершается плохо протестированной или вообще не тестируемой. Более того, все старые части никогда не подвергаются рефакторингу. Они временно пропатчены, потому что «у нас нет времени, есть сроки».
Такие проблемы, скорее всего, не уникальны, и большинство из вас время от времени сталкивается с одними и теми же проблемами. Вопрос в том, что мы должны делать как разработчики? Или, другими словами…
Как все это вытерпеть и не стать кодовой обезьяной?
Есть определенно два уровня проблем:
- Проблемы на уровне компании/проекта;
- Личные проблемы на уровне навыков и рабочего процесса и тайм-менеджмента.
Конечно, проще начать с себя. Компания тоже берет на себя изрядную долю ответственности, но я считаю, что разработчик должен еще больше заниматься своим саморазвитием.
Дело в том, что мозг создает шаблон из любых повторяющихся действий и будет использовать этот шаблон при любой возможности. Вот почему альпинисты прекращают тренировки, когда начинают двигаться неадекватно из-за мышечной усталости. Программист, которому приходится несколько раз идти на компромисс в отношении качества кода, через некоторое время начнет писать грязный код по умолчанию по той же причине.
Идея вроде «написать себе качественный код и доделывать только задачи на работе» приводит к той же ситуации. Плохой поведенческий паттерн начнет формироваться, поскольку количество рабочего времени в любом случае превышает количество личного времени. Вот почему нам нужно что-то придумать.
Я нашел пять ключевых проблем, которые могут превратить меня в кодовую обезьяну. Когда я их решаю, я осваиваю свои навыки, не деградирую, получаю удовольствие от процесса и в целом придерживаюсь составленного для себя плана перехода с PHP на Ruby. Вот как я это делаю.
1. Большой незнакомый проект
Обычно много времени уходит на поиск информации, попытки понять, что такое проект и как он работает. Можно подумать, что ознакомившись с проектом, вы избавитесь от проблемы. Но это скорее исключение. Изучение кода какого-то незнакомого и незнакомого проекта — обычное дело.
Так что в первую очередь я более или менее изучаю предметную область. Это помогает знать базовые термины, с которыми я обязательно столкнусь в каждой задаче. Затем я ищу совпадения с сущностями (такими как модели и таблицы в базах данных) для тех же терминов. И тогда я могу анализировать сущности и искать какие-либо связи между ними.
Вторая фаза — это момент, когда я получаю конкретное задание. Первым делом прошу менеджера или тестировщика показать мне, где это находится в интерфейсе. Там можно найти все необходимые части кода. Если у меня проблемы с пониманием того, что происходит в коде, я консультируюсь с теми, кто уже давно работает с проектом.
2. Недостаточно времени для тестирования
Даже если клиент сдвигает дату дедлайна, тестирование крайне необходимо для разработки и должно быть предусмотрено время для него при оценке задач. Даже если работодатель говорит что-то вроде «Нужно писать не тесты, а безглючный код», я их не слушаю, а пишу тесты. Когда я оцениваю время выполнения поставленной задачи, я также выделяю время на тестирование. Я просто не говорю, что это время также включает в себя время тестирования. Это проще :)
3. Недостаточная спецификация задачи
Иногда некоторые требования упоминаются только на этапе разработки. Более того, существует огромный разрыв между тем, как выглядит интерфейс, и тем, как он работает на самом деле. Если руководитель не понимает, насколько велик этот разрыв, он либо ставит невыполнимые задачи, либо бесится, почему «эта мелочь заняла так много времени». Меня это очень раздражает.
Так что, чтобы не было каких-то пояснений и переписываний, лучше все уточнять в процессе оценки задачи. При этом я также проверяю, все ли материалы готовы перед заданием, несмотря на то, что это не входит в мои обязанности. Я считаю, что лучше все прояснить, чем потом быть виноватым. Это особенно актуально, когда задача не выполняется вовремя, потому что мы ждем каких-то интерфейсов или текстов.
4. Код-ревью в конце задачи
Часто это делается в самом конце дедлайна. А в случае каких-либо выявленных проблем приходится все переделывать в спешке. Кроме того, у вас нет возможности обсудить принятое решение.
Я решаю эту проблему довольно грубо. Я прошу о проверке кода для каждой части, которую я отправил в PR. Таким образом, когда есть крайний срок, я могу быть уверен, что все проверено и мне не придется ничего переписывать.
5. Я не вижу пути развития для себя как программиста
Здесь я имею в виду, что мой рабочий процесс больше связан с выносливостью, чем с развитием. Нет понятного наставничества. Когда решаю мелкие задачи, учусь ставить патчи и работать по аналогии (на самом деле использование аналогии - обычная практика, но только если перед вами качественный образец.)
Этот вопрос может быть решен на уровне компании. Например, вы можете задать вопрос своему работодателю или найти работу, где более важно профессиональное развитие работников. Но ничего из этого со мной еще не произошло, поэтому я все решаю самостоятельно.
Вам необходимо повышать эффективность и качество своей работы точно в рабочее время. Выходных и свободного времени мало, даже не рассчитывайте на них.
У вас также должен быть глобальный план саморазвития. Если вы не можете применить это на практике в рамках проекта, вы должны потратить на это свое свободное время. Но вы должны помнить, что любой навык, не связанный с основным проектом, может навсегда остаться только академическим.
Я принял решение: мне нужен наставник, чтобы повысить эффективность своей работы. Вам может быть интересно, почему я выбрал наставника, если вокруг меня много коллег? Дело в том, что мои коллеги обычно настолько заняты своими делами, что у них нет времени на меня. Кроме того, наставник может брать на себя стратегические задачи вашего саморазвития, а коллеги давать вам советы о том, как создать что-то, что будет работать.
Когда рабочие задачи будут выполнены с надлежащими трудозатратами, я смогу повысить свой общий уровень вне проекта. Я предполагаю, что наставник может показать мне мои белые пятна и как продвинуться профессионально. После этого я мог бы поговорить с моим работодателем о повышении заработной платы.
Проблемы на уровне компании
Кажется, что некоторые компании, разрабатывающие специализированное программное обеспечение, превращают своих программистов в рабочих сборочного конвейера. Они выполняют какие-то простые процедуры на своих объектах, а руководители считают, что эффективность можно повысить просто за счет увеличения количества работников, а не развития тех, кто уже работает.
Я пока не менеджер и сужу как дилетант, но, на мой взгляд, любая девелоперская компания должна обращать внимание на следующие вещи:
- Регулярно наращивайте кадровый резерв;
- Наметить план профессионального развития внутри компании, понятный как работнику, так и работодателю (имея в виду не только карьерную лестницу, но и качество навыков);
- Не перекладывать ответственность за проблемные проекты только на разработчиков.
Впереди будут ужасные последствия, если закрывать глаза на эти вопросы. Разработчики, которые подошли к своей работе со всей серьезностью, в конце концов уйдут. Те, кого больше волнует стабильность или конкретная компания, останутся, но будут работать с небрежным отношением. Таким образом, эффективность останется низкой, независимо от того, сколько людей они нанимают.
На данный момент я вижу, как люди пытаются нарастить кадровый резерв, нанимая студентов. С одной стороны, легче воспитывать умы тех, кто не испорчен деловой жизнью. Но с другой стороны, студенты — это не та рабочая сила, которая может составить костяк компании.
Когда соотношение разработчиков и студентов становится 50/50, все становится странным. Рабочих достаточно, но они часто отстают от графика, так как много переписывания. Старшие разработчики заняты другими проектами, поэтому у них нет времени обучать этих студентов.
Дело в том, что нет повсеместного ответа на вопрос: «Что делать, чтобы разработчик продвинулся?» Одни добиваются больших результатов благодаря общению с другими, при этом днем и ночью засыпая их вопросами. И этого было бы достаточно для такого человека, чтобы продвинуться. Бывают случаи, когда вопрос достаточно специфичный, но нет возможности задать его коллегам, так как они могут быть заняты или работать над другим проектом. Если человек настойчив, он будет гуглить, спрашивать у друзей, искать на гитхабе, но решит проблему в одиночку.
Но не все такие: кто-то может покорить вершину, а кто-то просто сдается. Кому-то проще заплатить и получить быстрые и качественные ответы от эксперта. Некоторые решают задачи, которые не смогли решить в течение рабочего дня, в свободное время.
Ответ есть всегда, но каждый должен искать его, имея в виду свой случай. И работодатель должен быть заинтересован в решении проблемы с разработчиками.
Кто ответственный?
Я полагаю, что здесь «оба виноваты», как и в любых других отношениях. Но мы также должны принимать во внимание уровень приверженности обеих сторон. Когда вы начинаете работать в команде, вы ожидаете чрезмерной защиты. Вы ожидаете, что они будут заботиться о вас, мотивировать вас, поэтому вы продвигаетесь вперед безо всяких усилий. Но эта идея наивна и довольно инфантильна. И в то же время, если я все делаю сам, зачем мне вообще рабочие отношения? Если есть возможность заниматься фрилансом, зачем мы вообще формируем команды? В значительной степени потому, что мы не хотим, чтобы наши навыки ухудшались при выполнении утомительных задач на рынке фриланса.
На мой взгляд, партнерство здесь единственно возможный тип взаимодействия. Когда мы говорим о рабочих отношениях, у нас могут быть разные обязанности, но общая цель. В любой компании каждый разработчик может уточнить, какой карьерный рост они обеспечивают. Чем меньше альтернатив предлагает компания, тем большего саморазвития ждут от работника.
Но если у руководства есть хоть немного гибкости и оно готово к общению, вы можете вместе подумать о том, как помочь сотруднику продвинуться и сколько способов для этого им нужно. Может быть, им нужно нанять наставников из третьих лиц или, может быть, дать талантливым работникам немного расслабиться, чтобы они могли учить других? Может быть, нужно дать работникам свободное время для самообразования?
Стоит обратить внимание на то, что существует и проблема продвижения полноценных разработчиков, так как в таком случае сложнее найти менторов внутри компании. Но и это можно решить общими усилиями.
Это статья mkdev, написанная Натальей Максименко. Наши наставники всегда доступны для вас.
