Читать книгу: «Программист-фанатик», страница 3

Совет 4. Будь худшим

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

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

В какой бы группе ты ни был, всегда будь в ней худшим.

Ты можешь спросить, зачем по собственной воле становиться худшим в любом коллективе: «Разве это не бесит?» Да, сначала такая ситуация крайне нервирует. Будучи новичком, я оказывался в ситуациях, когда моя «худшесть» откровенно бросалась всем в глаза. Придя на работу, я не хотел доставать саксофон и боялся, что меня просто сбросят со сцены. Я находился среди людей, которые ждали, что я буду играть на их уровне и даже солировать!

И в этой ситуации обязательно (к счастью!) происходило какое-то чудо: мне удавалось вписаться. Разумеется, среди остальных музыкантов я не производил впечатления звезды. Но не было также впечатления, что я не дотягиваю до общего уровня. Этому чуду были два объяснения. Во-первых, на самом деле я не был настолько плохим, как мне казалось. Но об этом мы подробнее поговорим чуть позже.

Интереснее то, что я встраивался в коллектив этих знаменитых музыкантов – порой бывших моими кумирами, – начиная играть, как они. Было бы лестно думать, что я, как сверхчеловек, обладаю умением становиться гением просто потому, что рядом со мной находится гений, но теперь по прошествии времени я вижу более прозаическое объяснение. Скорее я был запрограммирован на стадное поведение. Именно эта программа заставляет меня, к примеру, перенимать словечки и грамматические конструкции тех, с кем приходится общаться. После полутора лет в Индии я стал говорить так, что моя жена то и дело принималась хохотать. Она спрашивала меня: «Ты слышал, что ты сейчас сказал?» Я говорил по-английски как индус.

Окружающие тебя люди влияют на твой результат. Поэтому тщательно подходи к выбору коллектива.

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

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

Позднее, после перехода в компьютерную индустрию, я обнаружил, что привычка искать самых лучших музыкантов сопровождает меня и как программиста. Возможно, неосознанно я искал работу среди лучших специалистов в области IT. Неудивительно, что тенденция сохранилась. Быть самым худшим парнем (или девушкой) в команде – все равно что быть худшим музыкантом в группе. Ты обнаружишь, что стал необъяснимо умнее. Ты даже начнешь грамотнее говорить и писать. Твой код и дизайн станут более элегантными, и вдруг окажется, что ты способен предлагать все более творческие решения сложных задач.

Вернемся к первому объяснению моей способности встраиваться в группу легче, чем ожидалось. Я и в самом деле не был настолько плох, как думал. Действительно, очень легко понять, как оценивают твой уровень другие музыканты. Если ты играешь хорошо, они пригласят тебя выступить с ними снова. В противном случае тебя начнут избегать. Это куда более надежный критерий, чем просьба высказать свое мнение, ведь хорошие музыканты не любят играть в одной группе с плохими. К моему изумлению, превосходные музыканты часто звали меня выступать с ними и даже предлагали организовать собственную группу.

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

Действуй!

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

Если в твоем городе нет организованного сообщества программистов, используй интернет. Найди привлекательный открытый проект с командой, которая находится на более высоком уровне, чем твой. Узнай чем они занимаются, просмотри архивные рассылки, выбери функциональность, над которой работают, или обнаруженную критическую ошибку, и приступай к написанию кода! Имитируй стиль готового кода по данному проекту. Преврати это в игру. Пусть твой код и дизайн будут так похожи на остальные материалы проекта, что даже отцы-основатели, стоявшие у истоков, не смогут вспомнить, кто это написал. Как только результаты твоих трудов тебя устроят, покажи их. Если все сделано на уровне, твой фрагмент кода будет включен в проект. После этого можно приступать к написанию следующего фрагмента. Если разработчики проекта не согласны с твоим решением, внеси исправления с учетом их отзывов и повторно отправь на рассмотрение или же возьми на заметку данные ими рекомендации. Работая над следующим дополнением к проекту, попытайся обойтись меньшим количеством переделок. В итоге ты станешь полноправным членом команды. Ты удивишься, чему можно дистанционно научиться у опытных разработчиков, даже если вы никогда не встретитесь лично.

Совет 5. Инвестируй в интеллект

При выборе поля будущей деятельности порой так и подмывает остановиться на технологиях, с которыми связано максимальное количество рабочих мест. Например, заняться изучением Java. Или программировать для. NET. Знание Java позволяет претендовать, а возможно, и получить работу, связанную с написанием Java-кода.

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

Компания TIOBE Software воспользовалась поисковыми службами интернета для определения относительной популярности языков программирования. За основу были взяты обсуждения различных языков⁴. На сайте написано, что «общемировой рейтинг составлен по информации о наличии квалифицированных инженеров, курсов и независимых производителей». Разумеется, речь не идет о научно обоснованной оценке, но тенденции говорят сами за себя.

На момент написания данной книги самым популярным был Java, затем следовал C. C# занимал почетное шестое место, но его популярность росла. ABAP – внутренний язык программирования компании SAP – оказался на семнадцатом месте, медленно утрачивая свои позиции. Мой любимый язык программирования Ruby (именно на нем написаны все мои наиболее серьезные проекты, кроме того, я принимаю участие в организации ежегодных международных конференций по этой теме) был на одиннадцатом месте. Впрочем, к моменту выхода первого издания этой книги он перестал входить даже в первую двадцатку. Он проиграл даже ABAP!

Я спятил, если все еще пользуюсь Ruby? Или попросту глуп? На ум первым делом приходят эти два объяснения, не так ли?

Поль Грэм в статье «Великие хакеры»⁵ утверждал, что программисты, пишущие на Java, далеко не так умны, как приверженцы Python. Он взбесил множество глупых Java-программистов (неужели я это написал?), которые принялись писать на своих сайтах развернутые контраргументы. Бурная реакция показала, что он задел за живое. Я присутствовал при первой презентации этой статьи. И она заставила меня вспомнить один эпизод.

Я приехал в Индию, чтобы набрать сотрудников, и просматривал сотни кандидатов, претендующих на десяток рабочих мест. Наша команда, проводящая собеседования, страдала от нехватки сил и времени из-за низкого процента успешно пройденных собеседований. Несмотря на поздний вечер, головную боль и красные глаза, мы не расходились, пытаясь найти новый подход к отбору кандидатов. Требовалось оптимизировать процесс, увеличив число интервьюируемых или каким-то образом привлекая более толковых людей (а лучше и то и другое). Тем, что осталось от моего голоса после двенадцатичасовых попыток получения ответов от ошеломленных программистов, я предложил добавить к ключевым словам, по которым наши специалисты по поиску персонала отбирали резюме из базы данных, слово «Smalltalk». «В Индии никто не знает этого языка», – кричал заведующий отделом кадров. Но на это и был направлен мой расчет. Ведь программирование на Smalltalk коренным образом отличается от программирования на Java. Вариативный опыт даст нам новый уровень требований к кандидатам, а динамическая природа Smalltalk позволит Java-программистам подойти к решению задач с другой стороны. Я надеялся, что эти факторы дадут нам специалистов с высоким уровнем технической подготовки, которого не было у уже просмотренных соискателей.

Добавление к списку требований Smalltalk удивительным образом уменьшило кадровый пул. Но теперь к нам приходили более одаренные люди. Они действительно разбирались в объектно-ориентированном программировании. Они знали, что Java не является универсальным, как его порой пытаются представить. Многие из них обожали программировать! Нам оставалось недоумевать, где же вы все были в предыдущие две недели?

К сожалению, наши возможности по привлечению подобных разработчиков сильно ограничивал уровень зарплат, которые мы могли предложить. В данном случае они могли диктовать свои условия, и большинство из них предпочло остаться на прежней работе или продолжить поиски. Мы потерпели неудачу с наймом, но получили бесценный урок: искать лучше среди кандидатов с многообразным (и даже нетрадиционным) опытом, а не среди тех, кто посвятил себя решению однотипных задач. Я объясняю это тем, что хорошие специалисты сами стремятся к разнообразию, потому что им нравится изучать новое. Да и вынужденная работа в незнакомой сфере формирует более зрелых и всесторонне образованных разработчиков программного обеспечения. Впрочем, по какой бы причине подобная ситуация ни сложилась, мы поняли, что она работает. Я до сих пор пользуюсь этим приемом при поиске разработчиков.

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

Тебе не дают возможности…? Используй свой шанс!

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

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

Если вы не считаете все вышеперечисленное достойными внимания причинами, возможно, вы неверно выбрали профессию.

Действуй!

1. Изучи новый язык программирования. Не имеет смысла переходить с Java на C# или с C на C++. Новый язык должен изменить тип твоего мышления. Если ты программист, работающий на Java или C#, попробуй освоить Smalltalk или Ruby, в которых отсутствует статическая типизация. А если ты долгое время занимаешься объектно-ориентированным программированием, обрати внимание на функциональные языки, например Haskell или Scheme. Ты не обязан достигать вершин мастерства. Просто попытайся написать достаточный объем кода, чтобы прочувствовать отличия новой среды программирования. Если тебе ничего не кажется странным, возможно, выбран неверный язык или ты используешь старый тип мышления в новых условиях. Отойди от привычных принципов и освой новые подходы. Попроси специалистов посмотреть на твой код и дать совет, как переписать его в соответствии с особенностями данного языка.

Совет 6. Не слушай родителей

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

Родители хотят, чтобы с ребенком все было в порядке. А блистательная карьера и связанные с этим риски в такую схему не вписываются. Родители дают панические советы чаще, чем кто бы то ни было другой, к кому мы склонны прислушиваться. Советы позволяют обойтись без потерь, но, стараясь обойтись без потерь, мы теряем возможность выиграть! Победители рискуют. Они думают о том, чего хотят добиться, а не как подстраховать свои тылы. Планирование карьеры под влиянием страха – это, скорее, не дорога к величию, а ссылка в офис до конца своих дней. Да, это безопасно, но никакого удовольствия при этом получить нельзя.

Поколение назад удовольствие не принималось во внимание, когда речь заходила о выборе профессии. Работа не должна была приносить удовольствие. Она должна была приносить в дом мясо. Удовольствие же было связано с тем, что мы делали в свободные от работы часы. Удовольствиями мы занимались по вечерам и в выходные. Но постепенно выяснилось, что если работа не доставляет удовольствия, ни о каком фантастическом выполнении своих обязанностей не может быть и речи. В наши дни ситуация не сильно изменилась, но культурные представления о том, как должна выглядеть работа, сместились в лучшую сторону. Многие из нас понимают, что энтузиазм ведет к совершенству. А без удовольствия в работе, связанной с программным обеспечением, скорее всего, не возникнет никакого энтузиазма.

Другим влияющим на карьеру фактором, идущим вразрез с представлениями наших родителей, является допустимость (а часто и желательность) смены рабочих мест. Всесторонне образованный специалист по программному обеспечению знаком с разными аспектами выбранной отрасли: проектированием продуктов, информационно-технологической поддержкой, разработкой внутренних коммерческих систем, работой по государственному заказу. Чем больше областей ты изучил, чем больше разных архитектур прошло через твои руки, тем проще тебе принимать решение в сложных случаях. Работа в одной и той же компании с постепенным продвижением по карьерной лестнице замедляет твой рост как разработчика. Времена, когда можно было присоединиться к крупной фирме и строить там карьеру, миновали. Подобное поведение считалось признаком надежности. Но теперь это недостаток. Информацию, что у тебя было всего одно рабочее место и тебе приходилось иметь дело только с одним набором систем, многие (умные) менеджеры по персоналу воспримут в отрицательном ключе. Лично я предпочту взять на работу человека, у которого было множество успехов и неудач в различных областях, а не того, кто умеет работать всего одним проверенным способом.

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

Помню, я заговорил с другом о потенциальном уходе из корпорации, и он сказал мне: «Разве твоя судьба до конца дней работать в название_крупной_компании?». Нет, черт побери! Я быстро нашел другую работу и уволился.

Это движение положило четкое начало моему неравномерному подъему в индустрии программного обеспечения. Я знакомился с новыми областями, я работал над более сложными проблемами и получал за это куда более весомое вознаграждение, чем раньше. Временами мне бывало страшно, но когда я решил, что страх и консервативность не должны влиять на выбор моего пути, форма и характер моей карьеры – и моя жизнь – изменились к лучшему.

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

Как я променял $300 000 в Microsoft на полный рабочий день в GitHub

Том Престон-Вернер, один из основателей социальной сети GitHub

Шел 2008 високосный год. 366 дней назад почти минута в минуту я в одиночестве сидел в спорт-баре на Третьей улице Сан-Франциско. Обычно я не болтаюсь по барам, но в тот четверг была организована вечеринка «I Can Has Ruby». Уже в то время я считал, что слова «I can has…»⁶ можно добавить к чему угодно. В данном случае речь шла о полузакрытом сборище Ruby-программистов, которое быстро превратилось в обычную ночную пьянку. Воспоминания о подобных развлечениях, как правило, исчезают, как только проходит утреннее похмелье. Но не на этот раз. Ведь этой ночью родилась социальная сеть GitHub.

Я занял отдельный кабинет, заказал бокал холодного пива и хотел отдохнуть от бурного общения за длинными столами в тускло освещенной задней части бара. Не успел я сделать пять или шесть глотков, как ко мне вошел Крис Ванстрас. Сейчас и не вспомню, воспринимал ли я его тогда как друга. Мы пересекались на встречах и конференциях, посвященных Ruby, но достаточно поверхностно – на уровне взаимного «Крутой код ты пишешь». Не помню, что меня подтолкнуло, но я сделал приглашающий жест и произнес: «Дружище, ты только глянь». Неделей раньше я начал работу над проектом Grit, который позволял мне через Ruby-код в объектно-ориентированном стиле получить доступ к Git-репозиториям. В то время Крис был одним из немногих Ruby-программистов, серьезно относящихся к системе Git. Он сел, и я начал демонстрировать ему немногочисленные наработки. Но этого оказалось достаточно, чтобы Криса охватил приступ энтузиазма. Почувствовав его настроение, я поделился еще не оформившейся до конца идеей создания сайта, который будет работать как центр обмена Git-репозиториями отдельных кодеров. Я даже придумал для него имя: GitHub. Возможно, я несколько искажаю его слова, но высказался он решительно: «Я в деле!»

Следующей ночью – в пятницу, 19 октября 2007 года, в 22:24, – Крис сделал первый вклад в репозиторий GitHub и оставил запись о запуске нашего совместного детища.

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

Помните потрясающую сцену из фильма «Парень-каратист»? Ту самую тренировку Дэниэла, когда он превращается в мастера боевых искусств. Помните эту музыку? Думаю, вам нужно еще раз послушать песню Джо Эспозито «You’re the Best», так как я собираюсь сразу перейти к сути.

В течение следующих трех месяцев мы с Крисом провели много восхитительных часов, занимаясь проектом GitHub и написанием кода. Я продолжал работать над Grit и пользовательским интерфейсом. Крис разрабатывал приложение Rails. По субботам мы встречались для обсуждения проекта и ломали голову над будущим тарифным планом. Я помню один до ужаса дождливый день, когда мы добрых два часа рассматривали стратегии ценообразования, поедая лучшие в городе спринг-роллы. При этом мы выполняли и другие обязанности. Лично я был разработчиком инструментов в группе рейтинга и соответствия фирмы Powerset.

В середине января, три месяца проработав по ночам и выходным, мы разослали нашим друзьям приглашения на закрытое бета-тестирование. В середине февраля в проект пришел Пи Джей Хиет, ставший третьим соучредителем. Официальный запуск состоялся 10 апреля. TechCrunch об этом не информировали. На тот момент мы все еще были обычными программистами в возрасте чуть за двадцать, а у проекта отсутствовали сторонние инвесторы.

Я все еще работал в Powerset, когда 1 июля 2008 года стало известно, что эту фирму примерно за сто миллионов долларов покупает корпорация Microsoft. Момент был достаточно интересным, ведь мне предстояло сделать выбор гораздо раньше, чем я предполагал. Можно было стать сотрудником Microsoft или уйти и полностью посвятить себя GitHub. Мне было 29, и я был старше своих компаньонов, успев как накопить больше долгов, так и привыкнуть к большим ежемесячным расходам. Мой образ жизни был достаточно роскошным. Кроме того, приближался момент, когда моя жена Тереза должна была вернуться из Коста-Рики, где она занималась сбором данных для своей диссертации. А значит, пора было оставить временные холостяцкие привычки и снова жить как семейный человек.

Еще сильнее осложнил мой выбор тот факт, что в Microsoft мне предложили крайне заманчивые условия. Оклад и лакомые $300 000 на протяжении трех лет. Вполне достойная сумма, чтобы заставить серьезно задуматься кого угодно. В итоге мне пришлось выбирать между стабильной и надежной работой с гарантированно высокой зарплатой в Microsoft и рискованной тропой частного предпринимателя с неизвестным уровнем дохода. Останься я в Powerset, мои отношения с ребятами из GitHub неминуемо обострились бы. Ведь они некоторое время назад, подкопив денег, ушли в свободное плавание, чтобы посвящать все свое время проекту GitHub. Это был момент, когда на карту было поставлено все. Я должен был либо полностью включиться в работу над GitHub, либо навсегда забыть о нем, предпочтя большие деньги от Microsoft.

Если вам нужен рецепт бессонных ночей, могу поделиться. Смешайте страх «Что подумает моя жена?» и 3000 стодолларовых бумажек, взболтайте с «пивом в любое время, когда захочется» и приправьте шансом на финансовую независимость.

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

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

Действуй!

1. Определи свои самые серьезные страхи, связанные с карьерой. Вспомни последние принятые в этом направлении решения. В этот список должны попасть не только ответственные решения (в конце концов, если твой выбор определяется страхом, ответственных решений, скорее всего, не было). Это могут быть взятые на себя дополнительные обязанности, заявление о смене работы или повышении. Когда список будет готов, честно оцени каждый из пунктов: насколько твоим решением в данной ситуации управлял страх? Что бы ты сделал, если бы страха не было? Если решение было принято под влиянием страха, как изменить его или найти аналогичную ситуацию, в которой можно будет действовать уже более взвешенно и обдуманно?