Программист-фанатик читать онлайн - Чед Фаулер

Программист-фанатик

Чед Фаулер

Библиотека программиста (Питер)

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

Чед Фаулер

Программист-фанатик

© Pragmatic Bookshelf; 2 edition (June 4, 2009)

© Перевод на русский язык ООО Издательство «Питер», 2015

© Издание на русском языке, оформление ООО Издательство «Питер», 2015

* * *

Для Келли Джин

Предисловие

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

До того как я зажегся проектами 37signals и Ruby on Rails, я прошел через множество работ и заданий, которые вовсе не соответствовали определению «незаурядный». Я торговал водой, и дни были похожи друг на друга, как две капли. Прежде чем я это осознал, прошло 6 месяцев, и они не дали мне абсолютно ничего. Чувство горечи было отвратительным.

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

И когда я такого следа не оставлял, это сказывалось и на моей личной жизни. Если я не чувствовал куража во время работы в офисе, становилось все труднее преодолевать себя и начать действовать.

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

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

Дэвид Хэйнемер Хэнсон (David Heinemeier Hansson), создатель проекта Ruby on Rails и партнер проекта 37signals

Благодарности

Я бы никогда не написал эту книгу, если бы не Дэйв Томас и Энди Хант. Их книга «Программист-прагматик. От подмастерья к мастеру» (The Pragmatic Programmer: From Journeyman to Master) стала катализатором и вдохновляющей силой. Если бы не поддержка и руководство Дэйва, я бы так и считал себя недостаточно квалифицированным для написания этой книги.

Сюзанна Пфальцер (Susannah Pfalzer) редактировала второе издание книги. Под редактированием я подразумеваю подталкивание, воодушевление, вдохновение, руководство и, конечно… собственно редактирование. Ее терпение и умение найти правильные слова, мотивируя меня, а не пугая, – это как раз то, что было так необходимо для завершения работы. Если бы не Сюзанна, книга так и осталась бы набором сумбурных, не до конца сформулированных идей.

Хочу поблагодарить Дэвида Хэйнемера Хэнсона (David Heinemeier Hansson), написавшего предисловие. Его карьера в 37signals и Rails – это блестящий пример воплощения идей, лежащих в основе этой книги. Я рад, что в мой труд внесли вклад и другие незаурядные люди, с которыми я сталкивался на протяжении своей карьеры. Огромное спасибо Стефену Акерсу (Stephen Akers), Джеймсу Дункану Дэвидсону (James Duncan Davidson), Вику Чадха (Vik Chadha), Майку Кларку (Mike Clark), Патрику Коллисону (Patrick Collison) и Тому Престену-Вернеру (Tom Preston-Werner), которые вдохновляли и меня, и читателей.

Спасибо рецензентам за ценные замечания, которые помогли в подготовке второго издания. Всегда удивительно, насколько неправильна может быть исходная версия главы и насколько правильной ее может сделать хороший рецензент. Спасибо Сэмми Лэрби (Sammy Larbi), Брайну Дайку (Bryan Dyck), Бобу Мартину (Bob Martin), Кенту Беку (Kent Beck), Алану Фрэнсису (Alan Francis), Джареду Ричардсону (Jared Richardson), Ричу Доуни (Rich Downie) и Эрику Костнеру (Erik Kastner).

Не могу не упомянуть Джульет Томас (Juliet Thomas), редактировавшую первое издание книги. Ее энтузиазм и видение перспектив были неоценимы. Я получил огромное количество отзывов от рецензентов первого издания: Кэри Боаз (Carey Boaz), Карла Брофей (Karl Brophey), Брэндона Кэмбэла (Brandon Campbell), Вика Чадха (Vik Chadha), Мауро Чичио (Mauro Cicio), Марка Донохью (Mark Donoghue), Пэта Эйлера (Pat Eyler), Бэна Гудвина (Ben Goodwin), Якоба Харриса (Jacob Harris), Адама Кейса (Adam Keys), Стива Морриса (Steve Morris), Билла Налла (Bill Nall), Уэсли Рейза (Wesley Reiz), Авика Сенгупта (Avik Sengupta), Кента Спиллнера (Kent Spillner), Сандеша Таттитали (Sandesh Tattitali), Крэйга Утли (Craig Utley), Грега Вона (Greg Vaughn) и Питера У. А. Вуда (Peter W. A. Wood). Они помогли сделать книгу значительно лучше, и я никогда не смогу отблагодарить их за потраченное время, силы и проявленное понимание.

Спасибо всем прекрасным людям, с которыми я работал как официально, так и не официально, за идеи, легшие в основу этой книги. Спасибо за то, что выслушали, научили и просто общались, Донни Уэббу (Donnie Webb), Кену Смиту (Ken Smith), Уолтеру Хоэ (Walter Hoehn), Джеймсу Макмюрри (James McMurry), Кэри Боаз, Дэвиду Алану Блэку (David Alan Black), Майку Кларку, Николь Кларк (Nicole Clark), Вику Чадха, Ави Брайнт (Avi Bryant), Ричу Килмеру (Rich Kilmer), Стиву Акерсу (Steve Akers), Марку Гарднеру (Mark Gardener), Райну Оуненсу (Ryan Ownens), Тому Копелэнду (Tom Copeland), Дэйву Крэйну (Dave Craine), Джону Афайду (John Athayde), Марселю Молина (Marcel Molina), Эрику Костнеру (Erik Kastner), Брюсу Уильямсу (Bruce Williams), Дэвиду Хэйнемеру Хэнсону (David Heinemeier Hansson), Али Сареа (Ali Sareea) и Джиму Уэричу (Jim Weirich).

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

Введение

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

Книга о том, как взрастить в себе желание быть незаурядным. Удивительно, но когда мы начинаем строить карьеру, далеко не в каждом живет стремление стать незаурядным. Большинство из нас просто плывет по течению. Причем СМИ, друзья, знакомые и родные лишь занижают наши ожидания. Поэтому, чтобы сделать свою жизнь незаурядной, ты должен поставить себе цель, а это совсем не очевидно.

Большинство взрослых людей подавляющую часть своего времени

проводят на работе, а по статистике[1 - http://www.bls.gov/tus/charts/] за 2006 г., средний американец провел на работе половину жизни. Отдых и занятия спортом далеко позади и занимают лишь 15 % времени бодрствования. Факты говорят о том, что наша жизнь в основном проходит на работе.

Если бо?льшая часть жизни поглощена работой, то любовь к работе – один из важнейших способов возлюбить собственную жизнь. Интересная, мотивирующая и достойно оплачиваемая работа будит тебя по утрам гораздо лучше, чем скучные и тривиальные обязанности. Если ты хорошо работаешь, значит, 50 % времени ты занят тем, в чем ты действительно хорош. И наоборот, если ты работаешь плохо, то бо?льшую часть времени ты чувствуешь себя некомпетентным или виновным в том, что не способен сделать должным образом.

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

Был бы я счастливее, имея больше денег? Был бы я счастливее, если бы мои достижения больше ценились? Был бы я счастливее, если бы меня повысили? А если бы я стал знаменит? А если бы я был беден и имел самую обычную работу, то мог бы я быть счастлив? Возможно ли это? И если да, то стоит ли тогда гнаться за деньгами или лучшей работой?

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

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

Не ведая преград!

По иронии судьбы одним из важнейших этапов на пути построения незаурядной карьеры для меня стало первое издание этой книги. Она называлась «Моя работа досталась индусам (а все, что получил я, – эта жалкая книжонка), или 52 способа сохранить работу» (My Job Went to India (And All I Got Was This Lousy Book): 52 Ways to Save Your Job). На обложке был изображен парень с табличкой «Код за еду». Это было прикольно, а название и шокирующая красная обложка обыгрывали страх Западного мира, что всю работу захватят гастарбайтеры из развивающихся стран.

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

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

Как-то вечером после работы я просматривал полки в ближайшем книжном магазине и увидел среди новинок книгу Кента Бека «Экстремальное программирование» (Extreme Programming Explained. Embrace Change). Идея любить перемены всегда была мне близка. До того момента у меня всегда были сложности с усидчивостью, я переходил с одной работы на другую, часто меняя работодателей. Хотя описание «методологии разработки ПО» казалось мне невыносимо скучным и отдавало менторством, я решил, что если эта методология поддерживает постоянные перемены, это может помочь мне не скучать и не думать о том, чтобы очередной раз поменять работу.

Покупка этой книги оказалась моей удачей. Начав читать, я уже не мог оторваться, потом я прочел все, что нашел в интернете об экстремальном программировании (Extreme Programming, XP). Эти идеи захватили меня настолько, что я обратился к руководителю информационной службы, пытаясь и его приобщить в своей новой религии. Это мне удалось, и для внедрения экстремального программирования он отправил меня и многих моих коллег на соответствующие курсы.

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

Мой коллега Стив, автор одного из эссе, вошедших в эту книгу, и я пришли к одинаковому выводу. Единственный путь общаться с такими людьми как можно чаще – стать одним из них. Другими словами, если я хочу оказаться в компании людей, поднимающих меня на один-два уровня выше, то проблема не в фирме, в которой я работаю, и не в курсах, которые я посещаю. Я просто должен понять, чем эти люди отличаются от прочих, и постараться стать одним из них. Это я и сказал Стиву.

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

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

Однако, несмотря на то что у меня не было профессиональной подготовки обычного разработчика ПО, мой опыт музыканта дал мне возможность пропустить эту ступеньку и не стать обычным программистом (кому охота быть обычным?). Никто не становится музыкантом, чтобы вести

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

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

Ты должен

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

Как составить такой план? Разработка программ – это бизнес. Как программисты, мы являемся еще и бизнесменами. Наши компании наняли нас вовсе не потому, что любят нас. Этого никогда не было и не будет. Просто потому, что не имеет отношения к бизнесу. Компании существуют совсем не для того, чтобы нам каждый день было куда пойти. Цель бизнеса – делать деньги. Чтобы преуспеть в компании, ты должен четко представлять себе, как ты вписываешься в план добывания денег.

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

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

? Выбери рынок. Осознанно и осторожно подбери технологии и сферы бизнеса, на которых ты будешь концентрироваться. Как сбалансировать риски и отдачу? Как учесть фактор спроса и предложения?

? Инвестируй в свой продукт. Твои знания и навыки – это краеугольный камень всего продукта. Правильные инвестиции в них – ключ к хорошему спросу на рынке труда. Просто знать Visual Basic или Java уже недостаточно. Какие еще навыки могут тебе понадобиться в новых экономических условиях?

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

? Продавай! Даже самый лучший продукт не будет продаваться, если о его существовании никто не знает. Как без заискивания получить признание в компании и в отрасли в целом?

Новое издание

Это уже второе издание книги «Моя работа досталась индусам (а все, что получил я, – эта жалкая книжонка), или 52 способа сохранить работу» (My Job Went to India (And All I Got Was This Lousy Book): 52 Ways to Save Your Job). Цель переиздания – дополнительно сконцентрироваться на основной теме: создании грандиозной карьеры. Для этого я не только придумал более позитивное название, но и изменил содержание.

Дэвид Хэйнемер Хэнсон, создатель Ruby on Rails и партнер в проекте 37signals, написал новое вступительное слово.

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

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

К советам, которые были в первом издании, добавлены новые разделы «Действуй!»

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

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

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

Часть I. Найди свой рынок

Ты собираешься сделать крупные инвестиции. Я подразумеваю не большие денежные суммы, а твое время – твою жизнь. Большинство не привыкло прикладывать усилий к построению своей карьеры, предпочитая плыть по течению. Человек изучает язык Java или Visual Basic, и в какой-то момент работодатель оплачивает ему курсы повышения квалификации для знакомства с последними новинками отрасли. И снова начинается рутинная работа, пока не появится очередная направляющая сила. В итоге карьера целиком зависит от стечения обстоятельств.

Дэйв Томас и Энди Хант в книге «Программист-прагматик: путь от подмастерья к мастеру» (The Pragmatic Programmer: From Journeyman to Master) рассказывают о программировании в расчете на совпадения. Большинство программистов начинают работать над задачей, добавляя небольшие фрагменты кода. Иногда просто берется фрагмент кода с сайта и редактируется под собственные нужды. Принцип работы программы при этом остается непонятым, но в нее вносятся многочисленные коррективы, пока она не начнет соответствовать текущим надобностям. Полученный таким образом продукт напоминает карточный домик, и добавление каждой следующей подсистемы повышает вероятность сбоя.

Любой разработчик программного обеспечения понимает порочность подобного подхода. При этом собственный карьерный рост многие оставляют на волю случая. Каким технологиям следует уделить повышенное внимание? Эксперты в какой области являются самыми востребованными? Что лучше – расширять кругозор или углублять свои знания? Мы просто обязаны задавать себе все эти вопросы.

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

Так почему же большинство из нас не столь тщательно

относятся к решениям, связанным с карьерным ростом? Если взглянуть на карьеру как бизнес (а так оно и есть), твоим «продуктом» будут те услуги, которые ты в состоянии оказать.

Что это за услуги? Кому ты собираешься их продавать? Возрастет или сократится спрос на них в будущем? Насколько ты готов рискнуть, делая выбор?

Ответы на все эти важные вопросы поможет найти первая часть книги.

Совет 1. Будь впереди или погибнешь?

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

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

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

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

Если бы в то время ты обратил внимание на язык Java, разработанный компанией Sun Microsystems, тебе пришлось бы поискать фирму, в которой этот язык был бы востребован. Кто знал, будет ли вообще нужен Java?

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

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

А теперь представь, что 15 лет назад ты участвовал в презентации новой операционной системы BeOS от фирмы Be. Это было что-то невероятное. Она создавалась для поддержки многопроцессорной архитектуры. Мультимедийные возможности поражали. Платформа наделала много шума и вскружила голову специалистам, которые ждали появления нового сильного игрока на рынке операционных систем. Должны были родиться новые способы программирования, новые API и новые концепции пользовательского интерфейса. Приходилось многое изучать «с нуля», но, казалось, дело того стоит. Приложив немало усилий, можно было создать первый FTP-клиент или программу-календарь для BeOS. Но сразу после выпуска Intel-совместимой версии операционной системы появились слухи, что Apple покупает фирму Be, которая собирается использовать разработанные технологии как основу для следующего поколения операционной системы Macintosh.

Apple не стала покупать Be. Более того, стало понятно, что Be не собирается захватывать даже узкоспециализированный рынок. Продукт просто не пришелся ко двору. Множество разработчиков, занимавшихся программированием для BeOS-окружения, медленно, но неуклонно понимали, что в долгосрочной перспективе их инвестиции себя не оправдали. В конечном счете Be приобрела компания Palm, и работа над операционной системой прекратилась. В данном случае мы имеем пример рискованных, хотя и привлекательных технологических инвестиций, которые не принесли долгосрочной выгоды вкладчикам. Награды за высокий риск не последовало.

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

Кто забьет этот гвоздь? Можно вспомнить, например, последних оставшихся седовласых и считающих часы до пенсии программистов на языке RPG, о котором молодое поколение даже не слышало. Сейчас все увлечены Java и. NET. Легко представить, как карьеры последних приверженцев устаревшей и умирающей технологии движутся по той же самой смертельной спирали, что и сама технология.

Старые системы умирают не сразу. Их замещают другие технологии. В большинстве случаев это многоэтапный процесс. И пока он протекает, старые системы должны взаимодействовать с новыми. Нужен человек, знающий, как склеить старое и новое. Молодежь, как правило, не знает (или не хочет знать), с какой стороны подойти к старой системе. А закосневшие в своей любви к старым системам специалисты пенсионного возраста не имеют представления о способах перехода к новым технологиям.

Доходным может оказаться любой из концов кривой восприятия технологий

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

Кривая восприятия технологий имеет два конца. Насколько близко к ним ты готов подойти?

Действуй!

1. Составь список новых, самых популярных и угасающих технологий. Перенеси их на лист бумаги: слева должны оказаться только что заявившие о себе направления, а справа – идущие к своему логическому концу. Постарайся вспомнить как можно больше примеров для каждой части спектра. Тщательно оценивай их положение друг относительно друга.

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

Совет 2. Предложение и спрос

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

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

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

По мере наполнения рынка веб-дизайнерами началось расслоение на настоящих художников и приверженцев утилитарного подхода. Кроме того, конкуренция привела к снижению цен. В итоге возросло количество фирм, желающих быть представленными во Всемирной паутине. Те, кто не мог заплатить за первый сайт $5000, получили его за $500.

Разумеется, остались компании, готовые платить огромные деньги за фантастический сайт. А значит, некоторые веб-дизайнеры все еще могли рассчитывать на фантастическое вознаграждение.

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

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

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

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

Низкооплачиваемые программисты из стран третьего мира работают с относительно небольшим количеством технологий. В Индии полным-полно людей, пишущих на Java и работающих с. NET. Там множество специалистов по базам данных Oracle. Экспертов в области менее популярных технологий в этой группе намного меньше. Выбирая направление развития, учитывайте перспективы роста предложений в этой сфере и, как следствие, снижение зарплат.

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

Конкуренция среди программистов, работающих с платформой. NET, на десятки тысяч человек выше, чем среди тех, кто пишет программы на Python. В результате средняя цена такого специалиста сильно падает, что потенциально может привести к повышению спроса (то есть к созданию большего количества рабочих мест в этой области). В итоге у тебя не будет проблем с трудоустройством, но вряд ли зарплата будет тебя устраивать. Программистов на языке Python намного меньше, чем программистов для. NET, но и спрос на них невелик. Но если на рынке труда такой специалист будет стоить заметных денег, это привлечет людей, которые начнут предлагать эту услугу. Конкуренция повысится, и цена начнет падать.

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

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

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

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

Используй дисбаланс рынка труда.

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

Действуй!

1. Исследуй рынок труда. Какие технические навыки наиболее или наименее востребованы? В этом тебе помогут рекрутинговые сайты. Найди несколько сайтов офшорных компаний (или поговори с теми, кто работает в таких компаниях). Сравни навыки, которые требуются для работы в такой компании, с навыками, наиболее востребованными на рынке труда. Выдели те из

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

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

Совет 3. Умения писать код мало

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

По сути дела, технический специалист должен понимать принцип ведения бизнеса на куда более глубоком уровне, чем требуется для разработки программного обеспечения. На предыдущем месте работы мне довелось столкнуться с подобными специалистами. Команда, отвечающая за администрирование баз данных, состояла из людей, которых не слишком интересовали технологии баз данных как таковые. При первой встрече с ними я испытал недоумение. Почему эти люди работают в области информационных технологий? Хотя их техническая квалификация оставляла желать лучшего, это была особенная команда. Они не только хранили и защищали данные нашего предприятия, но и разбирались в его хозяйственно-экономической деятельности лучше любого из наших экономистов, занимающихся вопросами конъюнктуры. Именно знание и понимание всех аспектов бизнеса обеспечили им повышенный спрос на рынке труда. В то время как мы, компьютерные гики[2 - Гик (англ. geek) – человек, фанатично увлеченный чем-либо, чаще всего компьютерными технологиями. – Примеч. ред.], смотрели на них свысока, коммерческая структура, для которой они работали, оценила их по достоинству.

Умение разобраться в особенностях бизнеса должно стать неотъемлемой частью твоих навыков. Например, музыканту, который добавляет в репертуар новое произведение, недостаточно один раз его сыграть. Его следует по-настоящему выучить. Именно так следует воспринимать знание бизнес-сферы. Ты можешь поработать в отрасли медицинского страхования, но так и не понять, в чем состоит разница между EDI-транзакциями HIPAA 835 и HIPAA 837. А ведь именно знание подобных тонкостей выделило бы тебя из числа разработчиков программного обеспечения, квалификация которых аналогична твоей.

Можно быть «обычным программистом», но умеющим говорить с деловыми клиентами на их языке. Ты только представь, насколько упростилась бы твоя жизнь, если бы все, с кем тебе приходится иметь дело, понимали принципы разработки программного обеспечения. Не приходилось бы тратить время на объяснения, почему не стоит выводить по 30 000 записей на одной странице веб-приложения или почему ссылки не должны вести на сервер разработки. Клиенты испытывают по отношению к тебе совершенно аналогичные чувства. Им хотелось бы работать с программистами, которые сразу понимают, что от них хотят, без объяснений на пальцах и абсурдного рассмотрения мельчайших деталей! А ведь именно они платят тебе деньги.

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

Самое время выбрать сферу бизнеса, на изучение которой ты будешь тратить свое время

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

Действуй!

1. Пригласи на обед знакомого бизнесмена и поговори с ним о его работе. Подумай, что бы ты хотел изменить или изучить, если бы собрался потрудиться в этой области. Расспроси об особенностях трудовых будней. Узнай, как в выполнении рабочих обязанностей помогают (или мешают) современные технологии. Взгляни на свою работу его глазами.

Сделай такие встречи регулярными.

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

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

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

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

Легендарный джазовый гитарист Патрик Мэтини дал начинающим музыкантам главный совет: «В какой бы группе ты ни был, всегда будь в ней худшим»[3 - http://clabs.org/blogki].

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

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

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

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

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

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

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

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

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

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

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

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

Действуй!

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

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

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

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

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

Компания TIOBE Software воспользовалась поисковыми службами интернета для определения относительной популярности языков программирования. За основу были взяты обсуждения различных языков[4 - http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html]. На сайте написано, что «общемировой рейтинг составлен по информации о наличии квалифицированных инженеров, курсов и независимых производителей». Разумеется, речь не идет о научно обоснованной оценке, но тенденции говорят сами за себя.

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

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

Поль Грэм в статье «Великие хакеры»[5 - http://paulgraham.com/gh.html] утверждал, что программисты, пишущие на 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…»[6 - Намеренно неграмотно написанная фраза «могу ли я получить…?»] можно добавить к чему угодно. В данном случае речь шла о полузакрытом сборище 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. Определи свои самые серьезные страхи, связанные с карьерой. Вспомни последние принятые в этом направлении решения. В этот список должны попасть не только ответственные решения (в конце концов, если твой выбор определяется страхом, ответственных решений, скорее всего, не было). Это могут быть взятые на себя дополнительные обязанности, заявление о смене работы или повышении. Когда список будет готов, честно оцени каждый из пунктов: насколько твоим решением в данной ситуации управлял страх? Что бы ты сделал, если бы страха не было? Если решение было принято под влиянием страха, как изменить его или найти аналогичную ситуацию, в которой можно будет действовать уже более взвешенно и обдуманно?

Совет 7. Будь универсалом

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

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

Все сотрудники так называемой фабрики по производству программ являются специалистами. Они занимают свои места в конвейерной цепочке, при помощи своих инструментов соединяя друг с другом Java-компоненты или шлифуя шероховатости приложений, написанных на языке Visual Basic. Инспектор № 12 работает тестировщиком. К нему стекаются компоненты программ, и он каждый день единообразно проверяет их и ставит штамп. J2EE-проектировщики создают J2EE-приложения. C-кодеры пишут код на языке C. Это крайне простой и поделенный на четкие категории мир.

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

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

Что это за проблемы? Ты этого не знаешь. И я не знаю. Известно только, что они столько же разнообразны, как вопросы развертывания, как критические недостатки дизайна, которые следует быстро устранить и провести повторную реализацию, как интеграция неоднородных систем, как ситуативная генерация отчетов. Столкнувшись с настолько разнородным набором проблем, бедный инспектор номер 12 довольно быстро допустит сбой в своей работе.

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

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

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

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

Обычный кодер, тестировщик, дизайнер или проектировщик в моменты, когда работа над проектом приостанавливается, будет бить баклуши или заниматься имитацией деятельности. Обычный программист, работающий с J2EE, NET или UNIX, не сможет ничего внести в проект на стадиях, не имеющих отношения к его непосредственной области деятельности. И дело тут не в том, каким из звеньев производственной цепочки ты себя ощущаешь (а высшим звеном тут всегда будет разработчик архитектуры). Дело в том, насколько полезным ты можешь стать.

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

Универсалы встречаются редко… и потому ценятся особо высоко.

Чтобы стать универсалом, нужно не связывать себя с определенной ролью или технологией. Определить свое место можно разными способами. Чтобы лучше представить себе возможности универсала, имеет смысл разбить перспективы карьеры в IT на набор независимых аспектов. Я выделил пять, но на самом деле их может быть бесконечное количество (все зависит от того, как лично вы делите темы):

? ступенька карьерной лестницы;

? платформа/ОС;

? код в сравнении с данными;

? системы в сравнении с приложениями;

? бизнес в сравнении с IT.

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

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

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

Еще одна искусственная (и непозволительная) граница разделяет платформы и операционные системы. Все более непрактично становится быть специалистом по UNIX, отказывающимся работать с Windows. То же самое касается. NET и J2EE и любых других инфраструктурных платформ. Долгосрочные перспективы на рабочем месте требуют независимости от платформы. У каждого из нас есть свои предпочтения, но их лучше оставить дома. Стань экспертом в одном и как следует разберись во всем остальном. Платформа – только инструмент. Специалиста по Windows можно нанять и на Филиппинах. А вот того, кто реально разбирается в разработке для Windows и UNIX и может помочь с интеграцией в обеих системах, лучше поискать в собственной стране. От подобных навыков не стоит отказываться, так как они относятся к умению работать в команде.

Также сложно провести водораздел между администратором баз данных (должность, которая в прошедшее десятилетие появилась буквально из ниоткуда) и разработчиком программного обеспечения. Во многих организациях администраторы баз данных (DataBase Administrator, DBA) знают, как использовать кое-какие инструменты администрирования и как установить конкретный программный продукт. От них не требуют умения использовать базы данных. Разработчики программного обеспечения со своей стороны ленятся работать с базами, а порой и плохо представляют, как это делается. В итоге одно цепляется за другое.

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

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

Действуй!

1. Составь список областей, в которых ты можешь или не можешь обобщить свои знания и умения. Укажи свою специализацию в каждой из сфер. Например, для Платформа и операционная система можно записать Windows.NET. Справа от своей специализации перечисли то, что ты собираешься изучать. В приведенном примере можно написать Linux и Java (или даже Ruby или Perl).

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

Совет 8. Будь специалистом

«Как бы вы написали на Java программу, которая уронит виртуальную машину Java?» А в ответ – тишина… «Эй, как вас там? Ау!»

«Извините, я вас не понимаю. Вы не могли бы повторить вопрос?» В голосе послышалось отчаяние. По опыту я знал, что повторение вопроса вряд ли чему-то поможет. Поэтому я повторил вопрос медленно и громко. «Как бы вы написали на Java программу, которая уронит виртуальную машину Java?»

«Э-э-э… прошу прощения. Я раньше никогда этого не делал».

«Я уверен, что не делали. Но что там с вопросом: как бы вы написали на языке Java программу, которая НЕ будет приводить к падению JVM?»

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

высоко себя ценит, что мешает ему придумать трюк, выводящий виртуальную машину Java из строя?

Это недостаток технической подготовки.

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

Многие из нас считают, что термин «специализация» означает неумение разбираться в других вещах. Согласно такой трактовке я могу заявить, что моя мать специализируется в Windows, ведь она никогда не работала ни с Linux, ни с OS X. А мои родственники из арканзасской глубинки окажутся специалистами по кантри, потому что они никогда не слушали другой музыки.

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

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

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

Так что же представляет собой специалист в области программного обеспечения? Кого я повсюду искал во время вербовочной поездки? Мне требовались люди, отменно разбирающиеся в программировании на языке Java и среде развертывания. Я хотел ребят, в 80 % случаев говорящих «это мне уже знакомо», глубина знаний которых позволяла бы решить проблему и в оставшихся 20 %. Я жаждал найти того, кто, работая с высокоуровневыми абстракциями, разбирался бы в деталях, лежащих в основе их реализации. Мне был нужен человек, умеющий справляться с возникающими при развертывании проблемами или хотя бы знающий, к кому можно обратиться по конкретному вопросу.

Именно такой специалист выживет в меняющейся компьютерной отрасли. Если ты специалист по. NET, это вовсе не оправдывает тот факт, что ты не разбираешься ни в чем, кроме.NET. Это лишь означает, что ты являешься экспертом во всем, что касается. NET. Зависли и нуждаются в перезагрузке IIS-серверы? «Нет проблем». Интеграция системы управления версиями с Visual Studio.NET? «Я покажу вам, как это сделать». Клиент хочет отказаться от обслуживания из-за непонятных проблем с производительностью? «Дайте мне тридцать минут».

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

Действуй!

1. Ты работаешь с языками программирования, которые компилируются и запускаются на виртуальной машине? Если да, найди время и разберись, как работает эта виртуальная машина. Существует множество книг и сайтов, посвященных виртуальным машинам для Java, NET и Smalltalk. Изучить этот материал проще, чем ты думаешь.

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

Откуда берутся внешние библиотеки, которыми ты пользуешься? Как на самом деле реализуется работа с внешней библиотекой? Каким образом компилятор, операционная система или виртуальная машина соединяет друг с другом многочисленные фрагменты кода, формируя однородную систему?

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

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

Совет 9. Не клади все свои яйца в чужую корзину

Во времена, когда я руководил группой разработки приложений, я поинтересовался у одного из своих подчиненных: «Что ты думаешь о своей карьере? Кем бы ты хотел стать?» Его ответ меня ужасно разочаровал: «Я хочу быть J2EE-разработчиком». Я спросил, почему не «проектировщиком Microsoft Word» или не «установщиком RealPlayer»?

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

Ориентировка на производителя, как правило, недальновидна.

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

Давай на секунду остановимся и вспомним, что карьера должна восприниматься, как бизнес. В принципе, построить бизнес, паразитирующий на другом бизнесе, возможно (например, фирмы, производящие продукцию для удаления шпионского ПО и латания дыр в системе безопасности браузеров от Microsoft), но для отдельного человека это крайне рискованный путь. Фирма сможет среагировать на изменение в расстановке сил на рынке, например неожиданный рост безопасности браузеров от Microsoft (или решение Microsoft выйти на рынок программ по удалению шпионского ПО), в то время как индивид вряд ли обладает способностями или излишками финансов, позволяющими резко изменить направление или фокус своей

карьеры.

Ставить во главу угла производителей не имеет смысла еще и потому, что детали реализации программного обеспечения, как правило, держатся в секрете. Ты можешь изучать патентованное программное обеспечение ровно до границы, за которой начинается сервисное обслуживание. Это искусственный барьер, призванный не дать пользователям самостоятельно разобраться с возникающими проблемами. Компании возводят его, чтобы получить выгоду, продавая такую услугу, как техническая поддержка. Иногда это делается сознательно, а иногда является результатом защиты интеллектуальной собственности (когда, к примеру, не публикуется исходный код).

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

Вскоре ты обнаружишь, что твои взгляды естественным образом поменялись. В J2EE (или что ты там выбрал в качестве области специализации) на самом деле нет ничего особенного. Разобравшись в деталях реализации, ты поймешь принцип работы высокоуровневых концептуальных моделей. Ты начнешь осознавать, что как на Java, так и на любом другом языке или платформе распределенная архитектура в масштабе предприятия остается распределенной архитектурой в масштабе предприятия. Твой кругозор станет шире, а ум начнет открываться. Ты ощутишь, что концепции и шаблоны, которые понял и осмыслил твой мозг, куда более масштабируемы и универсальны, чем любые технологии производителей. И скажешь себе: «Производители могут приходить и уходить, я знаю, как спроектировать систему!»

Действуй!

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

Совет 10. Полюби или уходи

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

Переезд в Бангалор вызвал у меня настоящий восторг. Впервые за свою карьеру я ждал, что найду компанию технических специалистов, мыслящих так же, как я, и с такой же страстью к обучению. Я надеялся, что после работы мы будем собираться и вести глубокие философские дискуссии о методологиях и приемах разработки программного обеспечения. Я думал, что индийская Силиконовая долина переполнена мастерами, жаждущими достичь высот в деле разработки ПО.

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

Все как дома.

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

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

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

Через несколько дней до меня стала доходить ужасная правда. Эти люди понятия не имели, чем, черт возьми, они занимаются! Более того, некоторые смотрели, что я делаю, и конспектировали! И это были люди с учеными степенями в области вычислительной техники!

В первый момент мне показалось, что меня окружают идиоты. Ведь у меня вообще не было специального образования. Ночи я проводил, играя музыку в барах, а дни – играя в компьютерные игры. Я научился работать с компьютером просто потому, что мне это было интересно. Скажу честно, я учился писать программы, чтобы создавать собственные компьютерные игры. Я возвращался домой после оглушительного вечера в баре и до восхода солнца исследовал Gopher-сайты[7 - Протокол Gopher представлял собой систему обмена документами, имеющую ту же цель, что и Всемирная паутина. С появлением интернета его популярность резко пошла на убыль.] с обучающими материалами. Затем я ложился спать, просыпался и продолжал изучение до момента, когда снова нужно было отправляться в бар. Я перемежал учебу моими любимыми компьютерными играми, ел и возвращался к экспериментам с протоколом Gopher и компиляторами, которые мне удавалось заполучить.

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

Именно это отличало меня от моих чрезмерно образованных, но недостаточно продуктивных коллег. Энтузиазм.

Работай потому, что не можешь не работать.

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

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

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

сможет стать вторым Моцартом или Колтрейном. Но мы можем избежать посредственности, найдя работу, которая нас по-настоящему увлечет.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию (http://www.litres.ru/ched-fauler/programmist-fanatik-3/?lfrom=931425718) на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

notes

Примечания

1

http://www.bls.gov/tus/charts/

2

Гик (англ. geek) – человек, фанатично увлеченный чем-либо, чаще всего компьютерными технологиями. – Примеч. ред.

3

http://clabs.org/blogki

4

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

5

http://paulgraham.com/gh.html

6

Намеренно неграмотно написанная фраза «могу ли я получить…?»

7

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