1. Идейный фанатик
Есть люди, которые уверены на 100%, что знают правильный ответ на любой вопрос. К сожалению, чаще всего у них нет аргументов или релевантного опыта, чтобы доказать свою точку зрения. Они просто так думают.
Вы когда-нибудь слышали подобное?
- Android лучше iOS;
- iOS лучше Android;
- язык программирования X лучше, чем язык программирования Y;
- фреймворк X лучше, чем фреймворк Y;
- язык программирования или фреймворк Z – отстой;
- бесплатные приложения лучше платных (и наоборот);
- только плохие разработчики используют тесты;
- хорошие разработчики всегда пишут тесты.
Конечно, в определенных ситуациях, некоторые из вышеперечисленных утверждений могут быть верны. Но как правило, слабые разработчики не думают – они просто применяют эти утверждения как неоспоримые правила в 100% случаев.
Есть еще одна проблема с этими тезисами – они могут быть верны или не верны. Третьего не дано. Поляризация никогда не помогала разрешить проблему. Люди придерживаются одной точки зрения, а если кто-то не согласен, это воспринимается как личная обида. Такой подход только усложняет отношения и коммуникацию.
Слабый разработчик будет слепо следовать догме вместо того, чтобы подумать, проанализировать и выбрать лучший подход.
2. Усложнение проблемы
Усложнять процесс разработки – классическая проблема для начинающих специалистов. Часто они не знакомы с наиболее эффективным способом решения проблемы и пытаются изобрести велосипед. В самом начале карьеры в этом нет ничего страшного.
Но иногда, даже с набором опыта, привычка усложнять проблему остается. И время от времени даже опытные разработчики этим страдают. А это, как мы уже знаем, может быть сигналом слабого разработчика.
Классические примеры сверх-инжиниринга:
2.1. Трата времени на функционал, который не важен
Представьте разработчика, создавшего сложную систему логирования для приложения, в котором есть страница входа и еще одна страница для работы, больше ничего. Создание этой системы заняло больше времени, чем написание всего приложения. Это сверх-инжиниринг.
2.2. Прикладывать огромные усилия для обработки всех возможных случаев отказа
Такой подход может быть оправдан, если цена ошибки очень велика. Например, вы разрабатываете систему искусственного интеллекта для хирургии или ПО для запуска ракет в космос. Но в большинстве случаев, приложение должно решать задачу с определенным уровнем надежности. Если система скидок в супермаркете имеет один сбой на 100 000 случаев, в этом нет ничего страшного.
2.3. Инновации ради инноваций
Иногда, для решения задачи на проекте уже есть готовое решение. Но слабый разработчик хочет использовать новую библиотеку, чтобы решить ту же задачу «лучше». Или он пожелает переписать существующую логику с другим набором сущностей и зависимостей. Для самого разработчика это может быть полезно, поскольку он изучает новое и улучшает навыки. Но это бесполезно для команды и проекта.
Если проблему можно решить просто, значит ее так и нужно решить. Помним про принцип KISS – keep it simple stupid. Так поступают сильные разработчики.
3. Беспорядочная речь – беспорядок в голове
При написании кода и при разговоре задействуются одни и те же участки мозга. Эти же области используются и когда мы думаем. Разработчики сначала создают решение у себя в голове, а затем реализуют его с помощью языка программирования.
Но при чем же здесь ясность речи?
Сильные разработчики обычно лучше излагают свои мысли, нежели слабые. Способность объяснить идею простыми словами без использования сложных выражений является чертой сильного разработчика. Для слабого это большая редкость.
Человек, который постоянно меняет тему в разговоре, может писать несвязный код. Человек, который говорит сложными и длинными предложениями с множеством пояснений, скорее всего, будет писать такой же код.
Просто обратите внимание на следующее:
- Насколько велик словарный запас разработчика?
- Как часто в разговоре он сам себя поправляет?
- Как он начинает и заканчивает предложение?
- Насколько четкие и последовательные его мысли?
- Насколько свободно он изъясняется?
- Использует ли он слова-паразиты?
- Насколько кратко и емко он излагает свои мысли?
Как и все остальное, эти пункты не характеризуют слабого разработчика на 100%, но чаще всего они верны. Разумеется, это не применимо к людям, у которых проблемы с речью, например, заикание.
4. Один стек навсегда
Такой подход связан с недостатком опыта и консервативным мышлением. Слабый разработчик будет пытаться решить любую проблему одним и тем же способом. Как в анекдоте:
Обычно это следствие первого успешного опыта. Слабый разработчик использовал способ Х на своем первом проекте, и все заработало. Теперь на любом другом проекте он будет пытаться использовать тот же подход. Это допустимо для начинающих разработчиков. Но есть проблема. Такой подход тормозит развитие. Если использовать повсюду один и тот же стек технологий, программист не будет развиваться.
Еще одна особенность состоит в том, что сфера IT очень быстро развивается, поэтому вы не сможете быть сильным разработчиком, используя стек технологий 2014 года в 2022 году.
Главное отличие слабого и сильного разработчика – это эффективность. Сильный разработчик всегда найдет, где и когда использовать правильные инструменты.
Главное – понять, что и когда использовать:
- регулярные выражения очень мощный инструмент, но использовать их для любых операций со строками на проекте – это слишком;
- Eclipse – отличная среда разработки для Java, но если вы разрабатываете под Android, лучше подойдет Android Studio;
- С – отличный язык, но не стоит на нем писать фронтенд для сайта, для этого есть другие языки;
Эти пункты не относятся к инструментам – они относятся к человеку, который их использует. Сильный разработчик будет использовать нужные инструменты в нужных местах. Слабый будет использовать, те которые ему больше нравятся.
Все вышеизложенные особенности характеризуют слабого разработчика. Но если вы заметили хоть одну из них в вашем друге или коллеге, не стоит сразу вешать на него клеймо слабого специалиста. Но все равно обращайте на них внимание. Это так называемые красные флаги.
Комментарии