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

Автор книги: Чед Фаулер

сообщить о нарушении

Текущая страница: 3 (всего у книги 17 страниц) [доступный отрывок для чтения: 7 страниц]

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

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

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

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


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

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

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

Поль Грэм в статье «Великие хакеры»[5]5
  http://paulgraham.com/gh.html


[Закрыть] утверждал, что программисты, пишущие на 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]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).

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