Помоги проекту - поделись книгой:
Бюрократия – это неповоротливая машина, которая часто дает сбои, но, кроме этого, она может уберечь вас от потенциально провальных решений, упростить взаимодействие с коллегами или обеспечить качественный отпуск (ощутите на языке вкус бананового коктейля).
Тезисы
■ Бюрократия – неотъемлемая часть больших компаний и продуктов.
■ Редкие плюсы бюрократии теряются среди ее многочисленных минусов.
■ Не позволяйте сухим бюрократическим формальностям расстраивать вас.
Задание
Если вы работаете в компании, известной своими бюрократическими проволочками, и вас это БЕСИТ, начните тренироваться. Воспринимайте каждое вовлечение в череду ненужных (на ваш взгляд) обсуждений как прогон тестов. Да, это медленно, да, вы в это время не можете толком заняться ничем другим, но, возможно, именно на этом прогоне вы заметите какую-нибудь очень неприятную, очень опасную ошибку. Используйте время, которое теряете в бюрократической бездне, с пользой для себя: подтяните свои знания по языкам программирования, займитесь рефакторингом вашего приложения (да-да, если вам одобрили эту задачу, подписав 12 бумажек на 6 разных этажах и прислав почтового голубя с письмом-подтверждением).
История из жизни
Одна из компаний, в которых я работал, требовала тотальной отчетности по рабочему времени, разбитому на десятиминутные интервалы, так что если в течение часа вам приходилось заниматься разными делами, вы должны были составить примерно такой список:
10 минут – обсуждение с коллегой ошибки #123
20 минут – анализ требований к задаче #125
10 минут – поиск библиотек, подходящих под требования задачи #125
10 минут – общение с тестировщиком по ошибке #123
10 минут – работа по внедрению найденной библиотеки в задачу #125
Все это отнимало уйму времени, и на отслеживание и запись своих занятий нужно было тратить куда больше усилий, чем непосредственно на сами занятия.
Идеальный продукт
Людям свойственна тяга к прекрасному, а перфекционисты – люди, ставшие рабами этой тяги. Желание сделать работу как можно качественнее – важная и замечательная черта любого специалиста. Когда мы начинаем новый проект или новую работу, мы горим (мама, неси огнетушитель!). Мы мотивированны, возбуждены, ушки у нас на макушке. Мы хотим сделать все правильно. Мы хотим сделать все качественно.
Извините, но сейчас я спущу вас обратно на землю. Мир – это хаос. Мир программного обеспечения, при всей кажущейся структурированности и логичности, – еще больший хаос. И мы становимся заложниками желания привнести в этот хаос смысл и логику. Мы пытаемся написать идеальный код. Дизайнеры пытаются создать идеальный, понятный и практичный интерфейс. Тестировщики пытаются написать идеальные системы проверки продукта.
И все это разбивается о пользователя, который решил отправить форму, оставив вместо имени цифру 0. Да, я утрирую, но лишь слегка. Мы так отчаянно стараемся создать что-то незыблемое и прекрасное, что отрываемся от реальности, от хаоса, в который погрузится наш продукт, как только попадет на рынок, к пользователям. И я не хочу сказать, что в этом есть чья-то вина: наша как создателей или пользователей как потребителей. Просто так устроен мир, и мир программного обеспечения не исключение.
Для примера понаблюдайте за опытными разработчиками. Со стороны их работа может показаться достаточно небрежной. И дело не в том, что они нарушают стиль кода или вместо того, чтобы писать код, играют в пинг-понг. Нет, «небрежность» заключается в самом их отношении к своему коду. Вы редко увидите, что профессиональный разработчик корпит сутки напролет, выстраивая монструозную систему отлова всех ошибок и исключений. Вы вряд ли увидите разработчика, который тщательно напишет все возможные тесты для только что созданного им кода.
Эта кажущаяся небрежность – не более чем показатель большого опыта, полученного на множестве проектов. Каждый разработчик, приобретя достаточный опыт в IT, начинает понимать, что идеального кода не существует. Есть код, который работает и делает то, что должен делать. С одной стороны, профессиональный разработчик должен писать качественный код, с другой – может быть достаточно небрежен в работе. Но как?! Опыт и интуиция. Если за свою карьеру вы написали 10 калькуляторов, то вряд ли станете писать сотню юнит-тестов по проверке сложения (assert(2 + 2, 4), какая красота, вы только посмотрите). Вероятнее всего, вы напишете десяток тестов, но таких, которые будут включать самые нелепые, самые глупые входные данные, какие только могут быть: сложение со строкой, деление на ноль, возведение в объект. Опыт поможет вам почувствовать, в каком месте код встретится с хаосом реальности и когда он падет смертью храбрых. Но даже тогда вы не предугадаете всех вариантов, поэтому позвольте себе наслаждаться процессом. Не делайте из кода или продукта культ. Пусть работа приводит вас в восторг, а мотивация зашкаливает так, что не дает уснуть по ночам. Однако всегда помните о том, что хрустальные замки идеалов – в облаках, а внизу – хаос реальности, от которого нельзя избавиться, просто отказавшись о нем думать.
Тезисы
■ Мир программного обеспечения – хаос.
■ Старайтесь выполнять свою работу качественно, но не кладите ее на алтарь перфекционизма.
■ Идеальных решений, как и идеального кода, не существует.
Задание
Вспомните самое начало своей карьеры. (Если вы начинающий разработчик, вернитесь к этому заданию чуть позже – уверен, оно вас впечатлит.) Вспомните, с какой дотошностью вы относились к новому коду, который впоследствии приходилось писать не один десяток раз. С точки зрения вашего опыта на сегодняшний день можете ли вы сказать, что по-прежнему так же педантичны? Что пытаетесь учесть все-все варианты и исходы кода? Что предпочитаете ставить обработчики ошибок и логирование через каждые три строчки, чтобы уж точно не упустить ни одной опасной ситуации?
История из жизни
Ощущение, будто я и правда могу создать что-то идеальное, никуда полностью не уходит, но мои ожидания становятся реалистичнее. Само словосочетание «идеальный код» теряет свою магическую недостижимость и означает вполне конкретные критерии, которыми я буду доволен, когда достигну их выполнения. Ощущаю ли я, начиная новый проект, что хочу создать идеальный продукт? Разумеется, да. Просто теперь «идеальный» для меня звучит как «надежный», «удобный для пользователей», «расширяемый» и «продуманный». На такие идеальные качества я вполне могу ориентироваться без того, чтобы усложнять бесконечным перфекционизмом и без того сложную работу.
Код-ревью
Качественный способ улучшить код, найти ошибки на ранней стадии, ознакомить членов команды с компонентами системы, с которыми они раньше не работали, – прекрасно. Возможность разобрать по косточкам код коллеги, которого вы недолюбливаете, чтобы найти ошибку, – бесценно. Шучу. Не обижайте коллег, вам с ними делать релизы.
Код-ревью – это прекрасная практика, которая помогает держать код проекта в чистоте и порядке, придерживаться изначально задуманной архитектуры, находить ошибки, давать подсказки новым разработчикам и т. д. Описывать прелести код-ревью можно долго, а еще проще найти об этом сотню статей.
В этой теме я не буду подчеркивать достоинства ревью кода. Просмотр кода полезен, и если в вашей компании его практикуют – прекрасно.
Код-ревью вовлекает разработчиков в диалог, в ходе которого один из них должен занимать оборонительную позицию. Может быть, и существуют идеальные команды, где каждый разработчик уважает своих коллег и то, как они пишут код, но давайте будем реалистами.
Формальные правила код-ревью предполагают, что написанный для проверки код должен соответствовать правилам проекта, которые нельзя проверить автоматизированно. Иными словами, код-ревью подразумевает проверку логики работы написанного кода, целесообразность использования механизмов, алгоритмов и компонентов.
Код-ревью поможет понять, соответствует ли код архитектуре и смыслу проекта, не используются ли средства, которые не принято использовать на проекте, и многое-многое другое. Отчасти с такой проверкой могут справиться тесты, но чаще всего тесты пишутся тем же разработчиком, что и код, попавший на ревью, а следовательно, они неспособны выявить все потенциальные проблемы.
Код-ревью требует времени. Нередко это раздражает, потому что не во всякой компании на ревью выделяется отдельное время и часто код-ревью требуется совмещать с работой над задачами. Просмотр кода не просто предполагает беглое ознакомление с написанным, но требует понимания поставленных задач и логики работы кода. В случае если мы говорим о ревью добавленной кнопки с одним действием, все кажется не таким сложным. Но если вы смотрите на код нового компонента аудита действия пользователей системы – да поможет вам Вселенная.
Код-ревью требует опыта и отстраненности. Умение донести свою позицию, не перегибая палку и не пытаясь переделать чужой код в свой, требует большого опыта. С годами у разработчиков вырабатывается свой стиль, свое видение кода. Да, мы используем один и тот же язык с одинаковыми правилами синтаксиса и выполнения, и тем не менее у каждого разработчика есть личный подход. Это может быть свой метод именования переменных, своя логика при работе с массивами, свой способ контролировать ошибки и исключения – все что угодно.
А теперь сосредоточьтесь. Не позволяйте своим привычкам проникать в код-ревью. Вы НЕ делаете код лучше, когда просите другого разработчика переименовать переменную. Вы НЕ делаете код лучше, когда просите заменить for на while просто потому, что привыкли обходить циклы так. Более того, даже если ваш подход обеспечивает мизерную оптимизацию на конкретной версии вашего компилятора, придержите эту ценную информацию при себе.
Ревью кода – это не схватка идеальных машин, это способ держать проект в балансе между разными людьми, у каждого из которых есть на него уникальный взгляд.
Код-ревью потребует от вас крепких нервов. Да, возможно, вы ветеран многих холиваров и закалены в интернет-дуэлях. Но скорее всего (особенно если вы начинающий), вы нервничаете каждый раз, когда ваш код отправляется на ревью старшим разработчикам. Это нормально. Хорошо сомневаться в своем коде, отлично, если вы хотите, чтобы он был лучше.
Проходя код-ревью, постарайтесь забыть, что этот код ваш, и объективно воспринять комментарии, которые вам напишут. Представьте, что сами присутствуете на этом код-ревью, а код принадлежит другому человеку. Хорошим советам и замечаниям стоит только радоваться: код станет только лучше.
Относитесь к код-ревью как к полезному инструменту, как к плагину для вашей среды разработки. Смогли бы вы прожить без него? Да. Но если что-то может сделать ваш вклад в проект более качественным, почему бы не воспользоваться такой возможностью?
Тезисы
■ В ходе код-ревью не обороняйтесь и не нападайте, это не битва.
■ Уделите время код-ревью.
■ Абстрагируйтесь от кода и стиля, сосредоточившись на логике написанного.
■ Воспринимайте рекомендации как добрый совет, не ищите в них упрека.
Задание
Попробуйте найти в системе контроля версий вашего проекта задачу, которую вы делали какое-то время назад и уже успели забыть. Возьмите ее на ревью. Оцените свежим взглядом собственные решения, выбор механизмов и подходов. Проверьте, соответствует ли ваш код архитектуре проекта. Достаточно ли много общего он имеет с похожими компонентами в системе? Какие рекомендации по его улучшению вы бы дали, руководствуясь своими знаниями на сегодняшний день?
История из жизни
Как-то раз я проводил код-ревью начинающего разработчика и делал это по большей части автоматически – комментировал, писал, почему так не стоит делать и как сделать лучше; словом, это было самое обычное ревью, по крайней мере для меня. Через некоторое время мне передали, что разработчик, чей код я проверял, работает через силу, подавлен, сомневается даже в простых решениях, которые пишет. Я решил поговорить с ним, узнать, что случилось, нет ли каких-то личных причин, которые он хотел бы обсудить. Выяснилось, что мое код-ревью было обычным только для меня, а разработчик воспринял его как отповедь, как прямую критику в свой адрес. Я извинился и попытался объяснить, что ничего из того, что я говорил, не может и не должно восприниматься как упрек или сомнения в его профессионализме: это всего лишь комментарии, которые должны подготовить код к тому, чтобы он стал частью проекта. Мы хорошо поговорили в тот день и достаточно долго поддерживали дружеские отношения, иногда вспоминая эту историю.
Методологии разработки
Тема, занимающая умы тысяч продакт-менеджеров. Тема, заставляющая директоров компаний потирать руки в ожидании невероятной продуктивности сотрудников. Тема, обязывающая разработчиков готовить доклады о том, как прошла их рабочая неделя.
Когда-то разработка программного обеспечения была узкоспециализированной необходимостью. Научной, математической, интеллектуальной. Развиваясь, разработка стала требовать большего, чем просто умение создавать программы и вычислять результаты. Итеративность процесса разработки, необходимость предсказуемости результата, формирование четкой структуры и фаз разработки требовали создания чего-то нового. Алгоритма по созданию программного обеспечения. Методологии.
Мы не будем погружаться в пересказ всех доступных (и уже покойных) методологий разработки. Если вам действительно этого захочется, можете найти их самостоятельно. Методологии позволяют структурировать процесс разработки программного обеспечения, составлять формальные правила по оценке задач, регламентировать обсуждения и планирование, оценивать эффективность людей и команд внутри компании.
Насколько методология разработки, предпочитаемая в компании, повлияет на вас как на разработчика? Это зависит от вас.
Для кого-то сам набор правил и регламентов позволяет чувствовать себя безопаснее и предсказуемее (многие разработчики любят структурированность не только в своем коде, но и в жизни).
Кому-то выбранная методология разработки будет отравлять жизнь необходимостью совершения рутинных действий, присутствия на пустых и обременительных обсуждениях и т. д.
На ком-то наличие методологии не скажется никак. Совсем.
Говоря о методологиях разработки, с большой долей уверенности можно сказать, что:
● наличие выбранной методологии разработки лучше ее отсутствия (плюс для компании);
● выбранная методология не должна мешать вам работать (плюс для вас).
Отчасти методологии защищают и самих разработчиков, помогая предупредить неверные решения, спрогнозировать лучший подход или верно оценить время, которое потребуется. Однако в первую очередь методологии нужны компаниям, и на то есть причины. Да, каждый разработчик способен на многое, но, как и любая совокупность людей, участвующих в одном деле, мы частенько теряем представление об общей картине происходящего. Не потому, что каждый человек в толпе глуп или недальновиден, просто сама толпа становится менее предсказуемой и эффективной.
Методологии разработки появлялись тогда, когда в них возникала необходимость. Часто методологии, описанные максимально подробно и применяемые максимально точно, абсолютно не приживались в одних компаниях и давали невероятный толчок к производительности в других.
Применение методологии разработки – не панацея и не проклятие, это всего лишь инструмент, полезность которого определяется методом проб и ошибок. На ваше счастье, если вы работаете в крупной компании, там уже есть люди, которые ломают над этим голову. Относитесь к методологии разработки как к временам года. Они могут вам нравиться или нет, но они есть, и вам нужно извлечь из этого плюсы.
Тезисы
■ Методология разработки – попытка структурировать и повысить производительность разработки программного обеспечения.
■ Чаще всего методологии создавались для конкретных компаний и с определенными целями.
■ Верная методология в любой компании определяется методом проб и ошибок.
■ Извлекайте из методологии разработки плюсы, даже если ее минусы мешают вам работать.
Задание
Определите, какая методология разработки используется в вашей компании (если используется вообще). Ознакомьтесь с историей происхождения этой методологии и оцените, насколько корректно компания следует изначальной идее. Если вас интересует структурирование взаимодействий внутри компании, попробуйте проанализировать слабые места в организации работы, предложите что-то из других методологий, которые, возможно, лучше бы подошли вашей компании.
История из жизни
Из всех моих пересечений с методологиями разработки я вынес для себя только одну, самую полезную и нужную технику. Вопреки тому, что я могу воспользоваться мириадами программ для трекинга задач, событий и важных уведомлений, я все еще предпочитаю клеить САМЫЕ ВАЖНЫЕ напоминания на монитор стикерами с написанным от руки текстом. Обычно мой монитор похож на рождественскую елку, разве что не зеленый и не мигает огнями гирлянды. А еще я веду письменные заметки во время технических обсуждений, чем вызываю немало шуток про бересту и глиняные таблички.
Я
Этот раздел написан про вас. Ну хорошо, хорошо, он написан про меня, потому что я не могу описать здесь ваш опыт, ваши будущие решения и профессиональный путь. Возможно, темы этого раздела покажутся вам полезными, а может быть, вы поймете, что в некоторых ситуациях поступили бы иначе. В любом случае я опишу то, что на протяжении моей карьеры казалось мне самым важным. То, что беспокоило или радовало лично меня. В конечном счете мы все удивительно похожи, и, возможно, вы сумеете найти в моем опыте что-то полезное.
Забота о себе
Внутреннее состояние оказывает огромное влияние на вашу работу.
Пожалуйста, остановитесь и еще раз прочитайте предыдущее предложение. Я серьезно. Вам может казаться, что работа – это исключительно набор навыков, технический склад ума или просто опыт, но, поверьте мне, самочувствие сказывается на ней больше, чем вы можете себе представить.
Отмечайте то, что вас радует. Возможно, это новые проекты, сложные задачи, какие-то конкретные технологии или направления разработки. А может, вы радуетесь, когда гладите страуса или готовите домашнюю пиццу. Какая-нибудь мелочь, которая делает счастливым лично вас, может дать вам мотивацию на неделю работы вперед. Замечайте это, запоминайте то, что дает вам силы.
Разумеется, вы не будете чувствовать себя всегда на все сто, и это нормально. Не корите себя, если замечаете, что недостаточно удовлетворены работой. Не упрекайте себя, если понимаете, что внутреннее состояние не позволяет вам работать так же качественно и быстро, как раньше. Отнеситесь к себе с пониманием, вы не можете обязать себя быть постоянно на подъеме. Дайте себе время, позвольте восстановиться.
Старайтесь радовать себя даже тогда, когда работа занимает все ваше время. Выделите час в процессе работы, найдите время вне работы, чтобы сделать то, что поднимет вам настроение. Это может быть все что угодно: возможно, вам давно хотелось попробовать написать 'Hello world' на Scala; а может, вы мечтали пострелять из арбалета или погладить енота.
Заботьтесь о себе во внерабочее время, это даст вам куда больше энергии для профессионального роста, чем кажется.
Это же касается и физического самочувствия. Я думаю, мне нет смысла объяснять, что писать качественный код, когда раскалывается голова или живот сводит болью, практически невозможно. И не нужно.
Быть разработчиком сложно – это требует очень больших затрат энергии как тела, так и мозга. Не пренебрегайте сигналами от организма, не забывайте нормально питаться и спать; следите за тем, как и сколько вы отдыхаете от новой информации.
Я не буду говорить про йогу, спортзал и абдоминальное дыхание. Это вещи, отношение к которым вы определите сами. Моя задача – донести до вас, что ментальное и физическое состояния неразрывны и напрямую сказываются на вашей работе.
Тезисы
■ Ваше внутреннее состояние – залог качественной работы.
■ Вы должны заботиться о себе.
■ Ваши ментальное и физическое состояния тесно связаны, не надейтесь удерживать на плаву что-то одно.
■ Находите и создавайте поводы для радости.
Задание
Составьте список из 10 занятий, которые вас всегда радуют. Любимая еда? Отлично. Тайная страсть к написанию кода на ассемблере? Замечательно. Храните этот список и заглядывайте в него, когда понимаете, что ваша мотивация под угрозой, или чувствуете, что работа перестает вас радовать, как раньше.
История из жизни
Увы, я всегда знал, как надо заботиться о себе, но редко следовал своим же правилам. Переработки? Да. Работа месяцами без выходных? Да. Черт, я как-то посчитал свое рабочее время за один очень насыщенный год, просуммировав общее количество рабочих часов и разделив на количество дней. Вышло, что в том году я работал по 8 часов КАЖДЫЙ день. Не будьте как я, будьте здоровее, чем я, заботьтесь о себе и своем здоровье.
Усталость и выгорание
Хотел бы я сказать, что вы никогда не будете уставать так, что вас будет тошнить от одной мысли о работе, и никогда не столкнетесь с профессиональным выгоранием. Но это было бы ложью.
В какой-то момент способы, описанные в теме «Забота о себе», не сработают так, как раньше. Вы почувствуете, что все, чем вы занимаетесь, – бессмысленно, что ваши решения в коде – некачественные и глупые. Вы начнете допускать грубые, детские ошибки, станете хуже принимать решения, хуже анализировать новые задачи и требования.
Поздравляю, вы стали профессиональным разработчиком. И это только отчасти шутка. Любой опытный разработчик сталкивается с личным кризисом: в силу внешних или внутренних причин ему кажется, что его работа бессмысленна и ничего не стоит.
Я мог бы попробовать описать причины таких кризисов, но в реальности их слишком много, чтобы перечислить. Это могут быть личные причины, не связанные с работой. Причиной может быть ваша компания, продукт, депрессия, начальник-идиот. Чаще всего причин множество, в какой-то момент происходит надлом и работа начинает страдать вместе с вами.
Первый совет, который я хочу вам дать, – притормозите. Возьмите больничный, даже если это будет стоить недовольных лиц руководства. Возьмите отпуск, пусть даже вы не будете присутствовать на релизе своего продукта. Если вы исчерпали весь свой ресурс, то можете сделать лишь одно: остановиться и обдумать ситуацию без нависающих над вами дедлайнов, ошибок и клиентов.
Не обвиняйте себя и не обесценивайте свою работу. Подобные мысли будут посещать вас очень часто. Вам будет казаться, что вы неудачник, ничего не умеете и не можете сделать хорошо. Помашите этим мыслям рукой, они просто обманывают вас и не имеют никакого отношения к реальности. Это всего лишь ваш усталый мозг дает сигналы, что ему пора отдохнуть.
Дайте себе столько времени, чтобы передохнуть, сколько необходимо. Вместе с выгоранием приходит потеря интереса ко всему, что вас радовало, мотивировало, интересовало. Ваша задача – сделать паузу, чтобы эти ощущения вернулись. Если вы снова чувствуете интерес, захотелось попробовать что-то новое в разработке, заинтересовала какая-то новая технология, – поздравляю, вы на правильном пути.
Однако есть и другой сценарий. То, что я сейчас скажу, прозвучит безжалостно, но я должен это сделать: возможно, взяв перерыв, вы поймете, что у вас уже нет желания работать в этой индустрии. И я не имею в виду конкретную компанию или проект. Возможно, вы почувствуете, что не хотите больше заниматься разработкой. Не пугайтесь этой мысли, дайте ей право на существование. Даже самая успешная карьера не стоит того, чтобы быть несчастным.
Выгорание и депрессия часто идут рука об руку, и вам нужно понимать, что не всегда потеря интереса к работе связана только с самой работой. Если вы понимаете, что ваше ментальное состояние ухудшается и потеря интереса к работе лишь следствие того, что вы несчастны как человек, пожалуйста, обратитесь к специалисту, начните психотерапию. Кислородную маску сначала надевают на себя, затем на ребенка. Работа никогда не будет важнее вас как человека, позаботьтесь в первую очередь о себе.
Тезисы
■ Выгорание однажды случится и с вами.
■ Остановитесь.
■ Не смейте себя упрекать и дайте себе столько времени, сколько нужно.
■ Помните, что вы не тождественны своей работе: вы значительно важнее, чем она.
■ Выгорание и депрессия – частые спутники; если перестаете справляться сами, обязательно обратитесь за помощью.
Задание
Никогда не упрекайте себя из-за работы и давайте себе столько времени на передышку, сколько вам требуется.
История из жизни
Я выгорал, разумеется. Я впадал в депрессию, я попадал в больницу, все это было. И в то же время я могу назвать себя счастливчиком, потому что ни один из этих спадов не закончился для меня ненавистью к разработке. Да, это было очень тяжело, но я никогда не задумывался о том, чтобы делать что-то другое. Моя работа для меня – спасение и проклятие, так было и есть. С каждым годом я только лучше понимаю, как извлекать плюсы из одной крайности и нивелировать минусы другой.
Винтик в механизме
Долгая работа на одном проекте или в одной компании заставляет наши мозги ржаветь. Мы используем одни и те же технологии, работаем по одним и тем же установленным в компании правилам, применяем одни и те же методологии и подходы. В какой-то момент это может даже начать доставлять удовольствие: все становится достаточно знакомым, чтобы работу можно было выполнять быстро, просто и шаблонно. И ровно в этот момент наш мозг начинает ржаветь.
Труд разработчика многогранен и интересен. Нам приходится решать сложные задачи, находить новые подходы и разбираться в порой совершенно безумных требованиях заказчиков. Однако постоянное повторение одних и тех же решений, работа в одной и той же области требований, с одними и теми же технологиями нередко приводит к тому, что наши навыки становятся узкоспециализированными, заточенными под один набор задач. В некоторых областях разработки программного обеспечения это станет плюсом, но если вы понимаете, что теряете профессиональную хватку, – пришло время помогать себе.
Ощущение того, что вы лишь винтик в механизме, характерно для разработчиков больших компаний, работа каждого из которых сосредоточена на конкретной подсистеме или части функций проекта. Разработчики могут годами видоизменять одни и те же части кода, теряя представление о том, как система функционирует в целом. Кому-то из вас такая работа будет по душе, но кто-то может начать чувствовать постоянное давление и растущее ощущение своей бесполезности.
Давайте оговоримся сразу: любая работа, которую вы делаете, важна и нужна. Даже не пробуйте спорить с этим и предполагать «другие варианты». Примите это как безусловный факт. Однако вы должны помочь себе. Ваши амбиции (я употребляю это слово в самом положительном смысле), ваш опыт требуют нового. Они требуют, чтобы вы развивались, им нужны ваша помощь и участие.
Знания и опыт – это то, что делает вас профессионалом. Помогите себе: начните заново пополнять их. Пробуйте направления, которыми раньше никогда не занимались. Вы занимаетесь веб-разработкой? Научитесь писать на ассемблере. Создаете мобильные приложения? Попробуйте написать свою мини-игру под Linux. Однако замечу: выбирайте то, к чему испытываете интерес. Нет ничего хуже, чем заставлять себя заниматься тем, что не по душе. Знания никогда не бывают бесполезными, особенно в нашей индустрии. Вы думаете, что разобрались в том, как работает сетевой стек, но это вам никогда не пригодится? Просто подождите. Думаете, что вам совершенно ни к чему знать, в чем разница между stack и heap? Года не пройдет, как вы столкнетесь с этим в работе.
Есть вероятность, что, даже получая новые знания, вы все равно будете чувствовать себя как в клетке. Такое ощущение часто возникает, если компания не дает пространства для роста и развития. Возможно, руководство не считает это важной или нужной частью вашей рабочей деятельности; возможно, ему выгоднее задействовать вас прицельно на конкретном проекте или части проекта. В любом случае, если вы постоянно чувствуете себя в западне, подумайте, а так ли полезна для вас работа в компании, которая не хочет видеть профессиональный рост и новый опыт своего сотрудника.
Тезисы
■ Не позволяйте мозгам ржаветь.
■ Поглощайте новую информацию.
■ Следите за тем, чтобы не останавливаться в развитии.
Задание
Попробуйте честно ответить себе на вопрос: вы чувствуете, что на текущем месте работы получаете новые знания и опыт? Не ощущаете ли вы себя в западне рутинной, повторяющейся работы? Если понимаете, что начали буксовать в профессиональном развитии, попробуйте изучить что-то новое: язык программирования, подход к разработке – что угодно, что вызывает у вас интерес. Если же вы пробуете снова и снова, но все равно возвращаетесь к работе, где вас используют как инструмент для выполнения одних и тех же задач, задумайтесь: заслуживают ли ваш профессиональный рост и карьера такой стагнации?
История из жизни
Самой большой отдушиной для меня становилось понимание того, что вся магия, которую я могу воплотить в коде, только в моих руках. Ничто извне не может помешать мне написать новое, создать что-то интересное из ничего, из набора слов и цифр. Когда мне начинало казаться, что я просто занимаю определенное место в скучном, большом механизме, я начинал писать для себя, по вечерам, после работы, ночью. И это всегда помогало. Я старался никогда не позволять себе быть узником собственных мыслей.
Кроличья нора
Любой профессиональный разработчик знает: лучшее решение получается только тогда, когда вы располагаете максимумом информации о проблеме, которую пытаетесь решить. Каждое требование к задаче, каждый элемент архитектуры новой системы, каждая ошибка в проекте требуют от вас владения полной информацией. Ваш профессиональный рост требует абсолютно того же.
Мир разработки программного обеспечения огромен. Еще совсем недавно он был достаточно обозрим и у разработчиков был шанс знать о программном обеспечении если не все, то почти все. В наши дни эта цель уже недостижима.
Начинающим разработчикам часто становится не по себе, когда они понимают, что им открывается только малая часть того, что ждет их впереди. Им кажется, что разработка программного обеспечения необъятна. Информации много, слишком много для восприятия, и хуже того, она устаревает быстрее, чем мы успеваем ее усвоить. Новые языки программирования, новые технологии, новые подходы, новые инструменты – в какой-то момент этот шквал новизны может сбить с ног. Не отчаивайтесь, это пройдет. Честно.
В самом начале карьеры вы должны сосредоточить свое внимание только на одном: на самообразовании. Учитесь, читайте, пробуйте, ошибайтесь. Если вы боитесь высоты, но при этом идете по узкой горной тропинке, не позволяйте себе смотреть вниз. У вас всего одна задача: шаг за шагом двигаться вперед. Шаг вперед, еще шаг, еще шажок.
Выберите технологию, которая вам нравится. Занимайтесь ею, изучайте ее. Интерес к этой технологии будет поддерживать вашу мотивацию. Не переживайте и не думайте, что упускаете что-то в мире IT, – наоборот, с каждым шагом вы становитесь опытнее и профессиональнее. Если в какой-то момент привычные рамки покажутся вам тесными, выйдите за их пределы: выберите новый язык программирования, поучаствуйте в open source проекте. Расширяйте границы своего опыта.
Каждый следующий шаг принесет вам новые знания, узкая тропка будет расширяться, а страх перед огромным и неизвестным – ослабевать. В какой-то момент вы сможете с уверенностью осмотреться вокруг и увидеть, что весь этот огромный мир, который изначально так пугал, на самом деле работает как цельный механизм с уже понятными вам законами и правилами.
Вы увидите, как новые технологии используют подходы старых, добавляя что-то свое. Как языки программирования наследуют удачные решения своих предшественников. Вы поймете, что каждый опыт познания на вашем пути добавлял крупицу понимания того, как устроен мир разработки программного обеспечения.
Ни один ваш шаг не окажется лишним. Сегодня вы узнаете что-то новое, а потом сможете наблюдать, как оно изменяется, эволюционирует. Как свежая идея, добавленная в новый язык программирования, спустя 10 лет становится стандартом индустрии. Как маленькая библиотека, которая должна была облегчать работу одного разработчика, превращается в полноценный инструмент, которым пользуются разработчики по всему миру. То, что вы узнаёте, облегчает весь ваш дальнейший путь. Эти знания позволят вам с каждым шагом двигаться все увереннее и быстрее. Вы начнете видеть связи между технологиями, единые правила, по которым они работают, и наконец почувствуете радость от пребывания в таком огромном и интересном мире.
Никогда не останавливайтесь в изучении нового. Если мы не развиваемся в сфере разработки программного обеспечения, весь наш опыт, все наши знания начинают растворяться. Это постоянно изменяющийся мир, и вы должны всегда двигаться вперед вместе с ним.
Тезисы
■ Мир разработки программного обеспечения огромен.
■ Весь этот огромный мир работает по очень похожим правилам.
■ Впитывайте знания, собирайте пазл.
■ Никогда не переставайте узнавать новое.
Задание
Найдите язык программирования, который вам понравится, но с которым вы еще никогда не имели дела. Вас может привлечь синтаксис, оформление документации – все что угодно. Попробуйте уделить этому языку программирования неделю своего времени (не в ущерб работе, но искренне пытаясь разобраться в нем). Попытайтесь увидеть в нем принципы, которые уже вам знакомы (я не про синтаксис языка, нас с вами не удивит наличие в нем конструкции if). Если во время изучения вам действительно понравится этот язык, попробуйте использовать его для себя, присоединиться к его сообществу.
История из жизни
Мое знакомство с программированием началось в детстве, когда я нашел дома книгу по языку Си. До сих пор не знаю, откуда она взялась: никто в моей семье не увлекался ни компьютерами, ни программированием. Мне было, кажется, 12, и я очень любил все связанное с компьютерами. Своего компьютера у меня не было, и я начал читать найденную книгу как эзотерический трактат, представляя, что я мог бы изменить в коде той или иной программы, если бы это было возможно. Мне казалось, что с годами это любопытство, жажда узнать, что там, на следующем шагу, ослабнет, но это ощущение так и остается при мне. Каждый день мне по-прежнему не терпится узнать, насколько глубоко ведет эта кроличья нора.
Пройдет и это
На своем пути разработчика вы будете попадать в самые разные истории и сталкиваться с самыми разными ситуациями. Взлеты и падения, большие удачи и большие разочарования, конфликты и внезапные озарения. Вас будет удивлять код, вас будут удивлять люди (не всегда приятно, к сожалению), вы будете удивлять себя сами (временами очень сильно).
Возможно, вы не поверите в то, что я сейчас скажу, но хотя бы запомните эту мысль и постарайтесь пожить с ней, применить ее на практике, дать ей шанс. Происходящие с нами события не определяют наше дальнейшее поведение. Приведу пример. Допустим, у нас есть два сотрудника, которых решили уволить. Само событие увольнения для них абсолютно одно и то же, но один расценит его как проблему, необходимость поиска новой работы, профессиональную неудачу. Второй же увидит возможность найти более интересную компанию, проект и должность, получить новый опыт работы.
Одно и то же событие может вызывать совершенно разную реакцию у разных людей. Дело тут, разумеется, не в самих людях, а в том, что они видят в этом событии. Кто-то расценит увольнение как трагедию, повод усомниться в своих силах. А кто-то увидит в этом новые возможности. Решить, как относиться к ситуации, можете только вы сами.
Я не предлагаю вам составить карту желаний и каждое утро перед зеркалом повторять себе: «Я замечательный». Я просто не верю в подобные техники. Но верю в то, что мы способны выбирать, как реагировать на события, происходящие в нашей жизни. Поначалу это будет непросто. ОЧЕНЬ непросто. Но если вы действительно постараетесь, уверяю вас, с каждым разом у вас станет получаться все лучше и лучше.
Помните: не все, что происходит в нашей жизни, по-настоящему важно. Но современный мир настолько требователен и стремителен, что кажется, будто любое событие ставит нас перед выбором: жизнь или смерть. Это не так. Вы в ответе за свою жизнь, за свои эмоции. Не давайте событиям управлять вами.
И не забывайте: абсолютно все события – хорошие, плохие, неожиданные или запланированные – дают вам новый опыт и новое видение жизни. Некоторые события помогут вам, некоторые вы просто пропустите как незначительные, но многие станут невероятно полезной практикой и толчком к чему-то новому.
Тезисы
■ Мы в ответе за то, как реагируем на жизненные события.
■ Учитесь реагировать так, как хотели бы, а не так, как получается.
■ Не позволяйте событиям управлять вашей жизнью, какие бы трудности они за собой ни влекли.
Задание
Возьмите листок бумаги и напишите список ситуаций или событий, которые регулярно вас расстраивают. Коллега любит подшутить над вашим любимым языком программирования? Добавляем. Продакт-менеджер забывает сбросить капсулу из кофе-машины, когда заходит к вам в офис? Пишем. Рядом с каждым событием запишите свою обычную реакцию, которой вы недовольны. Вспомните, как часто вас расстраивали такие события. Каждый раз вы реагировали одинаково, закрепляя этот опыт. Теперь необходимо решить, что вы измените в своем поведении, когда эта ситуация повторится. Вы каждый раз огорчаетесь, что коллеге не нравится ваш любимый язык программирования. Почему? Зачем вам нужно, чтобы коллега непременно полюбил этот язык? Может, с каждой новой шуткой вы начинаете сомневаться в себе и в том, что этот язык программирования действительно хорош? Выберите адекватную реакцию, в которой не будет места огорчению. Можно надеть наушники и включить музыку, можно сходить и выпить кофе, а то и придумать блестящую остроту про язык программирования коллеги. Самое главное – прекратить реагировать так, как вы привыкли.
История из жизни
Я очень долго не мог принять реальность в том виде, в каком она есть. В виде хаоса, неопределенности, непостоянства. Возможно, это прозвучит глупо, но мне потребовались именно годы, чтобы понять, что реальность не станет сама собой меняться мне в угоду. А если я стану сражаться с ней как Дон Кихот, то просто буду терять все больше и больше сил – с каждым годом, с каждой новой схваткой. Моя работа оказалась плохим помощником в осознании этого факта: она была логичной, она была воспроизводимой, от нее я мог ожидать одних и тех же результатов при идентичных начальных данных. Попытки провернуть тот же трюк с жизнью всегда заканчивались провалом. Отчасти я стал заложником того, что умею лучше всего: я просто проецировал то, чем восхищаюсь в программировании, на хаос. На этот конфликт я потратил немало лет и нервов, но, кажется, наконец научился разделять два разных мира: восхищаться красотой кода и с радостью принимать неопределенность бытия. И это очень приятные ощущения.
Хвали себя
Неспособность похвалить себя – одна из самых страшных болезней профессионалов. Если вы еще не слышали про синдром самозванца, самое время прочитать про него. Я не претендую на знание статистики, но практически все IT-профессионалы, которых я встречал, страдали этим недугом. Отчасти это связано с тем, что перфекционизм – неотъемлемая часть нашей профессии. Отчасти – с тем, что любой профессиональный разработчик постоянно развивается, и этот нескончаемый поток новых знаний не дает ему времени прерваться и сказать себе, что он (вообще-то!) молодец.
Многие зараженные этой болезнью считают, что проблемы не существует, потому что были воспитаны на фразах «пусть тебя хвалят другие», «хвалить себя стыдно» и т. д. Многие считают, что строгость и даже жестокость к себе мобилизуют их, делают лучше как специалистов, помогают прыгнуть выше головы. Это самообман. Если мы не хвалим себя, то лишаемся гордости за свой труд, самоуважения за свои достижения и успехи.
Проблема гораздо шире, чем эмоции отдельных людей. Компаниям, как правило, невыгодно хвалить своих сотрудников, а уж делать это персонализированно – тем более. Компании предпочитают поощрять сотрудников деньгами, но деньги никогда не станут достаточным мотиватором. В конце рабочего дня (недели, месяца, пятилетия – подчеркните нужное) мы остаемся один на один с собственной усталостью и неуверенностью. Эти ощущения растут с каждой сложной задачей, с каждой переработкой и дедлайном, приближая нас к выгоранию и депрессии.
Выкиньте в мусор установки родителей о том, как и за что вас надо хвалить. Выкиньте в мусор фразу «то, что не убивает нас, делает нас сильнее». Вы не перестанете быть профессионалом, если признаете свои заслуги. Хвалите себя. Вы каждый день создаете что-то из ничего. Вы каждый день двигаете человечество вперед (нет, это не высокопарные слова, вы точно внимательно читаете эту тему?). Ваши достижения – результат невероятного труда и опыта. Если вы не будете хвалить себя сами, то придется вечно ждать этого от кого-то другого.
Начните с себя, но не останавливайтесь на этом. Когда вы достаточно продвинетесь в своей карьере и будете работать на руководящей должности, продолжайте следовать этому правилу. Хвалите коллег, когда они хорошо выполняют работу, хвалите их, когда понимаете, что это им нужно. Делайте это искренне по отношению к себе и к другим людям.
Тезисы
■ Тот, кто сказал вам, что хвалить себя некрасиво, соврал.
■ Делайте паузу и говорите себе, что вы молодец, даже если не чувствуете этого.
■ Умение похвалить себя – это умение похвалить и другого.
Задание
Думаю, вы догадываетесь, что я попрошу вас сделать. Хвалите себя! Написали классный компонент – скажите себе спасибо. Разработали биллинг для своего проекта – немедленное спасибо. Не бойтесь, что вы себя перехвалите. Если вам трудно похвалить себя за хорошую работу, то перехвалить себя вам не удастся. Будьте честным с собой, уважайте и цените свой труд.
История из жизни
Я долго учился хвалить себя. Если быть совсем точным, то я учился хвалить себя ОЧЕНЬ ДОЛГО И МУЧИТЕЛЬНО. Потребовались годы, чтобы я перестал считать, что чем больше буду себя упрекать за неидеальную работу, тем сильнее буду становиться как разработчик. Наглая, отвратительная ложь, которой я пичкал и пичкал себя, пока не становилось тошно. Нет, я не встаю перед зеркалом каждое утро и не произношу: «Да что же это у нас тут за замечательный программист, да ты же мое солнышко». Для меня умение хвалить себя стало концом постоянных самоупреков, концом вечной неудовлетворенности своей работой. Я научился воспринимать ее отстраненно. С уважением, со вниманием, с конструктивной критикой, если в ней есть что улучшить.
Перфекционизм (и как от него не спятить)
Я думаю, ни для кого не секрет, что разработчики и перфекционизм неразрывно связаны. Можно долго спорить о том, делает ли разработчика перфекционистом профессия или же, наоборот, перфекционисты часто становятся разработчиками, но это не главный вопрос. Главный вопрос заключается в том, как жить и работать, не позволяя перфекционизму отравлять наше существование.
В стремлении сделать свою работу качественно не может быть ничего плохого. Однако перфекционист перестает понимать разницу между «качественно» и «идеально». Каждое решение, каждая новая строчка кода начинает проходить безжалостную, жестокую цензуру. Идеальное ли это решение? Учел ли я абсолютно все ошибки, которые могут возникнуть в процессе работы этого кода?
Поделиться книгой: