Чед Фаулер - Программист-фанатик
Следующей ночью — в пятницу, 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. Определи свои самые серьезные страхи, связанные с карьерой. Вспомни последние принятые в этом направлении решения. В этот список должны попасть не только ответственные решения (в конце концов, если твой выбор определяется страхом, ответственных решений, скорее всего, не было). Это могут быть взятые на себя дополнительные обязанности, заявление о смене работы или повышении. Когда список будет готов, честно оцени каждый из пунктов: насколько твоим решением в данной ситуации управлял страх? Что бы ты сделал, если бы страха не было? Если решение было принято под влиянием страха, как изменить его или найти аналогичную ситуацию, в которой можно будет действовать уже более взвешенно и обдуманно?
Совет 7
Будь универсалом
По меньшей мере пару десятилетий доведенные до отчаяния менеджеры и предприниматели делают вид, что разработка программного обеспечения представляет собой технологический процесс. Пишутся технические требования, а архитекторы воплощают их в высокоуровневых проектах. Проектировщики дополняют их подробной проектной документацией, которая затем передается кодерам, напоминающим роботов. В одной руке они держат описание задачи, а другой сонно набирают реализацию проекта. Готовый код получает инспектор номер 12, который никогда не поставит гриф «Согласовано» при несоответствии исходным техническим требованиям.
Тому, что менеджеры хотят превратить разработку программного обеспечения в производство, удивляться не стоит. Менеджеры понимают, как управлять производством. Многолетний опыт научил нас эффективно и точно создавать физические объекты. Значит, применив те же самые принципы, мы сможем оптимизировать процесс разработки программного обеспечения, превратив его в такой же хорошо отлаженный механизм, как фабричное производство.
Все сотрудники так называемой фабрики по производству программ являются специалистами. Они занимают свои места в конвейерной цепочке, при помощи своих инструментов соединяя друг с другом Java-компоненты или шлифуя шероховатости приложений, написанных на языке Visual Basic. Инспектор № 12 работает тестировщиком. К нему стекаются компоненты программ, и он каждый день единообразно проверяет их и ставит штамп. J2EE-проектировщики создают J2EE-приложения. C-кодеры пишут код на языке C. Это крайне простой и поделенный на четкие категории мир.
Но, к сожалению, аналогия с производством не работает. Программы должны быть не менее гибкими, чем требования к ним. В бизнесе все меняется, и бизнесмены знают, что программное обеспечение вполне можно изменить в соответствии с новыми требованиями. Это означает, что архитектура, дизайн, код и тесты должны создаваться и пересматриваться более динамично, чем может предложить самый рациональный производственный процесс.
В столь быстро меняющейся среде только гибкость позволит добиться превосходных результатов. В затруднительной ситуации умные бизнесмены обращаются к профессионалам, которые могут сразу решить проблему. Как же стать человеком, имя которого первым делом вспоминают, когда требуется супергерой, способный всех спасти? В данном случае все дело в умении решать все проблемы, которые только могут возникнуть.
Что это за проблемы? Ты этого не знаешь. И я не знаю. Известно только, что они столько же разнообразны, как вопросы развертывания, как критические недостатки дизайна, которые следует быстро устранить и провести повторную реализацию, как интеграция неоднородных систем, как ситуативная генерация отчетов. Столкнувшись с настолько разнородным набором проблем, бедный инспектор номер 12 довольно быстро допустит сбой в своей работе.
Поговорка «и швец, и жнец, и на дуде игрец» изначально имеет уничижительный смысл, подразумевая под собой человека, который из-за неумения концентрироваться не смог детально изучить ни одного дела и достичь в нем подлинного мастерства. Но когда приложение для покупок в твоем интернет-магазине перестает работать, каждый час лишая тебя заказов на сотни долларов, нужен человек, который не только знает, как функционирует код данного приложения, но и может произвести низкоуровневую отладку процессов на сервере, работающем под управлением UNIX, проанализировать конфигурацию системы управления реляционной базой данных на предмет влияющих на производительность «узких мест», проверить конфигурацию маршрутизатора. И, что куда важнее, обнаружив проблему, этот мастер на все руки сможет быстро принять решение по поводу архитектуры и дизайна, внести в код исправления и подготовить новую версию системы к работе. В подобной ситуации производственный сценарий в лучшем случае имеет странный, а в худшем — совершенно непригодный к применению в рамках производственного процесса вид.
