2013-08-12
Разница между плохим и средним разработчиком программного обеспечения невелика, но между средним и превосходным — огромна. Между нимипропасть. Превосходный разработчик запросто может быть в 20 раз ценнее, чем средний разработчик, поэтому очень важно нанять одного превосходного разработчика вместо двадцати посредственных.
Недавно мой коллега сформулировал это так:
«Есть те, кто повышает уровень энтропии в системе, а есть те, кто понижает».
Энтропию преодолеть невозможно, но скорость изменения энтропии должна быть как можно ниже, иначе те, кто понижает её уровень, будут успевать только сохранять существующий баланс системы – удаляя баги, устраняя последствия плохого дизайна, некачественного кода и т.д.
Превосходные разработчики знают об этой пропасти, поэтому они, как правило, устраиваются в компании, которые сразу нанимают отличных специалистов. Посредственные и плохие разработчики демотивируют и деморализуют лучших, потому что те не могут справиться с энтропией. Цитата из фильма «Пираты Силиконовой долины» хорошо это демонстрирует:
«То, что мы сейчас делаем — это всё равно что открывать двери. Каждый день. Откроешь не ту, и на тебя польётся всякая пакость. Нужно быть осторожнее, выбирая дверь».
Открывая дверь плохим разработчикам, вы подрываете производительность ваших лучших специалистов, потому что они будут просто тратить время, вычищая посредственный код. Может быть, плохой разработчик очень хороший человек, и вы не можете просто от него избавиться. Последствия этого ситуативного гуманизма сложно недооценить.
Мы не умеем отделять зёрна от плевел
Разработка программного обеспечения не имеет квалификационных стандартов, к тому же люди, которые ищут программистов, как правило, не сильны в выявлении самых лучших из них.В результате в области существует несчетное количество ужасных разработчиков. В IT хватает программистов, которым нечего делать в этой сфере. Крайне часто встречаются резюме, переполненные терминами и аббревиатурами, при этом уровень владения навыками значительно завышен.
Если после собеседования вы все еще не уверены на 100%, что человек вам подходит, не нанимайте его. Если вы не можете точно сказать, хороший ли это кандидат, не нанимайте его. Если двоим из шести человек на собеседовании вы хотите сказать «нет» или «может быть», не нанимайте их. Вы потеряете больше, наняв плохого разработчика, чем потратив время на ожидание хорошего.
Вам также может показаться интересной цитата Стива Джобса о формировании команды из биографии, написанной У. Айзексоном:
«В большинстве случаев разница между лучшим и средним составляет 30 % или около того. Наиболее удачный полет на самолете или особенно вкусный ужин будет на 30 % лучше, чем обычно. Но Воз (Стив Возняк) был в 50 раз лучше рядового инженера. Он мог проводить совещания в собственном воображении.
Создавая команду Mac, я хотел набрать в нее именно таких специалистов. Первоклассных игроков. Мне говорили, что они не уживутся или не сработаются. Но я понял, что первоклассные игроки любят работать с первоклассными игроками — просто им не нравится иметь дело с посредственностями. В Pixar вся команда состояла из игроков высшего уровня. Вернувшись в Apple, я стремился к тому же. Процесс найма должен затрагивать все отделы. Когда мы нанимаем кого-нибудь в отдел маркетинга, я отправляю его поговорить с дизайнерами и инженерами. Моя ролевая модель — Роберт Оппенгеймер. Я читал о том, каких людей он отбирал для создания атомной бомбы. Мне, конечно, до него далеко, но я мечтал о чем- то подобном».
На фотографии команда создателей первого Macintosh. 1984 год.
Читайте также:
Устали от open-space офисов? Есть альтернативы!
10 лучших способов потерять ценные кадры
7 вопросов для найма удаленных работников
