Я знал, что фронтенд-разработка зашла в тупик в тот день, когда интервьюер попросил меня предоставить мой профиль Stack Overflow.

Он также спросил, где находится мой блог.

И он спросил, где находится мой GitHub.

Он попросил у меня мой Twitter и мой jsFiddle.

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

Какие книги я читал?

За какими блогами я следил? Какие аккаунты в Твиттере?

Не поймите неправильно: он не запрашивал учетные данные, чтобы он мог принять мою личность. Он хотел знать все это, чтобы оценить мой вклад в «сообщество». И я знал, что «сообщество» фронтенд-разработчиков разорилось, потому что пятидесятилетний мужчина в неопрятной деловой одежде нанял кого-то для обслуживания некоторых сайтов во внутренней сети коммерческого банка, проект, который он описал, идя к комната для интервью, как «не особо сложная» и «немного скучная», попросила их, чтобы он мог найти хорошего разработчика.

Еще до того, как он задавал вопрос обо всем, что я сделал.

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

Во-вторых, он молчаливо признавал свою некомпетентность. Давайте спросим Stack Overflow и GitHub, хорошие ли они разработчики. Он использовал сообщество, чтобы принять решение за него.

В-третьих, он укреплял однородность сообщества. Он нанял не хорошего разработчика, он нанял идеализированного разработчика; Платоническая форма хорошего разработчика; «Хороший разработчик».

Вы должны убить всех «хороших разработчиков».

Не поймите неправильно: я не говорю, что следует убивать того, кто придерживается вашего представления о «Хорошем разработчике», или даже что вы не должны их нанимать.

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

Я говорю, что вам следует проанализировать свою идею о том, что значит быть «хорошим разработчиком», вывести ее на свет, а затем убить.

Убить всех хороших разработчиков

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

Кто знает, насколько хорошо он поступит?

Я полагаю, он считал себя хорошим разработчиком по собственному уважению.

Разработчики, которых я знал и уважал, тестировали вместе с ним; они прошли. С моей точки зрения, это было предсказуемо: конечно, они прошли.

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

Он охарактеризовал свой тест как тест на «Хорошего разработчика».

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

Но его испытание могло привести к установлению общих стандартов, превышающих его конкретные потребности.

Умел ли он различать младших разработчиков?

Всегда ли ему нужны были разработчики, чтобы быть старшим?

Как бы то ни было, его испытание могло подтвердить однородность мысли. Одно дело проверять факты, но при проверке на предмет мнения, проверка будет отдавать предпочтение мнению автора. По крайней мере, он отдавал предпочтение своему собственному мнению о том, что значит быть «Хорошим разработчиком», даже если он проверял только факты: было его мнение, что некоторые факты были важны, а не другие.

Тем не менее, это был технический тест. Кто знает, что повлекло бы за собой личное испытание?

Убить всех хороших разработчиков

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

Коллега может решить не пить с вами по многим причинам:

  • У них есть религиозный запрет
  • Они выздоравливающие алкоголики
  • Они беременны или пытаются забеременеть
  • Они принимают лекарства
  • Выпивка заставляет их чувствовать себя небезопасно
  • У них есть обязанности родителей или опекунов.
  • Ты скучный

Если оставить в стороне мысль о том, что кто-то может не захотеть пить с вами, потому что вы им не очень нравитесь, то выпьет ли он - это не ваше дело.

Вы нанимаете коллегу, вы не нанимаете друга.

Рабочие отношения - это не то же самое, что личные. Не путайте их.

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

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

Да пошла ты, жаба: они, блядь, не приветствуются, и причина в тебе.

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

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

Убить всех хороших разработчиков

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

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

Интервью - это не реальность и не похоже на реальность.

Наш процесс найма - не более чем ритуал, испытание, и если мы примем это, если мы признаем это, мы сможем лучше говорить о том, какими качествами должен обладать наш герой: мы должны уметь определять, что быть «Хорошим». Разработчик »означает для нас, а затем усовершенствовать эту идею. Мы должны быть в состоянии создать испытание, соответствующее нашим обстоятельствам, нашему бизнесу, а не имитировать какое-либо другое испытание.

Мы должны признать, что «Хороший разработчик» может быть не нами или даже не похожим на нас.