Почему эта книга заслуживает перевода
Хочу поделиться своим мнением с хабрасообществом о книге «Passionate Programmer», перевод одной из глав которой представлен ниже. Книга вышла в 2009 году, но среди российских программистов она не очень широко известна, тем не менее многие, кто познакомился с ней, считают её очень достойной. Чад Фаулер (автор книги) выложился очень хорошо, чтобы передать читателям свой богатый опыт (на данный момент он CTO 6Wunderkinder, имеет более 20 лет стажа разработки и в виду своего большого опыта и круга интересов он желанный гость на Ruby- и IT-конференциях). Да, уже и не помню как нашёл эту книжку, но помню, что именно предисловие от Кента Бека (идейный вдохновитель Test Driven Development и Extreme Programming) послужило причиной прочитать её.
В этой книге нет описания конкретных технологий, алгоритмов и т.п., но есть просто куча советов, касательно того, с чем порой сталкивается любой разработчик: отсутствие мотивации, выбор приоритетов, психология программирования, отношения с руководством и коллегами; по большому счёту даётся масса наставлений, о том как сделать яркую карьеру программиста. Конечно, опытные разработчики могут найти некоторые его идеи достаточно очевидными, но для тех, кто только в самом начале своей карьеры, чтение данной книги, определённо, будет хорошим вложением времени. Большой плюс, что книга читается очень легко и, если вы достаточно хорошо владеете английским, её реально прочитать всего лишь за несколько дней. Просто интересно, почему наши издательства ещё не перевели её на русский язык?
После прочтения книги я заинтересовался Чадом. Нашёл его блог в сети. Как оказалось, он начал выкладывать в нём главы из своей книги (на данный момент опубликовано 2 главы из 53). Я спросил разрешения на перевод для хабра, он ответил, что это хорошая идея, но только сначала мне надо отправить ему письмо с тем, что конкретно я хочу переводить (видимо это пожелание было как-то связано с тем издательством, где была опубликована книга). После моего ответа неделю было молчание, я отправил повторное письмо — ответа снова не было. Потом я получил от него приглашение на Wunderlist (сервис, за который он отвечает на данный момент). В общем, я посчитал, что если явного запрета не было, а эти главы уже и так находятся в свободном доступе, и он ещё не совсем про меня забыл, то делать перевод можно. В общем, если перевод сообществу окажется полезным, я продолжу переводить другие главы. В тексте возможны ошибки, поэтому заранее прошу прощения и прошу сообщать мне о всех проблемах в тексте через личные сообщения.
Не паникуй
Я начал свою карьеру программиста, потому что любил компьютерные игры. С тех дней, когда игры запускались с кассет на моём Commodore 64, я был просто зачарован их интерактивностью и тем насколько глубоко они могли погрузить игрока в свой мир. Я стеснялся признать этот факт, но с течением времени понял, что в этом нет ничего зазорного. Как бы то ни было компьютерные игры превратили для меня картинку с экрана монитора в нечто большее, с чем я чувствовал себя комфортно, и что меня приводило в восторг.
Самой любимой игрой был Doom от id Software. Особенно мне нравился режим игры по сети против других игроков — deathmatch. Желающие поиграть между собой могли подключиться друг к другу через модем по телефонной линии или через обычное последовательное подключение и вести поединок на небольших локациях. Я был очень хорош в deathmatch. Я даже шутил, что это могло бы стать моей профессией — настолько я хорош в нём был. На удивление, поединок с другими игроками при своей простой цели по факту достаточно сложен. Он требует использования как хороших технических навыков игры, так и психологии — как безумный микс шахмат и быстрой перемотки вперёд.
Самый лучший способ прокачать навыки в своём деле — наблюдать за тем, как работает мастер. В те времена моего увлечения Doom, был один такой мастер, который был известен под ироничным ником «Noskill» («Безумения» — игра слов прим. переводчика). Noskill был царствующим чемпионом в Doom. Люди со всей Северной Америки могли оплачивать недешёвые счета за телефонную связь, лишь бы попытать счастье сыграть с ним. Поединки сохраняли с помощью встроенной в Doom функции записи. Я пересматривал каждую из них.
Для меня разгадка секрета мастерства Noskill не заняла много времени. Конечно, он был очень хорош в самой игре, но также был очевидный ключ к его успеху — он никогда не паниковал. Doom был такой игрой, раунд в которой мог завершится за считанные секунды после своего начала. Это было реально быстро. Я помню свой первый deathmatch: появился-умер-появился-умер-появился-умер. Когда в конечном счёте я мог оставаться в живых более чем несколько секунд, я обнаруживал себя бесцельно бегущим по коридору, едва ли понимая, где сейчас нахожусь.
Но Noskill никогда так не поступал. В этих записях было ясно видно, что насколько бы ни сложна была ситуация, он всегда был расслаблен и всегда знал о том, что делать дальше. И, казалось, что он всегда знал как текущий контекст вписывается в общую картину матча.
Теперь, если вы вспомните другие игры, в особенности спортивные, вы поймёте, что все лучшие игроки разделяют это качество. По факту даже персонажи из книг и фильмов, которыми мы восхищаемся, также разделяют это качество. Герои никогда не паникуют. У них может стрястись всё что угодно — ядерная бомба, нацеленная на их город или крушение самолёта, но при этом они всегда смогут найти подмогу, помочь выжившим, перехитрить врага или по крайней мере не разрыдаться.
Это также экстраполируется на реальную жизнь. Несмотря на все усилия в планировании моя профессиональная жизнь была чередой чрезвычайных ситуаций и бедствий. Проекты завершались с большими опозданиями. Мои программы падали, что стоило реальных денег моим работодателям и потери доверия ко мне. Я говорил нехорошие вещи нехорошему вице-президенту, взращивая политического врага. Обычно такие штуки накатывали волнами все вместе, они никогда не приходили по очереди.
В мои самые худшие моменты я паниковал. Я закрывался у себя и мог разрабатывать тактику, рассматривая каждое событие по отдельности, не имея представления о том, какая картина складывается в целом.
Но оглядываясь назад на все произошедшие бедствия, очевидно, что ни одно из них не оказало продолжительного, заметного влияния на мою карьеру. Как бы я ни паниковал, ни расстраивался, в каких бы масштабах депрессии не оказывался, я справлялся со всеми этими кажущимися опасными ситуациями, которые по существу такими не были.
Что это паникёрство мне дало? Ничего. Было ли преимущество в негативных реакциях на каждую из этих ситуаций? Нет. Чему, действительно, поспособствовала паника, так это неспособности быть лучшим в те моменты, когда мне действительно надо было быть лучшим.
Да, я вынужден признать, что просто советовать отпустить панику в стрессовой ситуации проще, чем реально применять этот совет на практике. Это типа того как сказать кому-нибудь: «Просто будь счастлив». Конечно, это хороший совет, но как это сделать? Как вы можете избежать состояния паники, когда кажется, что всё вокруг рушится? Для ответа на этот вопрос, нам надо немного подумать о том, почему мы паникуем.
Мы паникуем, когда теряем перспективу. Когда что-то идёт не так, сложно не фокусировать своё внимание на этом. Я не говорю, что это плохо, и даже до некоторой степени это хороший способ решать проблемы. Но, к сожалению, такой подход становится причиной другой проблемы: без разницы насколько бы ни была маленькой первичная проблема, начинает казаться, что важна только она. Проблема становится всё больше и больше, уровень стресса увеличивается, и в итоге наши мозги просто отключаются.
Кто самый худший пользователь компьютера из тех, кого вы знаете? Для меня это скорее всего один из моих родителей или один из родителей моей супруги (я знаю, кто это конкретно, но я достаточно умный, чтобы не писать здесь их имена). Представьте, что этот человек сидит перед своим компьютером, пытаясь завершить свой рабочий проект, когда начинает выскакивать сообщение ошибке, чтобы он ни пытался делать. Большинство из нас были свидетелями подобной ситуации. Неопытные пользователи компьютера мгновенно расстраиваются и начинают делать разные странные штуки. Они начинают лихорадочно кликать и перетаскивать окна туда-сюда, игнорируя потенциально полезный текст об ошибке, который появляется снова и снова. В конечном счёте они становятся так возбуждены, что звонят с просьбой о помощи, конечно, предварительно сделав полный бардак ещё в одной или двух сопутствующих системах, перед звонком.
Не думайте, что я злорадствую, просто я хочу обрисовать эту ситуацию с таким главным героем, кого вы предположительно знаете, и я хочу чтобы вы от души посмеялись над собой. Такое поведение нелепо. Не так ли?
Самое забавное в этом то, что мы представили сценарий из реальной жизни, в котором человек работает вне своей зоны комфорта, когда он сталкивается с проблемой и начинает паниковать. Это не сильно отличается от того, как я реагировал в те моменты, когда мои разработки не укладывались в сроки, неожиданно рушили систему или просто разочаровывали клиента. Это всё происходило просто в другом контексте.
Ну и вот, как я собственно научился не паниковать. Когда происходит что-то плохое и я начинаю чувствовать, что это выбивает меня из колеи и вот-вот приведёт к панике, я начинаю сравнивать себя с тем разочарованным пользователем и смеюсь над собой. Я анализирую ситуацию с позиции третьей стороны, как если бы помогал своему родственнику справиться с тем бушующим текстовым процессором. Внезапно та проблема, которая казалась сложной, становится лёгкой. И эта плохая ситуация, становится на самом деле не такой уж плохой. Я часто сталкиваюсь с тем, что решение многих проблем очень простое и буквально кричит мне в лицо, точно также как тот диалог с ошибкой, который сообщает, что надо делать дальше. Если ваш ум не убежал и вы можете прочитать сообщение об ошибке, проблема может быть решена.
Действуй!
1. Начните вести журнал паники. Суть — перехватить панику до того, как она возникнет. Это возможно, если вы будете развивать своё «реал-тайм» осознание возникающих ощущений и эмоций. Я научился делать это, анализируя реакции и ситуации уже после случившегося факта. Я не настолько крут, чтобы запустить поток в «фоне» для анализа возникающих мыслей, но я обнаружил, что если практиковать анализ в «офлайне», я становлюсь всё лучше и лучше, делая анализ в реальном времени.
Говорить, что вы будете делать свою работу лучше, анализируя реакции, и реально делать это — две разные вещи. Ведение журнала поможет структурировать процесс. Каждый день в определённое время (используйте календарь с напоминанием!), открывайте текстовый файл и записывайте любую ситуацию, которая вызвала у вас панику, даже если это было что-то из мелочей. Один раз в неделю, просматривая составленный список, оцените долгосрочные последствия каждой ситуации, вызвавшей панику. Действительно ли стоило паниковать? Какой могла бы быть наиболее разумная реакция на эту ситуацию? Чтобы сделал герой в фильме о вашей жизни вместо паникёрства?
После некоторой практики вы обнаружите, что анализ будет происходит в то время, как только паника будет подкрадываться. Рационально исследуя причины своей паники в реальном времени, вы поймёте, что паника отступает и в конечном счёте рассеивается.
P.S. На хабре в 2009 году начинался проект перевода этой книги:
Страсть к программированию
Страсть к программированию. Глава 2. Благодарности
Страсть к программированию. Глава 3. Введение
Страсть к программированию. Часть 1 (Выбираем рынок). Начало
Страсть к программированию. Часть 1. Совет 2. Спрос и предложение
Страсть к программированию. Часть 1. Совет 3. Кодинг ещё не всё
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html
Комментариев нет:
Отправить комментарий