Кто из твоих знакомых является самым худшим пользователем компьютера? У меня это один из моих родственников или родственников жены (это вполне конкретный человек, но у меня хватает ума обойтись тут без имен). Представь, что этот человек сидит за компьютером и пытается закончить работу, но вдруг каждое его действие начинает сопровождаться появлением сообщения об ошибке. Думаю, у каждого бывала подобная ситуация. Неопытные пользователи сразу начинают нервничать и терять самообладание. Они беспорядочно щелкают мышкой и двигают что-то по экрану, игнорируя потенциально полезную информацию из сообщения об ошибке, которая появляется снова и снова. В конечном счете они начинают паниковать и звонить с просьбой о помощи, но обычно к этому моменту они успевают сломать еще что-нибудь.
Не подумай обо мне нехорошо, я просто предлагаю представить, что это случилось с кем-то, кого ты хорошо знаешь, и посмеяться над этим. Ведь такое поведение выглядит нелепо. Это просто анекдотично.
Но по-настоящему смешно то, что описанная ситуация является реальным жизненным сценарием. Человек оказывается вне своей зоны комфорта, сталкивается с проблемой и впадает в панику. Это ничем не отличается от моей реакции на отложенный запуск проекта, случайное падение системы или недовольного заказчика. Это всего лишь другие внешние условия.
И вот как я научился не паниковать. Если происходит что-то плохое и я начинаю ощущать это поглощающее чувство напряжения, ведущее к панике, то я сравниваю себя с расстроенным компьютерным "чайником" и начинаю смеяться над собой. Я анализирую ситуацию с точки зрения третьего лица, как будто помогаю своему родственнику справиться с переставшим работать текстовым редактором. И неразрешимые проблемы внезапно становятся проще. Сложные ситуации вдруг оказываются не такими уж запутанными. А решение зачастую оказывается простым и лежащим у меня под носом, как окно с сообщением об ошибке, информирующее, какие действия следует предпринять. Если у тебя хватит силы воли прочитать сообщение, проблема будет решена.
Действуй!
1. Заведи "тревожный" журнал. Способ предотвратить паническое состояние - внимание к собственным ощущениям и эмоциям в стрессовых ситуациях. Я хорошо анализирую свои реакции на происходящее после того, как все заканчивается. Мне не хватает ресурсов на поддержание фонового программного потока с одновременным копанием в природе собственных мыслей, но оказалось, что, рассматривая причины стресса постфактум, я все лучше и лучше начинаю анализировать происходящее в реальном времени.
Сказать, что ты собираешься научиться анализировать собственные реакции, и на самом деле научиться этому - это разные вещи. Ведение журнала сделает этот процесс более структурированным. Каждый день в определенное время (используй календарь с напоминалками!) открывай текстовый файл и записывай ситуации, заставившие тебя хотя бы немного запаниковать. Раз в неделю просматривай список и критически оценивай влияние паники на каждую ситуацию. Стоило ли вообще паниковать? Какой могла бы быть наиболее продуктивная реакция? Что сделал бы герой драматического фильма, посвященного твоей жизни, чтобы не впасть в панику?
Через некоторое время ты обнаружишь способность проводить подобный анализ непосредственно перед приступом паники. Рассматривая причины паники с рациональной точки зрения и в реальном времени, ты почувствуешь, как паника отходит на второй план и постепенно уходит.
Совет 32
Скажи это, сделай это, покажи это
Чтобы не доводить дела до логического конца, достаточно не брать на себя никаких обязательств. Если срок исполнения не указан, ничто не заставляет и не мотивирует тебя на трудовые подвиги. Это особенно верно, когда приходится делать нечто не особо интересное.
Даже плохим руководителям инстинкт говорит о важности планирования. У некоторых разработчиков магическое слово планирование вызывает тревогу. Бесконечные совещания со слабоумными начальниками, создающими в Microsoft Project многочисленные никому не понятные и никому не нужные планы, являются вполне реальным поводом для беспокойства. В итоге зачастую технари компенсируют протест против излишнего планирования, в пику ему постоянно действуя по наитию.
Однако планирование - не горькое лекарство, принимать которое можно, только задержав дыхание. Оно может дать вам освобождение. При наличии слишком большого количества дел именно планирование позволяет перейти от неопределенности, приводящей в замешательство в начале рабочего дня, к четкой уверенности в очередности решения задач.
План вовсе не обязан представлять собой большой чертеж. Достаточно списка в текстовом файле или в электронном сообщении. Не имеет смысла планировать на много дней вперед. Достаточно, чтобы план отвечал на вопрос: "Чем я буду сегодня заниматься?" Я знаю множество людей, дни которых столь сумбурны, что им практически никогда не удается пройти этот тест. В качестве первого шага рекомендую тебе найти время сегодня днем и выписать все дела на завтра в порядке убывания их приоритета. Пытайся реально оценивать свои силы, хотя не думаю, что у тебя есть склонность намеренно брать на себя повышенные обязательства.
План на один день может быть сколь угодно подробным или свободным. У меня был сосед по комнате, которого звали Крис. Каждое утро он просыпался и, даже рискуя опоздать на занятия, тщательно планировал свой день, уделяя особое внимание отработке упражнений на фортепиано (его специализацией было джазовое фортепиано). Учитывая количество лекций, которые он выбрал для посещения, у него был достаточно жесткий график. Он планировал даже то, что будет делать в 15-минутных перерывах между занятиями, вставляя в эти промежутки быстровыполнимые практические процедуры. Многие лекции проходили в одном здании, и зачастую в перерывах у студентов была масса свободного времени, которое они тратили на общение. Пока остальные сидели в ожидании начала следующей лекции, Крис зубрил звуковые ряды или занимался сольфеджио. Он даже делил свое расписание на многочисленные промежутки, занимавшие от трех до пяти минут, успевая за 10-минутный перерыв выполнить несколько практических упражнений. В итоге он стал одним из наиболее уважаемых музыкантов в нашем городе. Конечно, доля успеха тут приходится на его природный талант, но лично я убежден, что именно планирование и следование собственным планам обеспечило ему билет в ряды музыкальной элиты.
Итак, твой план готов. Он может быть не таким детальным, как у Криса, но его должно быть достаточно для ответа на вопрос, чем ты собираешься сегодня заниматься. На следующий день, придя на работу, достань список и начни с первого пункта. Действуй в соответствии со списком, пока не настанет время обеденного перерыва, а затем начни с прерванного места и постарайся завершить все намеченные дела.
Завершив дело из списка, напиши рядом ГОТОВО, используя прописные буквы. Затем произнеси готово и почувствуй себя счастливым. В конце дня посмотри на список завершенных дел и ощути, что ты достиг некоего результата. Ты не только знал, чем ты будешь сегодня заниматься. Теперь ты знаешь, что все готово.
Если у тебя не получится целиком выполнить запланированное, не переживай. В конце концов, никогда нельзя заранее предсказать, сколько удастся сделать за день. Просто перенеси незавершенные дела из сегодняшнего списка (если они еще актуальны) в список дел на завтра и повтори весь процесс заново. Это очень стимулирует. Это позволяет войти в ритм. Это дает возможность разделить свои дни и недели на серию маленьких побед, каждая из которых толкает тебя к следующей. Ты обнаружишь, что эти списки не только делают твои достижения заметными, но и позволяют достигать куда большего, чем во времена, когда ты не визуализировал свои успехи.
Если у тебя появилась привычка к определенному ритму планирования и выполнения, можно начинать думать в категориях недель и даже месяцев. Разумеется, чем больший промежуток времени нужно распланировать, тем менее подробным должен быть план. Расписание на неделю и на день можно сравнить с тактическим планированием битвы, в то время как расписания на тридцать, шестьдесят и девяносто дней лучше сконцентрировать на стратегических целях.
Для бойцов фронта программного обеспечения планировать дела на девяносто дней вперед не очень естественно. Мы - оперативная группа. Заставляя себя вообразить состояние разрабатываемой системы, происходящих в группе процессов и собственной карьеры через девяносто дней, ты столкнешься с вещами, о которых даже не подозревал. Вид на поле боя с высоты сильно отличается от вида снизу. Сначала тебе будет сложно, но продолжай усердно работать. Все полезные навыки нарабатываются только практикой, а преимущества скоро увидишь и ты сам, и те, кто с тобой работает (даже если они не в курсе, чем ты занимаешься).
Отчеты о проделанной работе помогут продвигаться на рынке труда.
Начни сообщать о своих планах руководству. Лучше всего это делать после выполнения хотя бы одного цикла своего плана. И - что крайне важно - начни это делать до того, как тебя об этом попросят. Ни один пребывающий в здравом уме начальник не выскажет недовольства, получив по электронной почте от своего подчиненного лаконичный отчет о сделанном за прошедшую неделю с планом на следующую. Еженедельное получение таких непрошеных писем - мечта каждого руководителя.
Начни с еженедельных отчетов. Привыкнув, переходи к планам на тридцать, шестьдесят и девяносто дней. В более долгосрочных перспективах концентрируйся на обобщенных, эффективных улучшениях, которые ты наметил для своих проектов или поддерживаемой системы. Всегда формулируй эти планы как предложения к руководству и проси прислать комментарии и пожелания. Со временем эти предложения будут требовать все меньших согласований, потому что ты на практике узнаешь, какие вещи обычно принимаются без вопросов, а какие требуют дальнейшей проработки.
Самой важной вещью, которую следует все время иметь в виду, является необходимость проработки всех пунктов плана. Задача может быть завершена, отложена, удалена или замещена. Ничто не должно оставаться неучтенным. Если задача появилась в твоем списке, а потом ни разу нигде не упоминалась, люди перестанут верить твоим планам и эффективности планирования. Сообщать следует даже о негативных результатах. Мы все допускаем ошибки. Но ты можешь выделиться из общей массы, публично признавая свои ошибки и несостоятельность и не стесняясь просить помощи. Постоянный мониторинг состояния запланированных дел создаст тебе заслуженную репутацию человека, у которого ни одна важная работа не теряется в общей массе дел.
Отладь этот процесс, и начальство обязательно обратит внимание на твой стратегический подход. Написание и выполнение планов демонстрирует, что ты не робот для написания кода, а лидер. Именно такой независимой отдачи компании ждут в рамках мероприятий по снижению накладных расходов.
Окончательным преимуществом общения посредством планов является упрочение доверия к обязательствам, которые ты на себя берешь. Если ты говоришь, что собираешься что-то сделать, а затем делаешь это и показываешь готовый результат, ты создаешь себе репутацию человека дела. Вместе с доверием к тебе растет и твое влияние. Представь, что ты хочешь внедрить в своем отделе гибкую методологию разработки или новую технологию. Общепризнанная способность брать на себя и выполнять обязательства обеспечит тебя большей свободой действий в этих экспериментах.
В Бангалоре, в нашем центре программного обеспечения, была группа, которая более года работала в ночь. Из семи входящих в нее человек двум всегда доставалась ночная смена. Еженедельно они менялись, в итоге каждую третью или четвертую неделю каждому члену группы приходилось работать с 7 вечера до 3 утра. Группа постепенно выдыхалась, страдая от постоянной смены суточных ритмов. Но эта группа играла важную вспомогательную роль, и заказчики из США считали, что не справятся без специалистов из Бангалора, помогающих в режиме реального времени.
В итоге был разработан план действий. Группа рассмотрела различные процедуры поддержки и связанные с ними измерения и придумала, как одновременно и избавиться от ночных смен, и улучшить качество обслуживания клиентов. Как действующий руководитель проектов я помог оптимизировать их план и выступил (с моральной поддержкой) в рамках официального предложения руководству в США.
Они знали, что для начальника, который лично отвечал перед американскими заказчиками, это будет щекотливая тема. Когда встреча началась, многих членов группы в буквальном смысле слова охватила дрожь. Но руководитель группы был столь впечатлен, что немедленно поставил свою подпись под предложением, и группа перешла к реализации плана. Через несколько недель ночные смены канули в прошлое и все вернулись к нормальному расписанию.
Основательность их плана, позволявшего не только поменять рабочие часы, но и стратегически повысить производительность работы, внушила большое доверие не только руководству, но в конечном счете и заказчикам. Руководитель группы пользовался этим планом, обсуждая изменения с заказчиками. И группа довела дело до конца. За несколько месяцев она вышла на новый уровень эффективности. И с этого момента доверие к ним настолько возросло, что постепенно они получили возможность работать независимо.
Группа воспользовалась собственным планом для решения конкретной проблемы. Они пошли к начальству не с жалобами, а с предложением по разрешению ситуации.
Твои руководители хотят, чтобы ты мог работать независимо и ощущал вовлеченность в процесс. Составление планов, их воплощение и отчет о достигнутых результатах помогут тебе получить то и другое.
Неудачи и копирование
Патрик Коллисон, студент Массачусетского технологического института
Ларри Уолл писал, что типичными чертами великих программистов являются лень, нетерпение и гордыня. Я не знаю, врожденные это особенности или они приобретаются прилежной работой над собой. В любом случае, непонятно, как воспользоваться этой информацией, чтобы стать более квалифицированным программистом. Поэтому будем смотреть не на характеристики, а на показатели, которые помогут нам самосовершенствоваться.
Если бы мне нужно было выбрать только два показателя, я бы остановился на неудачах и копировании.
Знаю, что ошибаюсь чаще других программистов. Большинство моих проектов заканчиваются провалом. В папке - /Projects можно найти целый ворох забытых попыток сделать нечто интересное. Шансы на успех у каждой из них были примерно такими же, как шансы лобстера уплыть из кастрюли в океан. Кое-чем они привлекают внимание. Успешные проекты, как и счастливые семьи, похожи друг на друга, а вот неудачные проекты завершаются по-разному.
Хотя утверждение, что если человек был владельцем обанкротившейся фирмы, то это указывает на его большой опыт, уже набило оскомину, я не слышал, чтобы подобные идеи распространялись на программирование.
(Если что, у меня есть опыт в обеих сферах. Мои попытки заниматься бизнесом проваливались так же часто, как программные проекты.)
Коммерческие провалы обычно дают тебе вполне конкретный опыт. Ты понимаешь важность экономии или становишься более решительным. Но в программировании ценен не столько опыт неудач, сколько знания, полученные во время работы над проектом, который, скорее всего, провалится.
Когда я начинал программировать, много времени тратилось на бесплодные попытки написания самых разных замечательных вещей: операционных систем, файловых систем, виртуальных машин, дополнительных реализаций сетевых протоколов, интерпретаторов, JIT-компиляторов. Большинство моих творений так и не заработало, а то, что заработало, справлялось со своими задачами крайне посредственно. Даже если игнорировать технические аспекты, большинство моих попыток с самого начала было обречено на неудачу. Я не знаю, насколько велика вероятность написать новую операционную систему, но она крайне мала.
Однако для меня эти проекты являются самыми интересными в программировании. Это фундаментальные задачи, касающиеся разработки программного обеспечения, причем очищенные от всего постороннего. Все они связаны с поиском компромисса между пространством, быстродействием, надежностью и сложностью, без сглаживания углов или некорректного API.
Это теоретические задачи, в решение которых можно погружаться месяцами, так и не получив реального результата, - именно это я регулярно демонстрировал.
Точно не знаю, по каким причинам, но люди, в настоящее время изучающие программирование, обычно не занимаются подобными вещами.
Возможно, это связано с увеличением количества сетевых приложений. Несколько дней назад на сайте Hacker News кто-то поинтересовался, нужны ли в настоящее время хоть кому-нибудь программы на стороне клиента. Это некоторое преувеличение, но оно недалеко от истины. Да-да, я тоже считаю, что веб-приложения - это очень круто.
Но с точки зрения программирования такая тенденция имеет свой минус. При написании веб-приложений практически никогда не приходится сталкиваться с серьезными техническими проблемами, пока дело не доходит до реально больших масштабов (мы не берем в расчет совместимость с Internet Explorer 6).
Другими словами, барьер, за которым программиста подстерегают неудачи, стал выше. И на первых порах человек работает вполне успешно.
И вот из-за этой направленности на программы, ориентированные на работу в Сети, я считаю, что нужно специально искать проекты с высокой вероятностью неудачи.
А что с копированием? Любой вам скажет, что для превращения в хорошего программиста нужно читать по-настоящему хороший код. Допускаю, что никто не подразумевает чтения в буквальном смысле (это слишком скучное занятие), но все равно такой подход остается, по сути, неверным: ведь он пассивен. Вместо него я предлагаю активно, широко и беззастенчиво заниматься копированием.
Разумеется, это относится ко многим вещам. Хантер С. Томпсон не просто читал хорошие книги; он перепечатывал Хемингуэя и Фитцджеральда. А старейшие из известных рукописей Баха являются переложениями произведений других органистов. Возможно, более известным является тот факт, что Гейтс в Гарварде доставал чужие программы из мусорной корзины.
Понять, как это может помочь, не так уж сложно. Копирование нарабатывает мышечную память. Ты начинаешь чувствовать нюансы и форму оригинала - детали, которые при быстром сканировании теряются.