Как опознать плохого разработчика: 9 признаков

Торопыжка

Адаму нравится быстро закрывать задачи. Его фишка — делать всё в кратчайшие сроки. При малейшей сложности он бросается гуглить и применяет первое найденное решение.

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

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

QA-диссидент

Сильвия — замечательный разработчик. Ей очень нравится программировать. А вот что она на самом деле ненавидит, так это писать тесты. Она жалуется, что это снижает скорость разработки. И вообще, есть же тестировщики (QA), так зачем ей самой об этом беспокоиться?

Да, писать тесты бывает обременительно. Но приложение развивается, становится сложнее, требований к нему всё больше. Без подстраховки в виде тестов поддерживать код будет ой как нелегко.

Проблема всех Сильвий в том, что им неинтересно настраивать тестовую среду, — ведь они не осознают важности тестирования. К тому же их знания о тестировании обрывочны и бессистемны.

Код проживёт дольше, чем вы его разрабатываете. Вы должны убедиться, что он делает ровно то, что должен, — ни больше ни меньше. Так что в следующий раз, когда будете оценивать трудоёмкость новой фичи, учитывайте и время на написание тестов.

Адепт оверинжиниринга

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

Такие программисты:

• сразу закладывают в проект микросервисную архитектуру — даже не представляя границ системы и не зная, нужно ли в ней несколько сервисов;
• думают о масштабировании, когда и клиентов ещё нет;
• размышляют об оптимизации, когда с производительностью всё просто прекрасно
• и так далее.

Одинокий волк

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

Но есть разработчики-отщепенцы.

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

Ненавистник документирования

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

Как вы себя почувствуете, если купите навороченный телевизор и обнаружите, что в комплекте нет инструкции по эксплуатации? Да вы тут же проклянёте компанию, которая его выпустила.

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

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

Быдлокодер-беспредельщик

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

Меня такой подход бесит больше всего. Писать код просто, но вот писать хороший код — сложно. А большинство разработчиков даже не пытаются это делать. И им нет оправдания!

Код многое говорит о своём авторе. Если код у вас получается неаккуратным и неуклюжим, возможно, вы и в жизни так же небрежны. Но если стараться писать хороший код, то это постепенно войдёт в привычку, а потом и вовсе начнёт приносить удовольствие. Смотреть на чистый и понятный код — что может быть лучше?

Спринтер-графоман

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

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

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

Сделайте шаг вперёд, станьте проактивным.

Диктатор

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

Они сто раз придерутся к вашему фрагменту кода. Он их, видите ли, чем-то раздражает — хотя работает исправно, проходит все тесты и выглядит отлично.

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

Непридельщик

Они пишут код. А документацию не пишут. И дизайном тоже не занимаются. И бумажная работа их не прельщает. Всё, что не код, — не их проблема. Они не возьмутся за это, даже если сроки поджимают.

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

По моему опыту, обычно так ведут себя новички. А ведь как раз этого и нужно избегать новоиспечённым программистам. Растите над собой! Ничего не делая, невозможно чему-то научиться. Хорошие разработчики рано или поздно выходят из зоны комфорта.

Подытожим

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