Это история о нас. Тем из нас, у кого 10 и более лет опыта работы в сфере ПО, описанное в статье может показаться знакомым. А те, кто еще на ранних этапах карьеры, смогут узнать, что ждет их в близком и не очень будущем, и получить пару советов.
Переведено в Alconost
Первые шаги
Сам механизм еще не совсем понятен, но иногда в нас загорается искорка — и мы просто влюбляемся в программирование: это может случиться и после какого-то университетского проекта, и после написания приложения для собственного пользования. Ведь столько всего можно узнать, столько попробовать! В разработке ПО очень короткий цикл вознаграждения, который постоянно повышает уровень дофамина и заставляет нас «подсесть» на программирование. Нас укусил паучок программирования, но не волнуйтесь: это не болезнь — это просто химия мозга.
Впервые мы ищем работодателя, и когда нас берут на работу, мы считаем, что нам очень повезло. Сначала в нас полно энтузиазма: мы готовы узнавать все обо всем и стремимся к этому, беремся за любую задачу и не возражаем. Вычеркивая пункты из списка задач, мы получаем вознаграждение, которого ищет наш мозг. И пока мы учимся и создаем что-то новое, нас не особо волнует, над какими проектами и с какими технологиями мы работаем.
Впрочем, на этом этапе карьеры мы можем задавать слишком мало вопросов. Обычно, наверное, люди неохотно задают вопросы потому, что спрашивать и признавать, что чего-то не знаешь, как-то стыдно. У кого-то и правда это может работать так, но иногда мы, разработчики, просто предпочитаем потратить на задачу многие часы, но решить ее самостоятельно, а не просить помощи. Возможно, и здесь дело в системе вознаграждения: нашему мозгу нравится справляться с задачами самостоятельно, а удовольствия от полученного «на блюдечке» решения особо сложной проблемы нет. Если это про вас, то все-таки не брезгуйте задавать вопросы: впереди будет множество задач, и вам же наверняка хочется за проведенное на этой планете время набраться как можно больше знаний, а задавать вопросы — отличный способ учиться.
Впитывать знания тех, кто много лет учился на собственных ошибках, — бесценно.
Кроме того, мы склонны слишком доверять своим кураторам и не задумываясь следовать их советам. Не поймите меня неправильно: обычно это неплохо, но при этом обязательно нужно проверять получаемые сведения, особенно если кажется, что что-то не так. Порой кураторы становятся немного чересчур самоуверенными и, возможно, нуждаются во встряске. Найдите время и напишите пример того, что, как вам кажется, является улучшением, — чтобы куратор мог легко оценить его: если вы правы, ваше замечание примут, ведь куратором должен быть опытный и умный разработчик. Если это не сработает или окажется, что вы не правы, вам помогут понять, где вы ошиблись, а это — ценный урок.
Еще одна частая ошибка на ранних этапах — дни летят быстро, очень-очень быстро: мы хотим показать, как продуктивно мы умеем работать, мы пишем тонны кода, а в итоге — даже не уверены, правильным ли путем двигаемся. Может оказаться, что вы впустую тратите время, поэтому остановитесь, еще раз уточните требования, сделайте глубокий вдох и работайте над задачей более целенаправленно.
С корабля на корабль
За первые несколько лет или даже месяцев мы достигаем точки, когда начинает казаться, что дальше на этом месте расти некуда: и коллеги уже не такие компетентные, и кураторы не такие уж и особенные, как думалось раньше. Мы впитали все знания, которые смогли, и начинаем искать место, где можно будет продолжить увлекательно учиться.
Мы становимся чуть более требовательными при поиске работы: хотим работать там, где можно будет не только изучать новое и незнакомое, но и применять любимые технологии для создания классных штук.
На этом этапе можно сменить множество кораблей, ведь на бумаге компании выглядят отлично, но изнутри оказываются довольно скучными.
В конце концов, проявив настойчивость, мы снова находим отличное место для работы — или, по крайней мере, для удовлетворения текущих потребностей, — и начинаем работать.
Неоправданно сложно? Да быть этого не может!
Постепенно мы развиваемся, и если не очень повезет, у нас появляется навязчивое стремление писать совершенный код. Рефакторинг за рефакторингом, и снова рефакторинг: код становится все более прекрасным на ваш взгляд — и все менее понятным для других членов команды.
Вот мой совет: попробуйте прикинуть, сколько времени нужно, чтобы написать собственный прекрасный предметно-ориентированный язык или общее суперабстрактное решение с заделом на будущее (которое сейчас используется только в нескольких местах кодовой базы). Кроме того, дважды проверьте, что вам говорит «git diff». Уверены, после рефакторинга код стал лучше? Обычно, если удалось выкинуть большой кусок кода — это хороший знак. И всегда можно передумать и отложить его на некоторое время в отдельную ветку.
На этом этапе карьеры мы одержимы желанием показать компании и остальному миру, насколько мы умны. Нам это нужно, чтобы получить порцию дофамина, благодаря которому мы сидим на рабочем месте. Обычные задачи начинают повторяться, и мы спасаемся тем, что тратим время на совершенствование того, что уже и так работает — при этом начинает не хватать времени на код, который фактически решает бизнес-задачи.
Даже если у нас есть проверенный в бою способ, который работает хорошо, мы по-прежнему ищем «новые» способы и придумываем волшебные улучшения. Мы начинаем тратить много времени, пытаясь усовершенствовать, то, что уже достаточно хорошо работает и в чем команда разработчиков разбирается досконально.
В таком случае нужно помнить вот что: стабильно работающий в «боевых» условиях код оставляет больше времени на то, чтобы спокойно оценить новые методологии, передовые фреймворки и экспериментальные библиотеки. Новые загадочные проблемы в продакшне — это не очень весело. Поэтому экспериментируете на менее важных частях системы или создайте несколько тщательно проверенных побочных проектов. Это значительно упростит внедрение нововведений: вы сможете поделиться достижениями с коллегами, узнать, что они об этом думают, и в конечном итоге добиться более плавного перехода к усовершенствованным решениям.
Часто мы попадаем в еще одну ловушку: стремимся заставить работать всё в 100% случаев. Мы учитываем все возможные пограничные случаи и пишем для них тонны сложного кода (который на самом деле может даже сделать хуже) — в итоге кодовую базу становится все сложнее и сложнее поддерживать. Может показаться, что такой подход — единственно верный. Однако иногда с точки зрения бизнеса несовершенно работающие системы — это нормально, поэтому советуйтесь с тем, для кого пишете код: возможно, он предпочтет использовать ресурсы и время для разработки новых функций, а если появится проблема — просто отправит письмо, чтобы кто-нибудь разобрался с проблемой вручную.
Почему мы ведёмся на шумиху
В карьере разработчика случается и такое: мы решаем, что мир может подождать, и беремся изучать что-то новое — это может быть и новый язык, и новый фреймворк, и новая методология, и даже совершенно новая область разработки — ну или что-то еще. И как же мы делаем выбор, что изучать?
Бывает, какая-то тема просто привлекает внимание — например, потому что кажется, будто это решение одной из текущих задач. Иногда мы изучаем что-то, потому что думаем, будто в этом направлении движется вся отрасль. А иногда главная цель — получить работу получше.
Самое сложное здесь — научиться отличать временную шумиху от действительно стоящих технологий. Единственный совет, который я могу дать, сводится к тому, чтобы попробовать новинку самостоятельно и проверить ее по-настоящему.
Недостаточно просто почитать статьи в блогах — потратьте время и копните глубже, составьте собственный перечень недостатков и преимуществ технологии. Выясните, действительно ли она решает заявленные задачи?
Потратив уйму времени на изучение фреймворков и библиотек, я понял, что самое главное — держать их слегка на периферии разрабатываемых систем ПО: если в них окажется слишком много ошибок или появится что-то получше, тогда их можно будет легко заменить.
Умение найти среди всей шумихи что-то и правда полезное — важное качество хорошего разработчика. Новые технологии рождаются каждый день, и никто не заставляет их использовать.
Чтобы повзрослеть как разработчик ПО, важно также отдавать предпочтение работающему в реальных условиях коду, а не новомодным словечкам в резюме. Иногда это непросто, да и на собеседовании звучит не очень круто — но для компании должно быть гораздо важнее иметь рабочее и поддерживаемое ПО.
Впрочем, это не означает, что придется задушить в себе любопытство и перестать уделять время изучению прорывных технологий. Надо попытаться найти золотую середину: вдохновляться тем, как новички получают удовольствие от новинок, но и одновременно понимать, что работа должна быть сделана — и скорее раньше, чем позже.
Вперед, к вершинам
Поднимаясь по карьерной лестнице, мы становимся все более самоуверенными, поэтому младшим членам команды и даже курируемым разработчикам мы часто начинаем казаться надоедливыми и менее компетентными. Пишем код мы все меньше и меньше; кто-то начинает думать, что поставленные задачи — слишком простые, а это только усугубляет проблему. Постарайтесь делать наоборот: давайте остальным пример и закрывайте простые задачи самостоятельно — пусть даже они скучные.
Если в команде есть увлеченные своим делом разработчики, это помогает не забывать, что нужно сохранять любопытство и продолжать учиться. Мы должны постоянно пробовать новое: полученный даже за пару лет профессиональный опыт поможет принимать более обоснованные решения насчет того, какие технологии следует использовать.
Сложно как-то обобщить, что представляет собой состоявшийся разработчик с десятилетним опытом. Мы склонны развиваться в разных направлениях, но подстерегают нас одни и те же проблемы.
Мы с большей вероятностью попадаем в ловушку небрежной разработки: на этом этапе опыт говорит нам, что спешить с абстракциям не стоит, поскольку большую часть времени они будут не нужны. Поэтому просто помните, что если команда не любит работать с какой-то частью кодовой базы, это признак того, что соответствующий код был написан небрежно и его забросили. Возможно, его надо переписать, поэтому уделите ему внимание, когда появится время разобраться с техническим долгом.
Нас подстерегает еще одна опасность — стать жертвой собственных карго-культов, которые успели развиться за все эти годы. Обязательно время от времени подвергайте свои убеждения сомнению.
Пару слов о скромности
Многолетний опыт не дает абсолютной защиты от плохого кода — постоянно спрашивайте мнение других и просите проверять ваш код. Иногда я прошу жену (она не программист) вычитать мой код — чтобы понять, может она разобраться, что он делает, или нет.
Наверняка вы слышали это и раньше, но я повторю: опыт должен в первую очередь научить тому, что невозможно знать всё. Кто угодно может научить вас тому, о чем вы понятия не имеете.
Не сдавайтесь
У каждого разработчика в карьере бывают взлеты и падения. Кто-то начинает больше обращать внимание на деньги, а не на удовлетворение от работы, и в итоге либо работает по подряду, либо получает большие деньги за неинтересную работу. Кто-то в поисках жизни без постоянной ловли ошибок в коде переходит на управленческую должность.
Постоянно разбирать нескончаемый поток проблем (а это и есть суть разработки ПО) — это тяжелый умственный труд. У каждого были (или еще будут) дни, когда наваливается слишком много — и ты думаешь: «Зачем я этим занимаюсь? Всё очень плохо».
Если вам кажется, что пора сменить профессию, — сделайте перерыв. Обычно достаточно просто уйти в офлайн на несколько дней (или недель). Вы не поверите, насколько это встряхивает: вы вернетесь и с жадностью наброситесь на код — возможно, вам даже захочется залезть в самые дебри и разобрать бардак, до которого все никак не доходили руки.
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Подробнее: https://alconost.com
