При одинаковом результате код может быть удобным, понятным и эффективным, а может быть запутанным и неочевидным. Есть ряд признаков, по которым вы сможете понять, что перед вами слабый программист.
В этой статье мы разберем признаки слабых разработчиков, которые можно обнаружить на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Это не чек-лист, а скорее некоторые закономерности, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но если в одном человеке сочетаются несколько из них, то вероятность сильно увеличивается.
Сбивчивая речь и непоследовательность в изложении мыслей
Есть одна интересная закономерность: как человек говорит, так он и пишет код. Еще в 80х годах эту мысль высказывал Эдсгер Дейкстра, автор одноименного алгоритма обхода графа, а в наши дни это подтверждают и научные исследования.
При написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность. Это можно объяснить на достаточно бытовом уровне: разработчик сначала придумывает абстрактное решение в голове, используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код. То есть язык программирования является такой же формализацией образов из мышления в конкретную систему символов и правил, как и любой другой человеческий язык.
Поэтому при знакомстве с разработчиком обратите внимание на то, как он говорит:
— Насколько объемный у него словарный запас;
— Как часто он поправляет себя;
— Как начинает и как заканчивает фразы;
— Насколько целостны и непротиворечивы его мысли;
— Много ли он использует слов-паразитов и заполняющего паузы «мычания»;
— Насколько обширный контекст он способен удерживать в диалоге;
— Насколько лаконично и емко он способен донести информацию.
Такое наблюдение требует некоторой практики, но если вы будете обращать на это внимание, то тревожные звоночки заметите сразу. С большой вероятностью, все то же самое вы обнаружите и в его коде. Если человек многословен, то и код его будет избыточен. Если он прыгает с темы на тему, то и код будет непоследовательным. Если же он может донести глубокую мысль понятным образом в несколько слов, то и в коде он будет прост и нагляден.
Корреляция достаточно высока, и ее точно можно учитывать. Но стоит отдельно исключить из этого правила случаи, когда у человека есть органические или неврологические нарушения речи, такие как заикание или афазия.
Злоупотребление жаргонизмами и buzzwords
Некоторые разработчики в общении (или в резюме) часто используют профессиональные термины. Особенно внимательным стоит быть к людям, которые изменяют их морфологию, используя уменьшительно-ласкательные формы, вплоть до превращения их в эвфемизмы — «багуля», «тэзэшка», «аппликуха», «батончик».
Велика вероятность, что таким образом человек пытается впечатлить слушателя, замаскировать неуверенность в себе, или скрыть отсутствие опыта и реальных знаний. То же самое относится к buzzwords — к «гламурной лексике», словам, которыми умышленно пытаются произвести ложное ощущение, а не передавать информацию. Например, «эксклюзивность» или «элитный» — слова, которые используются, чтобы произвести впечатление и апеллировать к эмоциям, а не передать информацию и апеллировать к разуму.
В этот же пункт входит слишком частое употребление новояза — особенно часто это встречается у людей, которые много работали в в крупных корпорациях и часто общались с менеджерами, или в стартапах, где нужно выбивать инвестиции, создавая видимость прогресса. Такую манеру общения иногда называют «технотрёп» (“technobabble”), а в англоязычной культуре есть более общий (сугубо разговорный) термин “bullshitting”.
Если вы замечаете за разработчиком такую линию поведения, задавайте ему уточняющие вопросы в глубину и в ширину. Ирония в том, что даже если вы сами в этой теме не эксперт, поймать на вранье такого «специалиста» будет достаточно просто. Поэтому разработчик, который может просто и без затей ответить на ваш вопрос «Я не знаю», уже немалого стоит, и такого точно не стоит списывать со счетов. А вот программист, который будет изображать осведомленность, жонглируя техническими жаргонизмами — однозначно «слабый».
Перфекционизм и идеализм
Есть разработчики, которые давно сформировали свое мнение о чем-то и практически не меняют его. При этом часто никаких практических аргументов в пользу такого мнения у них нет, как и релевантного опыта. То есть человек просто может уверенно повторять то, что где-то когда-то услышал. Например:
— Фреймворк или язык X лучше фреймворка или языка Y;
— Фреймворк или язык Z — вообще гадость;
— Задачи такого рода нужно всегда решать именно так;
— Надо делать так, потому что так сказал такой-то;
— Если в компании используют X, в этой компании не надо работать;
— Если в компании не используют X, в этой компании не надо работать;
— Бесплатные решения лучше платных;
— 100% кода должны быть покрыты тестами, иначе это плохой код;
— Тесты нужны только плохим разработчикам, хорошие могут работать и без них;
— Тернарные операторы это плохо;
— Мутабельные данные это неправильно;
— Однобуквенные названия переменных — это гадость.
Каждый подобный тезис может быть справедлив в ряде случаев — проблема в том, что человек возводит этот тезис в абсолют. Он может даже писать неплохой код, но с таким подходом он вряд ли сможет подружить свои интересы с интересами команды и бизнеса. А еще такого разработчика трудно вырастить до сеньора, поскольку для этого нужна способность сравнивать, анализировать разные варианты и выбирать наиболее подходящие по объективным причинам, а не по личным симпатиям.
С перфекционизмом все достаточно прозаично: лучшее — враг хорошего. Разработчик не должен тратить лишние часы на то, чтобы решить, какой цвет тени будет смотреться лучше — #444444 или #3e3e3e, или на переименование всех переменных и функций так, чтобы фрагмент кода был максимально приближен к грамматически корректному тексту.
Какие еще есть признаки «плохого разработчика»?
Об этом расскажем в следующей статье! Не забудьте подписаться на наш канал и поставить лайк. А еще расскажите в комментариях: помогали ли вам подобные наблюдения определить слабого разработчика?
