На что нельзя забивать: 5 критических ошибок, которых должен избегать каждый разработчик

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

По мнению Калеба Маккелви, разработчикам нельзя:

1. Ставить код выше людей

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

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

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

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

2. Думать, что их подход правильнее других

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

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

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

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

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

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

3. Не читать официальную документацию

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

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

Один из примеров — Angular. Читая его документацию, автор узнал, как работает фреймворк, о всех его аспектах и подготовился к множеству функций, которые нужно использовать для его реализации. Как представить создание авторизации или аутентификации в Angular, если не знать, что такое Route Guards? Благодаря чтению документации вы будете знать все.

4. Не заботиться о здоровье

Разработчики сидят за компьютером часами напролет. Многие не занимаются спортом и не получают достаточную дозу солнечного света. Со временем последствия такого поведения накапливаются и вытекают в проблемы со здоровьем.

Сосредоточить внимание на психическом и физическом здоровье необходимо для успешной и полноценной карьеры разработчика.

Физическое здоровье

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

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

Ментальное здоровье

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

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

5. Прекращать учиться

В IT-сфере технологии не перестают развиваться. Языки программирования также меняются и совершенствуются с течением времени. Появляются новые функции и лучшие практики.

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

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