Физическое рабочее пространство. Игрушки

Похожая логика относится и другим игрушкам разработчика. Просто нет причины, чтобы не снабдить ваших разработчиков новейшими компьютерами, имеющими как минимум по два больших (21 дюйм по диагонали) ЖК-монитора (или один монитор с 30 дюймами по диагонали), а также не разрешить, чтобы они могли заказывать на Amazon.com любую нужную им техническую книгу. Это очевидные средства уси­ления производительности, но для темы нашего обсуждения более существенно то, что это очень важные инструменты найма, особенно для мира, где во многих компаниях считают программистов "мелкими сошками", "машинистками", и действительно зачем вам такой большой монитор, и что плохого в ЭЛТ-экранах с 15 дюймами по диагонали? Когда я был еще ребенком, .
Общественная жизнь разработчиков
Разработчики программ ничуть не отличаются от обычных людей. Конечно, мне известно, что сейчас разработчиков принято считать типичными чудаками с синдромом Аспергера, целиком отключенных от межличностных отношений, но это не совсем так, и даже люди с этим нарушением развития заботятся об общественной стороне рабочего пространства, которая включает в себя следующее.
Как относятся к программистам в организации?
Они "шишки" или "машинистки"? Руководство компании состоит из инженеров или бывших программистов? Отправляясь на конференцию, разработчики летят первым классом? (Меня не заботит, что это выглядит расточительством. "Звезды" перемещаются первым классом. Как правило.) Когда они прилетают на собеседование, в аэропорту их подби­рает лимузин, или им нужно добираться в офис самостоятельно? При прочих равных условиях разработчики предпочтут организацию, где к ним относятся как к "звездам". Если ваш генеральный директор - это ворчливый бывший продавец, который "не понимает, чего эти разработчики-примадонны все требуют какие-то подпорки для кистей рук, большие мониторы и комфортабельные кресла, и за кого они себя держат?", тогда вашей компании, скорее всего, нужно сменить род деятельности. Вам явно не нужны великие разработчики, если вы их не уважаете. 
Кто их коллеги?
В день собеседования программисты особое внимание обращают на сотрудников, с которыми встречаются. Хорошие ли они? И, что еще важнее, способные ли они? Как-то я проводил летнюю интернатуру в компании Bellcore, филиале Bell Labs, и каждый, с кем я встречался, повторял снова и снова: "В Bellcore прекрасно работается благодаря ее сотрудникам".
Скажем так, если у вас работают ворчливые разработчики, от которых нельзя просто так избавиться, то хотя бы отстраните их от собеседований, которые должны обязательно проводиться веселыми, компанейскими людьми, похожими на руководителей круизов. Постоянно напоминайте себе, что кандидат, вернувшись домой и решая, где ему работать, будет вспоминать о вашей компании не слишком хорошо, если в ней ему попадались одни только мрачные личности.
Кстати, первоначальное правило найма в Fog Creek, "украденное" у Microsoft, состояло в следующем: "Будь способным и доводи дело до конца". Но до того как была основана компания, мы поняли, что требуется еще одно правило: "Не строй из себя крутого"5. Если вспомнить прошлое, то для получения работы в Microsoft следовать этому правилу было необязательно. И хотя я уверен, что в этой компании пусть неискренне, но заявляли, как важно людям хорошо относиться друг к другу, в конечном итоге там никого еще не отстранили от работы только потому, что человек строил из себя "крутого". В действительности это качество сотрудника, возможно, является предварительным условием того, чтобы он выбился наверх. Интересы производства от этого не страдают, но страдают интересы найма. Кому захочется работать в компании, где терпимы к таким людям? 
Независимость и автономность
Еще в 1999 году, до того как основать компанию Fog Creek Software, я увольнялся со своей работы в городе Джуно и прошел собеседование с кадровиком, которое обычно проводят со всеми увольняемыми. И тут я попал в ловушку, рассказав ему все, что было не так с управлением компанией. Мне было точно известно, что из-за этого я не получу ничего хорошего, а могу только пострадать, но, тем не менее, я это сделал, и главное, на что жаловался, - на стиль руководства "наскоками". Видите ли, большую часть времени начальники оставляли людей в покое, чтобы те спокойно делали свою работу, но время от времени они вмешивались по мелочам, требуя что-то сделать именно так, как они говорят, и не иначе, а затем, не ожидая результатов этого фарса, довольно быстро переключались на мелочное руководство какой-то другой задачей. Например, я помню особенно надоедливые два-три дня, когда все, от моего начальника и до генерального директора, занимались тем, что указывали мне, как именно вводятся данные в анкету при приеме на работу. У них не было опыта работы в качестве разработчиков пользовательских интерфейсов, и они уделили не слишком много времени на разговор со мной, чтобы понять, почему в том конкретном случае я все-таки был прав. Впрочем, дело здесь в том, что начальство просто "уперлось" в этом вопросе и даже не удосужилось выслушать мои доводы. Вывод, сделанный после разговора с генеральным директором, состоял в том, что не надо было болтать.
Обычно, если вы собираетесь нанимать способных людей, позвольте им применять свою квалификацию в работе. Начальники могут советовать, и это правильно, но им следует быть крайне осторожными, чтобы их "совет" не воспринимался как команда, так как по любому конкретному техническому вопросу начальство, скорее всего, знает меньше, чем сотрудники "на передовой", особенно если вы, как я уже сказал, нанимаете способных людей.
Разработчикам хочется, чтобы их нанимали за их квалификацию, относились к ним как к экспертам и разрешали принимать самостоятельные решения в рамках их собственного опыта.