Программист-фанатик бесплатное чтение

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

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

Предисловие

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

До того как я зажегся проектами 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] за 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], смотрели на них свысока, коммерческая структура, для которой они работали, оценила их по достоинству.

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

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

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

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

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

Действуй!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действуй!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действуй!

Изучи новый язык программирования. Не имеет смысла переходить с 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 выйти на рынок программ по удалению шпионского ПО), в то время как индивид вряд ли обладает способностями или излишками финансов, позволяющими резко изменить направление или фокус своей карьеры.

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

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

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

Действуй!

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

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

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

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

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

Все как дома.

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

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

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

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

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

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

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

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

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

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

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

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

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

Держи нос по ветру

Джеймс Дункан Дэвидсон, программист и фотограф

Моя карьера с самого начала развивалась нетрадиционно. Я всего лишь использовал все подворачивавшиеся мне возможности. Первая возможность появилась, когда я был еще в школе и писал дипломную работу по архитектуре. В возрасте 15 или 16 лет я решил, что хочу стать архитектором, и тратил много времени, вкладываясь в свое будущее. Но основой моей реальной карьеры послужило мое юношеское увлечение электронными досками объявлений. Я был из тех детей, которые обожали модем на 300-бод в семейном компьютере. В конце концов, это привело меня в Сеть, сначала в Gopher, а затем во Всемирную паутину.

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

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

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

Одно цеплялось за другое. В 1997 году я пришел в JavaSoft, где начал работать над приложениями, исполняющимися на стороне сервера, и, в конце концов, стал отвечать за спецификацию сервлетов. К сожалению, мои усилия финансировались в недостаточном объеме, кроме того, у меня не было команды, помогающей в решении актуальных задач, в том числе построении эталонной реализации. Однако меня это не остановило, итогом был JavaServer Web Development Kit. Немногие помнят эту программу. А вот о ее следующем выпуске знает большинство «серверных» Java-программистов: Tomcat был выпущен Apache Software Foundation одновременно со служебной программой Ant. История выхода этой версии достойна отдельной книги. Упомяну лишь тот факт, что все это сопровождалось удивительным количеством случайностей, которыми я смог воспользоваться.

Поработав на Sun четыре года и столкнувшись с вопросом «А дальше что?», я решил стать независимым. И начал писать книги для издательства O'Reilly. Разрабатывать программное обеспечение для Mac. Я создал изрядное количество программ, так и не дошедших до выпуска. В конце концов, я занялся разработкой Ruby on Rails. Мне нравится быть независимым разработчиком программного обеспечения, и у меня это хорошо получается. Фактически хобби, которым я увлекался, превратилось в профессию.

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

В 2005 году, через десять лет после того как я прекратил учиться на архитектора и переключился на разработку программного обеспечения, мне позвонили друзья из группы, занимающейся организацией конференций для O'Reilly Им требовался человек, который мог бы запечатлеть проводимое мероприятие, и меня спросили, не хочу ли я прийти и сделать несколько снимков. Я принял предложение, но несколько вышел за рамки данных мне инструкций. Я с удовольствием снял все важные заседания и с изумившей всех быстротой выложил фотографии на сайт Flickr. Меня снова пригласили на аналогичное мероприятие, и в течение следующих четырех лет благодаря большому количеству клиентов мне удалось открыть свое дело.

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

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

Действуй!

1. Найди работу, которая тебе по-настоящему интересна.

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

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

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

Часть II
Инвестируя в свой продукт

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

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

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

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

Возможно, все дело в том, что я постарел. Или поумнел, хотя в этом я сомневаюсь. Но теперь я понял, насколько большое значение могут иметь даже небольшие инвестиции в себя. Вместо того чтобы взять инструменты и отправиться на очередной концерт, я (в обязательном порядке) играл сам для себя. Это позволило мне более целенаправленно подойти к инструментам. Я слушал музыку и составлял список приемов, которые неплохо было бы изучить. Скажем, я всегда хотел делать такие же штуки, которые показывал в своих соло на саксофоне Фил Вудс. Или узнать, каким образом Принс в конце песни «Let's Go Crazy» из альбома Purple Rain заставляет свою гитару так визжать.

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

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

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

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

Совет 11
Учимся ловить рыбу

Лао-цзы сказал: «Дай человеку рыбу, и он будет сыт целый день. Научи его ловить рыбу, и он будет сыт всю жизнь». При всей верности этой поговорки Лао-цзы не учел, что бывают люди, не желающие учиться ловить рыбу. Такой человек предпочтет на следующий день попросить еще одну рыбу. В процессе обучения задействованы как учитель, так и ученик. Но многие из нас зачастую не испытывают желания учиться.

Не жди, пока тебе расскажут. Спрашивай сам!

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

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

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

Не менее важной является используемая тобой технологическая платформа. Например, ты можешь разрабатывать приложения с помощью J2EE. Тебе приходится создавать различные классы, интерфейсы и дескрипторы развертывания. Можешь ответить на вопрос: зачем? Знаешь, как применяются все эти вещи? Что происходит при запуске J2EE-контейнера? Даже если ты не являешься разработчиком сервера приложений, знание всех этих вещей позволит тебе писать надежный код для этой платформы и устранять неисправности, когда что-то идет не так.

Особенно располагают к лени различные модули, генерирующие за тебя код. Они весьма распространены среди Windows-разработчиков, так как Microsoft создала множество инструментов, предельно упрощающих решение многих задач. Оборотной стороной этого удобства стало появление множества разработчиков, не имеющих понятия о принципах работы своего кода. Происходящее внутри того или иного модуля остается для них мистической тайной. Не пойми меня неправильно — генерация кода может быть весьма полезной. Ведь именно она позволяет перевести высокоуровневый код C# в байтовый код, запускаемый в среде исполнения .NET. Не думаю, что тебе понравилось бы писать такой код вручную. Но применение высокоуровневых мастеров и модулей не способствует углублению твоих знаний. В итоге твои навыки ограничиваются умением работать с имеющимся инструментарием.

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

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

Действуй!

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

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

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

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

Ежедневно выделяй немного времени, чтобы изучить очередной аспект выбранного инструмента, позволяющий повысить продуктивность твоей деятельности или лучше контролировать среду разработки. Например, ты можешь выбрать для изучения командную оболочку Bourne Again Shell операционной системы GNU. Когда в очередной раз твой ум начнет уходить в сторону от рабочих задач, вместо загрузки привычного новостного сайта поищи в интернете советы по bash. В течение минуты-другой ты обязательно найдешь новую для себя полезную информацию по работе с этой оболочкой. А узнав новый прием, начинай препарировать его с помощью вопросов как и почему.

Совет 12
Разберись, как работает бизнес

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

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

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

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

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

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

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

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

Действуй!

1. Найди книгу по основам бизнеса и прочитай ее внимательно. Ищи среди книг для специалистов по управлению предприятиями. Могу порекомендовать тебе книгу Стивена Силбигера «MBA за 10 дней». Я считаю ее весьма полезной (и приятно лаконичной). Ее можно прочитать всего за десять дней, а это не очень большие затраты времени.

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

3. Попробуй повторить эти объяснения.

4. Разберись, почему чистая прибыль называется чистой.

Совет 13
Найди наставника

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

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

В профессиональной деятельности (особенно в сфере IT) просить чужой помощи не принято. Зачастую зависимость от другого человека считается признаком слабости. Мы боимся признать собственное несовершенство. Все пронизано духом конкуренции. Выживает сильный, и это закон. К сожалению, этот закон мешает развиться институту наставничества. Спроси я у группы джазовых музыкантов «Кто ваш наставник?», большинство из них ответит без проблем. А как будут реагировать на подобный вопрос программисты? Произвольно взятый программист из Соединенных Штатов, скорее всего, удивится: «Что?»

Так было не всегда. Западная история включает в себя развитую систему профессионального наставничества, уходящую корнями в Средневековье. Подход к профессиональному обучению был еще более сильным и формализованным, чем принятая в современном музыкальном сообществе система. Молодые люди начинали свою карьеру подмастерьями признанных мастеров. Работали за символическую плату и привилегию учиться у мастера. А тот, в свою очередь, был обязан обучить подмастерьев созданию вещей в собственной манере (и собственного качества).

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

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

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

Устроившись специалистом по поддержке систем, я взял в оборот Кена — святого человека, который работал в нашем университете одним из сетевых администраторов. Он помог мне решить серьезную проблему с NetWare-сетью нашего кампуса, проблему, из-за которой студенты не могли пользоваться компьютерным классом, и после этого отделаться от меня ему было уже сложно (впрочем, он и не пытался). Когда я спросил у него, в каком направлении следует двигаться, чтобы стать более компетентным и независимым, он дал мне простой рецепт: разберись со службами каталогов, научись работать с их UNIX-вариантом и как следует изучи язык сценариев.

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

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

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

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

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

Действуй!

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

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

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

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

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

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

Совет 14
Стань наставником

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

Я слышал, как Мартин Фаулер (Martin Fowler)^[8], выступая перед разработчиками в Бангалоре, сказал, что когда он хочет как следует что-то изучить, он об этом пишет. Мартин является известным разработчиком программного обеспечения и автором книг. Его можно назвать одним из самых выдающихся и влиятельных преподавателей в своей области, если рассматривать его книги как средство дистанционного обучения.

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

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

Чтобы понять, на самом ли деле ты хорошо разбираешься в теме, попробуй объяснить эту тему кому-то еще.

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

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

Для поиска учеников вовсе не нужно расхаживать с умным видом и объявлять себя знатоком. Здесь помогут только твоя компетентность и желание терпеливо делиться знаниями. Не стоит переживать об отсутствии доскональных знаний по теме. Скорее всего, у тебя есть некий опыт, который даст возможность помогать менее опытным товарищам. Определи, в какой сфере ты накопил достаточно опыта, и начинай приносить пользу.

Как правило, наставники не попадают под сокращение.

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

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

Действуй!

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

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

Совет 15
Практика, практика и еще раз практика

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

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

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

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

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

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

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

Тренируйся на пределе своих способностей.

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

♦ физические упражнения/координация;

♦ игра с листа;

♦ импровизация.

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

Физические упражнения/координация. Музыканты должны нарабатывать технику обращения с инструментом: генерация звука, координация движений (например, легкость перемещения пальцев), скорость и точность — все это крайне важно наработать.

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

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

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

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

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

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

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

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

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

Действуй!

1. TopCoder. TopCoder.com — это сайт корпорации, проводящей соревнования по спортивному программированию. Ты можешь зарегистрироваться там и участвовать в соревнованиях с призами. Для тех, кто не любит соревноваться с другими, на сайте есть раздел с набором задач, которые послужат прекрасной основой для отработки практических навыков. Регистрируйся и начинай заниматься.

2. Code Kata. Один из самых прагматичных программистов, наш любимый издатель Дэйв Томас (Dave Thomas), превратил идею наработки программистских навыков в… кое-что прагматичное. Его кодовая ката (code kata) — набор небольших, но провокационных упражнений. Программисты могут выполнять их на любом языке. Каждая ката делает упор на определенную технику или мыслительный процесс, нагружая один из твоих ментальных мускулов.

На момент написания этой книги Дэйвом была создана двадцать одна ката. Все они доступны в его блоге (http://codekata.pragprog.com/). Там же можно найти список рассылки и чужие решения этих упражнений, а также обсуждения способов решения.

Твоя задача — выполнить всё. Записывай результаты в дневник или веди блог. Закончив дело, напиши собственную кату и поделись ею с широкой публикой

Совет 16
Подход к работе

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

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

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

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

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

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

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

Чтобы почувствовать причастность к процессу разработки, помоги с его внедрением.

Возможен и вариант, когда ты работаешь в фирме, где производственный процесс спускается сверху. Здесь зачастую, когда инструкция добирается до группы разработчиков, к описанию технологических приемов добавляют столько лишних слов и интерпретируют их столь вольно, что они теряют свой первоначальный смысл. Инструкцию постигает судьба фразы в игре Испорченный телефон.^[9] Тут ты снова можешь взять на себя инициативу. Изучи спущенную сверху методику и помоги своей группе и руководству корректно интерпретировать описание рабочего процесса. Если ты не собираешься бороться против спускаемых сверху инструкций, по крайней мере обеспечь корректность их практической реализации.

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

Методики: Не только для зануд

Управление проектами далеко не всегда имеет отношение к методам разработки программного обеспечения, но ты можешь оказаться первым в своей компании, кто решил изучить данную тему. Многочисленные методики управления проектами широко используются во всей отрасли. Вероятно, самым известным является Свод знаний по управлению проектами (Project Management Book of Knowledge)^[10] от Института управления проектами (с его общепризнанной программой сертификации).

Шесть сигм (Six Sigma)^[11] — еще одна качественная методология, не связанная, впрочем, напрямую с программным обеспечением. Подход, продвигаемый такими монстрами, как General Electric и Motorola, придает особое значение измерению и анализу процессов и продукции для улучшения качества обслуживания клиентов и роста эффективности. Этот не имеющий отношения к разработке программного обеспечения, строгий и методичный подход предлагает данные, непосредственно применимые к работе программиста.

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

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

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

Действуй!

1. Выбери методику разработки программного обеспечения и найди посвященные ей ресурсы. Начни читать книги и сайты, присоединись к списку рассылки. Посмотри на эту методику критически. Выдели с твоей точки зрения сильные и слабые стороны. Что мешает внедрить ее на твоем рабочем месте? Изучи аналогичным способом еще одну методику. Сравни достоинства и недостатки обеих методик. Можешь ли ты скомбинировать предлагаемые подходы?

Совет 17
На плечах гигантов

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

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

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

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

Чтобы проникнуть в суть, анализируй чужой код.

Дизайн и программирование ПО в этом отношении во многом похожи на различные области искусства. В поисках шаблонов и трюков приходится анализировать огромные объемы готового кода. Образцы разработки, с которыми можно познакомиться в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования» (Design Patterns: Elements of Reusable Object-Oriented Software) появились как попытка обнаружить и документировать допускающие многократное использование решения часто возникающих при разработке программного обеспечения проблем. Они формализовали изучение существующего кода, сделав его доступным большому количеству профессионалов в области ПО. Тем не менее это всего лишь небольшой фрагмент обучающих практик, которыми мы можем воспользоваться посредством чтения кода.

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

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

Используй чужой код для оценки собственных способностей.

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

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

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

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

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

Действуй!

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

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

Совет 18
Автоматизация задач

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

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

Представь себе гипотетический проект по созданию программного обеспечения для какой-либо сферы по твоему выбору. Сколько программистов потребуется, чтобы написать такую программу за три месяца? Говоришь, пять? Шесть? (Потерпи минутку.) Хорошо. А как насчет выполнения этого проекта за два месяца? Как ты уберешь целый месяц?

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

Но достичь поставленной цели можно несколькими способами. Для увеличения объемов производства программного обеспечения можно:

♦ нанять тех, кто будет работать быстрее;

♦ нанять дополнительных работников;

♦ автоматизировать работу.

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

Это дает простую формулу, привязанную к фиксированному периоду времени:

Продуктивность = Количество проектов / (Количество программистов * Почасовая оплата)

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

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

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

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

Введя в формулу нашего финансового директора некоторые (вымышленные) цифры, мы получим показанное ниже уравнение.

Сравнение производительности

Быстрые программисты: 5 / (З * $80) = 0,02.

Дешевые программисты: 5 / (20 * $12) = 0,02.

Один программист + робот: 5 / (1 * $80) = 0,06

Автоматизация является неотъемлемой частью нашей отрасли. Но по каким-то причинам мы пока не хотим автоматизировать наш труд разработчиков программного обеспечения. Как гарантированно создавать программы быстрее и дешевле зарубежных конкурентов? Нужно сделать роботов. Автоматизируй свою работу!

От консультанта по вопросам информатизации до генерального директора

Вик Чадха, генеральный директор Enterprise Corp.

Путь от консультанта по информационным технологиям в General Electric до должности entrepreneur-in-residence^[12] в bCatalyst (бизнес-акселератор с фондом в 5 миллионов долларов) — вовсе не та карьера, о которой я мечтал.

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

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

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

Но какой бы замечательной ни была моя работ

© 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] за 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], смотрели на них свысока, коммерческая структура, для которой они работали, оценила их по достоинству.

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

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

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

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

Скачать книгу