Бежать вдвое быстрей
Предисловие
Книга написана для помощи начинающим осваивать профессию программиста. Она содержит советы для начинающих и сосредоточена на том, что называют «soft skills». Умение общаться, вести себя в коллективе, профессиональная этика, вопросы самосовершенствования как специалиста и человека.
Первая часть посвящена введению в профессию. Здесь я постараюсь рассказать об первых трудностях и неочевидных нюансах профессии. Подниму вопросы баланса между требованиями заказчиков и здравым смыслом, дам советы как справиться с первыми вызовами на работе.
Вторая часть рассказывает про работу в команде. Она так же ориентирована на новичков, но аспект смещается на взаимодействие с другими людьми и работу в команде.
И в третьей части, наверное, самой важной и сложной – рассматривается работа над собой. Главная сложность нашей профессии - это сочетание творческой работы и потребности поставить оную работу на промышленную основу. Мы должны постоянно учиться, понимать сложные концепции, разбираться в чужих идеях и, вместе с тем, придумывать и воплощать какие-то практические решения. Сочетать учебу, полет фантазии и выдачу практического результата, каждый день, из года в год. И поэтому у программистов высокие зарплаты – эффективно, на постоянной основе, так работать получается далеко не у всех.
Книга не является истинной или каким-то универсальным рецептом – все люди слишком разные. Это всего лишь попытка как-то структурировать набранный опыт и помочь другим.
Надеюсь, она будет вам полезна.
Часть 1 Введение в профессию - Глава 1-1. Что такое программист?
Программист – это посредник между компьютером и бизнесом. И платят программистам за реализацию потребностей бизнеса в программах. А у бизнеса, в свою очередь, деньги появляются от удовлетворения потребностей пользователей. Типичный пример бизнеса – интернет магазин. Где сайт, сопровождаемый программистом, лишь «верхушка айсберга». Вся логика «айсберга» зависит от бизнес условий и потребностей пользователей - это вроде как все знают, но мало кто из новичков задумывается, что за этим стоит.
У программистов есть серьезная проблема с… образованием. Люди учатся в институтах, колледжах, ходят на курсы и понятия не имеют с чем им придется столкнуться на реальной работе. Им объясняют какой-то язык программирования, что такое объектно ориентированное программирование, паттерны… назначают лабораторные и курсовые, где решают оторванные от жизни задачи. И вот приходит типичный выпускник работать в технический отдел интернет магазина, и не понимает, ни как общаться с коллегами, ни в чем заключается его работа… Все это приходится объяснять чуть ли не с нуля.
В этой книге я попробую сократить «отрыв» от реальной жизни и помочь новичкам стать успешными профессиональными программистами. Надеюсь, и вам она будет в чем-то полезна.
Итак, программист – это посредник между компьютером и бизнесом. Ключевое слово тут «посредник». Для успешной работы посредник должен хорошо понимать обе стороны. То есть перед началом выполнения задания вам нужно понять, что на самом деле нужно заказчику. Потом понять, что происходит в уже существующих программах. И только после понимания «обеих сторон» вы можете начать вносить изменения в программы.
Только если как писать программы еще как-то во время обучения объясняют, то в коммуникации с людьми, как правило, полный пробел. Как и полное непонимание такой вещи, как «производственный код».
Результатом работы программиста должен быть готовый, качественный продукт. Который ваши коллеги или пользователи могут без каких-либо проблем употребить по назначению. Именно соответствие потребностям конечного потребителя определяет качество продукта. При этом дословное выполнение технического задания вторично. А вот эти самые «потребности» зачастую не документированы и их приходится выяснять самостоятельно. Про это на курсах и в институтах не рассказывают.
Когда новичок приходит на новую работу, он обязательно сталкивается с конфликтом понятий. Ему кажется – что достаточно сделать написанное в задании, а на деле задача может оказаться на порядок сложней. Например, если вам дали задание «просто добавь новое поле» - может получиться, что кроме добавления оного поля на форму еще надо его прописать в базе данных, оформить документацию, понаставить проверок, внедрить дополнительную логику, доработать логику соседних полей… И обо всем этом вы должны догадаться сами.
Типичный пример – новичок получает типичное же задание – «Нарисуй мне окошко, с такими кнопками-полями, которые будут делать то-то и то-то. Вот рядом похожие формы, бери за основу и вперед!» Новичок открывает редактор и, по аналогии, набрасывает форму. В лучшем случае, он еще проверит, что форма работает и вроде как делает требуемое. И радостно бежит к начальнику сказать, что он де справился с работой…
Что тут может быть не так? На практике оказывается, что «не так» сделано чуть меньше чем все. Новички даже не заморачивается банальным соблюдением общего визуального стиля. В готовом продукте у формы ввода должен быть общий стиль, у кнопок и полей должны быть одинаковые отступы и смещения. Они должны использовать общие функции для проверки введенных данных. И все это приходится объяснять…
Повторюсь - мы получаем деньги за качественный продукт. Если это форма ввода, то она должна выглядеть соответственно другим формам в программе. Кнопки должны стоять на нужных местах, с одинаковым смещением – а не разбросаны по форме, как мышкой кликнулось. Но, люди приходят после обучения на работу, зачастую заплатив большие деньги за образование, и не подозревают о таких банальных вещах.
Фактически объяснение разницы между лабораторными и рабочим продуктом ложится на плечи «старших товарищей». И на работу приходят не готовые сотрудники, а «заготовки». В лучшем случае назначат куратора, который должен новичкам объяснить нюансы. Но, далеко не факт, что лично вам попадется нормальный куратор, который вам будет терпеливо отвечать на глупые вопросы. Но, если же вам, каким-то чудом, попадется подобный человек – держитесь его, слушайте внимательно и старайтесь выполнять его советы. Это самая простая и прямая дорога в профессию.
Остальным же придется все познавать на собственном опыте. Тратить время, нервы, получать выговоры или даже терять работу. И этим придется заплатить за опыт, который уже есть у ваших коллег.
Будьте мудрей, учитесь у старших программистов, читайте книги по коммуникации и софтскилам – устраняйте свои слабые стороны, и не вступайте в конфликты, и не перечьте начальству. На старте карьеры ваша задача спокойно набраться опыта и стать востребованным специалистом.
Глава 1-2. Перед тем, как писать код
В прошлой главе я сказал, что прежде чем начать писать код нужно понять истинные потребности заказчика. Но, это только «вершина айсберга», правильный код требует серьезных усилий, и я расскажу о них более подробно, дабы вы познали «глубину кроличьей норы». Однако, не пугайтесь, на старте от новичков настолько профессионального подхода никто не ждет. Я просто даю пример, к чему нужно стремиться.
Во-первых, вам нужно понять, что хочет заказчик на самом деле. Если вы новичок, и делаете какую-то задачу в первый раз – скорее всего вы что-то не поймете или поймете не правильно. Поэтому, когда вы получаете ТЗ (техническое задание), постарайтесь уточнить все непонятные и двусмысленные моменты. Любая двусмысленность, как правило, толкуются исполнителем не правильно. При этом нужно соблюдать тактичность и не надоедать с заказчику с вопросами каждые пять минут.
Для начала прочитайте ТЗ внимательно, вдумайтесь и выпишите себе все непонятные моменты. Выберите самые критичные вопросы, и уточните их у заказчика. Более мелкие вопросы, можно будет уточнить потом, по ходу работы. Только не забудьте про них… Любое недопонимание обычно выливается в неправильный код. А делать «правильный код» - это ваша задача.
Во-вторых, вам нужно разобраться, как работает та часть системы, в которую вы планируете вносить изменения. Если это формы ввода данных – то как они вызываются, как проверяются данные, как они сохраняются в базу и т.д. и т.п. Обратите внимание – есть разница между «пониманием как работает» и тем, что «показалось» с первого взгляда. Вам нужно именно первое. Не стесняйтесь почитать документацию, погонять код под дебагом, посмотреть какие функции участвуют в процессе, где они вызываются и т.п. Только после того, как вы поймете нужную вам часть системы, вы сможете спокойно вносить в нее изменения.
В-третьих, нужно понять, как функционирует система в целом, хотя бы в общих чертах. Желательно это сделать еще до начала выполнения практических задач – но, это уже зависит от условий работы. Обычно на раскачку много времени не дают и хотят какой-то результат с первых недель. Если есть возможность – читайте доступную документацию по проекту. Если нет документации подойдите к куратору – попросите объяснить общую картину, что от чего зависит, как функционирует и т.д. Хотя бы в общих словах вам это расскажут.
В-четвертых, после понимания как работает система, как работает нужный вам участок и чего хочет заказчик – обычно вы уже представляете, что нужно делать для выполнения задачи. Так вот перед тем как бежать и писать код – подумайте, а можно ли ваше решение сделать лучше? Может есть другой, оптимальный вариант? Может в процессе можно что-то улучшить? Убрать копипасту, что-то оптимизировать, отрефакторить и т.п. При этом не увлекайтесь, задуматься над лучшим кодом надо, но тратить много времени на него нельзя.
В-пятых, если мы все поняли, придумали как написать код лучшим образом, нужно задаться вопросом – а все ли я себе досконально представил? Если не все – то нужно сесть и расписать изменения более подробно, на бумаге или в электронном виде. Все равно при написании кода вам придется все продумывать, а потом переписывать код. Но, тут тоже не стоит увлекаться. Если «не придумывается» – то быстрей будет написать код, а потом уже, посмотрев, как он работает, вносить изменения.
И да – после этой оценки мы наконец пишем код.
В-шестых, после того как вы все поняли, придумали, описали и даже реализовали – нужно проверить что ваш код работает. Не проверенный код – не работает!
Желательно отстраниться и написать пошаговый план теста. Прогнать пару наиболее вероятных сценариев и проверить крайние значения. Например, если есть поле суммы – вбить туда отрицательное число или слишком большое число. Да, по сути это работа тестера, но к тестеру должен уже прийти рабочий продукт.
Кроме этого, если у вас есть вычитывающий – желательно к вашим изменениям написать короткие пояснения, почему вы сделали именно так. А если вас должен проверять тестер – то короткую инструкцию, как правильно запустить ваш кусок программы и на что обратить внимание. Вы работаете в коллективе – старайтесь облегчить работу ваших коллег. Это пойдет и на пользу общей работе и вам будет большой плюс.
Только после того как у вас есть рабочий код, сопровождаемый пояснениями, вы его отдаете своим коллегам на проверку. На этом обычный этап работы заканчивается.
Все вышеперечисленное новички или не делают, или делают по минимуму. Но, все это приходиться делать с участием других людей – вычитывающего, тестера, тимлида. Причем у этих «других людей» зарплата в разы больше зарплаты новичка. Фактически в начале карьеры новички работают в минус для команды. Их набирают в надежде отсеять адекватных и быстро обучающихся людей, которые потом принесут пользу.
Если же вы оказались в роли новичка, не тушуйтесь и не пытайтесь сделать все сразу. От вас этого никто не ждет. Постарайтесь постепенно, для себя, внедрять все выше описанные этапы. Постепенно, с опытом, вы поймете, на чем концентрировать больше внимания, а что можно пропустить. Главное – работайте над собой и старайтесь сделать качественный продукт. Коллеги ваши усилия заметят и вам помогут.
Глава 1-3. Общение с коллегами
Как правило новички, книга ведь именно для них, напрямую с заказчиком не общаются. Есть какое-то промежуточное звено, являющееся одновременно и непосредственным начальником – менеджер, аналитик, тимлид или просто более опытный программист. Это лицо разбирается в требованиях заказчика, а до новичка доносит готовое задание - «сделай 1. 2. 3…». Для новичка это большое благо, но, тот же менеджер все равно остается человеком, со всеми проблемами взаимопонимания.
Когда вы только пришли на работу – терминология и понятия руководителя отличаются от ваших. Будьте готовы, что вы будете не понимать ваших коллег. И вам придется не раз переспрашивать. Кроме того, нужно быть вежливым, ответственным, ни с кем не ругаться и т.д. Попробую это расписать более подробно:
Во-первых, всегда помните про вежливость и тактичность. Если вы пришли с института и готовы общаться с коллегами, как со своими друзьями – то это не правильно. Вокруг вас уже не дружеская компания – а серьезный рабочий коллектив. Вас окружают взрослые люди, как правило старше вас и опытные. Держите дистанцию, относитесь к коллегам вежливо и уважительно. И старайтесь избегать конфликтов - нет проще способа добиться увольнения, чем поругаться с коллегами и начальством.
Во-вторых, относитесь к работе серьезно и не забывайте демонстрировать оное отношение окружающим. Никаких игр на работе, опозданий, ухода с работы раньше срока. На работе вы должны работать. И ваш начальник должен видеть, как вы работаете и наблюдать результаты вашей работы. Даже если ваши коллеги забивают на работу и играют в рабочее время в компьютерные игры – не обольщайтесь. Пока вы не докажите, что вы полезный член команды –послабления не для вас.
В-третьих, когда вас спрашивают о сроках выполнения порученного задания – всегда берите запас времени. Если работы на час – говорите два. Два часа – пол дня. На день работы – берите два. Если на три дня – просите неделю. Программирование всегда занимает больше времени чем кажется. Тем более в начале карьеры, когда вам приходится разбираться со множеством нюансов.
И да, даже когда есть запас времени – сразу садитесь за работу. Если вы думаете, что у вас в запасе несколько дней и можно расслабиться – это большая ошибка. Болезнь «ночь перед экзаменом» должна остаться в институте. На работе вы должны показывать стабильный и качественный результат. А для этого нужно садиться за работу сразу и ничего не откладывать. Если же останется время – потратьте его на тесты и оформление документации.
В-четвертых, при получении задания внимательно его вычитывайте, и все вопросы уточните у менеджера. При этом, как я говорил, не надо все вываливать одной кучей – сначала обдумайте свои вопросы и выберите самые важные. Тактичность в том числе означает, что вы стараетесь не напрягать начальство лишний раз. Обращайте внимание на то, чем заняты ваши коллеги, подгадывайте удобное время для ваших вопросов.
В-пятых, относитесь с уважением к чужому времени и к чужому труду. Если вы можете помочь коллеге – постарайтесь это сделать. Думайте о тех, кто будет проверять ваш труд. Если есть возможность написать объяснения как вашу программу нужно проверять – напишите. Не надо подкидывать загадки коллегам. В пустую тратить время никому не интересно.
В-шестых, не забывайте отчитываться о результатах работы. Если ваш менеджер слишком занят и не интересуется, как у вас дела – подойдите к нему сами или отпишите в личку в корпоративном чате. Если вам надо куда-то отлучиться – согласовывайте это с начальством. Начальник должен знать где вы находитесь и чем вы сейчас заняты. И это не он должен за вами бегать и вас контролировать. Демонстрация, что вы ответственный работник в ваших же интересах.
В целом от новичка ничего сверхчеловеческого не требуется. Просто надо быть адекватным, ответственным, трудолюбивым работником. Для этого надо всего лишь не лениться, стараться и быть вежливым. От того как вы начнете работать – зависит ваша жизнь. Не относитесь к работе как какой-то обязаловке, не считайте, что вы тратите время зря. В начале вашей карьеры вы закладываете основу вашего будущего. Постарайтесь выложиться в начале пути – это вам с троицей вернется в будущем.
Глава 1-4. Ошибки начинающих
Немного «теории» про то, как делать качественный продукт и как общаться я вам рассказал… Давайте теперь рассмотрим несколько примеров ошибок поведения в коллективе, которые я наблюдал лично, либо слышал из первых уст.
Мой знакомый работал начальником IT отдела в филиале банка и рассказал такую историю. К ним, уже после его увольнения, пришел новичок, на вакансию администратора. Парень толковый, работал без нареканий. Но, однажды, под новый год у него произошел конфликт с главным бухгалтером.
Главный бухгалтер, женщина уже в возрасте, позвонила и попросила принести ей годовой отчет. Сетевой принтер стоял возле администратора, и распечатка шла там. На что молодой администратор ответил – «Вам надо вы и носите, это не моя работа»… А надо сказать годовой отчет в банке – это очень большая и тяжелая кипа из сотен если не тысяч листов, и пожилому человеку ее тяжело таскать. Но, главбух поднялась, и сама принесла этот отчет. После этого молодой администратор премий больше не получал, до самого своего увольнения, через несколько месяцев. А премии в том банке составляли половину заработной платы.
…
По сути конфликт глуп и выведенного яйца не стоит, и пострадал банк в целом, как и в большинстве «рабочих» конфликтов. Так вот, чтобы не создавать подобные ситуации, нужно проявлять вежливость и тактичность. Как по отношению к начальству и более старым сотрудникам, так и по отношению к молодым подчинённым.
Другой случай, произошел уже со мной. Когда я работал в IT отделе банка и к нам на практику пришли два студента. Одного из них дали мне в кураторство, я показал ему проект, поставил задачу, объяснил, что и как делать – начали работать.
Через пару дней приходит наш начальник и говорит, что у нас в городе в два следующих дня проходит IT выставка и желающие, не загруженные срочной работой, могут в рабочее время ее посетить. На следующий день на работу студенты не вышли, ни «мой», ни «чужой». У начальника, задним числом, выясняю, что они отпросились на два дня, посетить выставку, о чем меня в известность никто не поставил.
Я к этому отнесся спокойно, работа не горела, и я, естественно, на студента не полагался. Но, когда «мой студент» вернулся на работу, я его отозвал и приватно объяснил, что он поступил не правильно и объяснил почему. Человек все понял и извинился… Поясню же этот момент более подробно для вас.
Во-первых, если вас взяли на работу – то ваш непосредственный начальник должен быть в курсе, когда вы на работе присутствуете, и чем вы вообще заняты. Если вы хотите уйти с работы, вы в первую очередь должны договориться с ним. В том числе вы должны его известить, если вы заболели или у вас появляется другая уважительная причина для отсутствия.
Это необходимо не потому что «начальник должен вас контролировать», а потому что ему необходимо планировать и координировать вашу работу и работу ваших коллег. Кстати, коллег, которые с вами взаимодействуют, тоже полезно держать в курсе ваших планов. Исчезая в никуда, без предупреждения, вы подставляете весь коллектив и вешаете на себя ярлык ненадежного человека.
Во-вторых, подобные маневры, когда вы через голову непосредственного начальства о чем-то договариваетесь с вышестоящим начальством, ряд людей, особенно «старой закалки» могут воспринять как прямое оскорбление и демонстрацию, что вы их «как начальника» ни во что ни ставите. И после этого такие начальники будут относиться к подобным «героям» соответственно.
Я же в этой ситуации понял, что «мой студент» просто сглупил по неопытности, а не пытался меня «оскорбить» или увильнуть от работы – и просто объяснил человеку его ошибки. А вот если бы этот студент пришел бы на работу в соседний отдел, где сидел начальник «старой закалки» и там бы так учудил… то, скорее всего, бы получил полноценный конфликт. И этот начальник его бы выжил с работы.
По молодости и неопытности вы будете совершать какие-то ошибки. И я, в том числе, тоже совершал глупые ошибки, и вел себя в каких-то моментах бестактно. Когда я вспоминаю эти моменты, через года, мне становится стыдно… Но, на самом деле, все это не так страшно – главное учиться и не повторять подобные ошибки. И лучше всего учиться на чужих ошибках. Поэтому я вам и советую не спешить и вести себя вежливо и тактично. От всего вы не убережетесь, но хотя бы успеете посмотреть на чужих примерах, как поступать нельзя.
Не торопитесь, обращайте внимание на других людей. Не спешите судить и не судимы будете.
Еще один нюанс, который я бы хотел упомянуть… Этих двух студентов, которые сбежали на выставку, можно еще поделить на «трудолюбивого» и «ленивого». Трудолюбивый (мой) старался работать, пытался разобраться в проекте, от него было видно конкретную отдачу. Поэтому я объяснял ему его ошибки и в целом «наставлял». В том числе и в таких «рабочих моментах».
Второй же, откровенно ленился, делал работу «на отцепись» и даже играл на телефоне на рабочем месте. Я не был его непосредственным начальником, чтобы «карать за плохую работу» и в целом со студентов на практике спрос небольшой. Но и отношение к «ленивому» у меня сформировалось… безразличное. И, когда эти два студента накосячили с побегом на выставку, я второму даже не пытался ничего объяснить.
Окружающие вас люди видят, как вы относитесь к работе и к коллективу, соответственно, они так же относятся и к вам.
Глава 1-5. Проблема жертвы
После того, как вы понимаете, как правильно работать, понимаете, что надо заказчику, осваиваете общение с коллегами – к вам приходит понимание, что вы физически не можете выдавать 100% качественный продукт. Наше время ограничено, и постоянно приходится чем-то жертвовать – либо качеством кода, либо потребностями пользователей. Есть еще вариант работать сверхурочно и в выходные, чтобы успеть сделать всем хорошо, но это годится только как временная мера. Перегрузка и отсутствие отдыха ничем хорошим не заканчивается. И хорошему программисту приходится в этом разбираться и искать баланс, искать чем пожертвовать, чтобы вытянуть приемлемый уровень качества за приемлемое время.
Жертва качеством кода – называется накоплением технического долга. Эта метафора означает несовершенство программ, затрудняющее их сопровождение и развитие. Это непонятно написанный код, плохая архитектура, недостаточная документация, отсутствие автотестов, «костыли» быстрых решений… Все то, что замедляет разработку или вообще делает ее невозможной.
«Долгом» все это назвали из-за меткого сравнения с процентами по кредиту. Например, для быстрого решения какой-то задачи мы делаем простую вставку в программу… Эта вставка работает, но она выбивается из общей архитектуры и про нее надо помнить, когда вносишь новые изменения. Мы понимаем, что поступили плохо, но как бы «взяли кредит» ради быстрого решения. И в будущем, каждый раз, когда вносим изменения в этот модуль, нам требуется больше времени для его понимания и внесения корректных изменений - так мы «платим проценты».
На самом деле технический долг – это огромная проблема для программистов. Суть проблемы – долги добавляются линейно, а проценты растут по экспоненте. И заказчики, как правило, этого не понимают…
Поясню на примере – пусть у нас есть модуль оповещения, который просто отправляет e-mail сообщения. Простой, понятный, работающий без сбоев… Потом в голову заказчика приходит мысль, что e-mail адресов у пользователей может быть несколько, и поддержку нескольких адресов нужно сделать вот прямо сейчас… Мы делаем простую вставку, которая ищет дополнительные адреса пользователей, и по всем ним отправляет сообщения. Пусть сложность модуля возрастет примерно на 10%, и мы будем тратить на 20% больше времени на сопровождение. Не так страшно…
Через некоторое время заказчика «осеняет» - что неплохо бы отправлять еще и SMS сообщения. Причем, раз структура оповещений завязана на этот модуль, то придётся в нем и делать. Добавляем рядом цикл, добавляем новые шаблоны, поиск нескольких номеров телефонов… Сложность модуля возрастает по сравнению с изначальным раза в полтора… Сложность же внесения изменений возрастает в два раза и уже сильно осложняет работу.
Дальше – больше. Добавляются push-уведомления, очередь сообщений с приоритетами, отложенные рассылки, поддержка маркетинговых программ в шаблонах. И простой как палка модуль превращается в страшное непонятное чудовище. Программисты перестают понимать, что там происходит, и вносят правки по принципу «воткнуть по аналогии, авось заработает». Через некоторое время это перестает спасать - модуль перестает работать стабильно, правка ошибок генерирует новые ошибки от которых страдают десятки тысяч пользователей… Крах, коллапс… финал.
Технический долг – типичная причина провала проектов. И, что самое печальное, руководство, как правило, не понимает необходимость постоянной борьбы с ним. А если и понимают, то зачастую откладывают «погашение» - ведь сейчас надо отчитаться перед начальством, показать проект инвесторам, выйти на рынок, успеть провести акцию и т.д. и т.п. Тут программист может оказаться заложником ситуации, не в силах что-то изменить… оказаться в роли лошади, которую гонят на убой.
Это тяжелый момент в нашей профессии, необходимо отслеживать такие вещи и постоянно работать с начальством. Объяснять необходимость рефакторинга и самому постоянно работать над кодом, вести документацию, добавлять автотесты, улучшать архитектуру и как-то выбивать под это все время. А если руководство не идет на встречу, и вы видите, что все катится в пропасть – то начинать искать новую работу.
Чтобы не попасть в такую ловушку – при поиске новой работы, обращайте внимание на код с которым вам придется работать. Легко ли его понимать? Есть ли актуальная документация? Ведутся ли автотесты? Насколько руководство понимает технические проблемы? Насколько профессионален коллектив? Есть ли обратная связь между программистами и заказчиком?
Кстати говоря – испытательный срок, это не только когда работодатель смотрит на нанимаемого работника, но и время, когда работник оценивает условия труда. И далеко не факт, что опытный сотрудник захочет работать в какой-то компании, даже если там платят «выше рынка».
Подходите серьезно к поиску работы, ищите профессиональные команды, где следят за качеством и приучат вас делать так же. Особенно в начале карьеры, когда вы толком не понимаете, что происходит и не можете наладить обратную связь с заказчиком и руководством.
Другой типичный пример «жертвы», но уже со стороны заказчика – это завышение сроков. Чтобы не напороться на необходимость раздувать технический долг хороший программист систематически завышает сроки выполнения задач. Примерно раза в два. После него идет хороший менеджер, который увеличивает этот срок в полтора раза. После менеджера идет хороший руководитель, который на выполнение проектов закладывает еще 20-30% запаса. И, кстати, все это помогает, но не спасает от проблемы технического долга.
Подобная «миграция сроков» - естественный процесс в нашей профессии. Такова специфика нашей работы, что при первичной оценке сроков, за редким исключением, их не получается оценить точно. Постоянно «появляются» дополнительные сложности, при оценке не учитывается часть требуемого функционала, заказчик что-то «вспоминает», в процессе теста и эксплуатации всплывают критические моменты, на которые раньше не обращали внимание… И все это нужно решать и приводить в продукт в порядок.
Невозможность оценить сроки выполнения задач – большая проблема нашей профессии и напрямую мы с ней бороться не можем. Приходится действовать непрямыми методами, и постоянно балансировать между желаниями заказчика и тем, что мы можем качественно воплотить в текущих условиях. Умение же правильно жертвовать и хоть как-то реалистично оценивать сроки выполнения, приходит только с опытом. Обращайте внимание на такие моменты, учитесь общаться с заказчиками и коллегами. Все это вам не раз пригодится.
Глава 1-6. Простые правила
В прошлой главе я затронул проблему жертвы и рассказал про технический долг. Эффективно решать подобные проблемы можно только после наработки определенного опыта. Но, ждать пока вы оный опыт наработаете, вы не можете и бороться с тем же техническим долгом вам надо прямо сейчас. Для этого нужны какие-то доступные решения… и такие решения есть.
Есть ряд простых правил, ориентируясь на которые вы можете улучшить техническим долгом и не только. Но, в них есть особенность. И решение, и проблемы лежат в области человеческой психологии. Чтобы они заработали вам нужен мотив и постоянная работа над собой. Найти правила не сложно, кучу подобных советов можно найти в литературе и в интернете – важно их начать соблюдать. Проникнуться определенными принципами и только тогда они начнут работать.
Еще важно понять – почему это решения работают? Откуда возникают такие проблемы? И решать их осознанно, в разы эффективней. Попробуйте разобраться, что лично у вас вызывает сложности? Почему? В чем корень ваших проблем и как с ним бороться?
Впрочем, достаточно вступления… Перейдем к правилам:
Правило бойскаута – оставь код после себя лучше, чем он был до тебя («оставь место стоянки чище, чем оно было до твоего прихода»). Это правило для борьбы с техническим долгом. Просто старайтесь вносить изменения так, чтобы код после вас хоть немного, но стал понятней и работал стабильней. Чуть-чуть отрефакторить функцию, сделать более понятным какой-нибудь цикл, переименовать переменные. Его соблюдение не займет много времени, всех проблем не решит, но удержит систему от спадания в яму деградации.
Почему же с техническим долгом так тяжело бороться? Да потому что над нами довлеет решение задачи заказчика, а то и нескольких. И, как правило, есть срок сдачи и другие ограничения, в которые мы должны уложиться. Наш мозг, под давлением, ищет максимально короткий путь для решения текущей задачи. Чтобы сделать код хорошим, нам нужно отвлечься от первой задачи и поставить себе вторую задачу. А задачи априори ставит нам заказчик, а заказчику интересно решение задач бизнеса, а не чистоты кода…
Мы привыкаем работать по «задачам сверху», мы привыкаем идти по короткому пути… Это нормально, это особенность человеческого мозга – но это губительно для программ. Обычно нет «команды сверху» и нет регулярных проверок чистоты кода. Но, мы можем «обмануть» систему и ввести дополнительное условие. Соблюдением простого «правила бойскаута» отрезать большую часть негативного эффекта.
Не бей стекла – соблюдай целостность архитектуры и качество кода. Первый же кривой костыль или уродливая вставка убивает модуль.
Есть теория разбитых окон – «Если в здании разбито одно стекло, и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна». Суть в чем – у человека есть психологический барьер на «нарушение чистоты». Если в здании целы стекла, то оно может стоять годами. Но, стоит разбить первое стекло и дать ему постоять – как здание превратится в замусоренную и раскрашенную помойку.
Так же и с кодом. Стоит в элегантный и понятный код прилепить наспех сделанную нашлепку – как барьер ломается. Все начинают лепить новые нашлепки, вкручивать костыли, делать непродуманные вставки… И отличный, красивый модуль вырождается в мусор.
Так вот – если у вас есть в проекте что-то хорошее, отлаженное, вычищенное – не портите! Восстановить будет очень тяжело.
Прими необходимость тяжелой работы – мы всегда стараемся «сэкономить». Закончить работу пораньше, сделать ее полегче. Это тоже часть человеческой психологии. Мы обманываем сами себя мечтой не напрягаться и получать много денег. Этого хочется всем, и все же понимают, что это обман.
Не бывает денег, признания, достижений за просто так… Везде основу составляет тяжелый и систематический труд. Физический, психологический, моральный… И чем выше вершины, которые мы хотим покорить тем тяжелей и дольше нужно трудиться. Но, мечта о «легких деньгах» всегда путается под ногами.
Сделайте выбор – или вы «не напрягаетесь» и работаете по минимуму за сколько получится, или вы отдаете себя своим амбициям и своим мечтам.
Если вы выбираете дорогу достижений, то мечту о «легких деньгах» выбросьте в корзину для мусора. Мысленно скомкайте, как лист бумаги, и выкиньте. И с этого момента помните, что тяжелый труд – это ваш выбор и ваш путь.
Примите его и сделайте его частью вашей жизни.
Всегда работай на совесть – надо всегда стараться делать свою работу качественно. Еще один ориентир и маяк, который может вам помочь стать профессионалом. Сделал задачу – спроси сам себя: «Я сделал хорошую работу?» Если вы сами себе не можете честно ответить «да» - то, надо что-то переделать. Если ответ «нет, но у меня нет выбора» - то, надо что-то менять в организации работы.
Будьте честны сами с собой и с другими людьми. Обман, попытки «сэкономить» - не ведут ни к чему хорошему. Вы сможете обмануть других людей раз-два, но в коллективе всем быстро становится понятно – кто работает, а кто халтурит. Вы можете обманывать себя долго... потому что хотите обмануться. Но, это опять же не приведет вас ни чему хорошему. Вы просто сами себя загоните в тупик отрицания и ненависти к другим людям.
Отец мне как-то сказал, что работать надо на совесть и не обманывать ни себя, ни других людей. В долгой перспективе это всегда зачтется. И эти слова стали для меня «маяком». Благодаря этому маяку я достиг всех своих целей. Чего желаю и вам.
Корень наших бед лежит в психологии. Чтобы качественно работать и писать чистый код нужно в первую очередь преодолеть себя. У каждого на этом пути свой путь и свои маяки. Что сработало у меня – не сработает у вас. Наш собственный разум слишком сложная и непонятная «игрушка». Поиск ориентиров и правил, при помощи которых мы можем изменить свою жизнь, похож на работу сапера.
Тут нельзя останавливаться – ищите собственный путь. Перебирайте методики, правила, ищите что вас зацепит. Это могут быть слова ваших родителей, это могут быть правила из книг… Вспоминайте, экспериментируйте и снова ищите. Дорогу осилит идущий.
Глава 1-7. Абстракция и декомпозиция
Человеческий мозг весьма ограниченная штука… Как пишут разные исследователи, мы можем в кратковременной оперировать максимум семью объектами. На самом деле эта цифра еще меньше. Попытки работать больше чем с тремя объектами вызывают серьезные затруднения. А пять или шесть объектов уже перегружают мозг.
Как мне кажется, развитие программирования обусловлено попытками обойти эти ограничения. Функциональное, объектно-ориентированное, модульное программирование – мы все больше отдаляемся от конкретных операций, делим их на части, заворачиваем обертки. И все это ради расширения поля функционала, с которым мы можем работать.
Представьте себе дрона с камерой, который висит над строящимся зданием. Вы можете им управлять, приближать, удалять, подробно рассматривать любую деталь – даже включить «рентген» и просветить проводку или канализационные трубы. Да – вы можете разглядеть в подробностях любую деталь, но вы не можете удержать в голове все здание целиком. Вы даже не можете удержать в голове отдельную квартиру со всеми нюансами… Но, вам постоянно нужно вносить изменения в этот дом.
Сегодня от вас требуют переделать лестницы на лифты, завтра вертолетную площадку сверху. Потом захотят бассейн, и хорошо если в подвале, а не в пентхаузе… И вам необходимо все эти проблемы решать, зачастую на ходу. Следить, чтобы здание не развалилось, имело запас прочности, работала канализация и водопровод, был свет, выполнялись требования по пожарной безопасности…
Программист выступает в роли архитектора, которому постоянно нужно перестраивать свой дом. Да – есть еще «маленький» нюанс, обычно в этом доме уже живут жильцы… и их нельзя стеснять, а тем более подвергать риску их жизни. Все изменения должны происходить «на лету», как по волшебству…
Абстракция с домом достаточно точная – но работаем мы все-таки с компьютерами, и у нас гораздо больше возможностей по перестройке нашего «дома». Узким же местом обычно оказывается голова «архитектора». С одной стороны, мы не можем уместить в несчастной голове все подробности, а с другой – они нам и не нужны. Нам нужен достаточный уровень детализации. С которым мы накрываем большую часть нюансов, и решаем большую часть проблем.
Для получения нужного уровня детализации мы «играем с камерой». Отдаляем камеру – абстрагируемся, выделяем в отдельные объекты этажи и квартиры, и мы с ними уже можем эффективно работать. Нужны детали – приближаем объект, включаем декомпозицию. Разбиваем квартиру на отдельные комнаты. Работаем с ними по отдельности.
Представьте свой проект в виде такого виртуального дома. Полетайте дроном, поработайте с фокусом камеры. Вам не нужны все подробности – вам нужно рабочее «впечатление», некий образ, которым вы можете манипулировать в сознании.
Поработайте над уровнями абстракции – они должны быть четкими и понятными: комната, квартира, этаж, дом. На уровнях не должно быть много разных объектов. Больше трех – это уже ошибка. Если у вас на этаже четыре разных типа квартир – его уже надо делить на «полуэтажи». Чем меньше разнообразия – тем лучше. Отдельное внимание уделите «мусору» - ненужным, лишним или просто выбивающимся из общей концепции объектам.
Когда я в первый раз читал «Чистый код», требование «одна операция на одну функцию» мне показалось излишним. С опытом же я понял – любое разнообразие является тормозом. Наш мозг ограничен и если мы вынуждены удерживать в памяти несколько объектов – мы «тормозим». Чем больше тормозов, тем уже наш угол обзора, тем ниже летает наш дрон. Не освободившись от мусора и не организовав четкую иерархию мы не можем построить многоэтажный дом.
Все требования по чистоте и компактности кода нужны не для «префекционизма», а для того, чтобы могли эволюционировать на уровень выше. Наведя порядок в типовой комнате, мы можем перейти к квартире. Разобравшись с квартирой – спокойно работаем на уровне этажа. Очистили и поняли этаж – можем строить дом…
Искусство иерархии и чистоты – ключ к успешности масштабных проектов. А «манипуляции с камерой» через абстракцию и декомпозицию – наш основной рабочий инструмент.
Попробуете сами «полетать дроном» по своему дому. Есть ли у вас четкая иерархия? Много ли у вас «мусора в комнатах»? Можете ли вы представить свой проект целиком?
И что вы со всем этим будете делать?
Глава 1-8. Баланс стресса
Когда рабочий копает лопатой траншею он себе примерно представляет объем работы и когда она закончится. Он с каждой лопатой видит результат своего труда, видит сколько работы он сделал и сколько осталось. Когда программист получает задание обычно он не знает, как и сколько он будет его делать. Более того, он даже не знает сможет ли он вообще решить поставленную задачу. Неопределенность – это бич нашей профессии. Нам постоянно приходится учиться, осознавать требования бизнеса, изучать уже существующий код. И при этом мы не знаем сколько усилий уйдет решение задачи, заработает ли наша программа вообще и какие ошибки всплывут при эксплуатации.
Наша работа связана с постоянными стрессами. В какой-то мере это даже полезно. Творческий процесс он такой… требует постоянной мотивации. Равнодушному человеку сложно быть программистом. Нужен какой-то стимул, чтобы постоянно учиться и придумывать что-то новое.
Обычно такой мотивацией выступает ответственность.
Ответственность перед коллективом, заказчиком, пользователями. Кроме нее - гордость, желание что-то доказать, реализовать стремление к творчеству. Мотивации разные, что-то цепляет вас сильно, что-то не очень… Но, чем выше мы забираемся, чем сложней и важней наша работа – тем больше моральная нагрузка.
Нервы изнашиваются незаметно, а последствия разнообразны и очень неприятны. Надорванное здоровье, хронические болезни, скандалы в семье и на работе.
Стрессовая нагрузка усугубляется особенностями нашей работы. Давление и расшатанные нервы мешают работать. Когда надо успокоиться и придумать хорошее решение – мы боремся сами с собой. Мы переживаем, что не сможем придумать решение – от этого становится только хуже. С натугой что-то придумав, мы не можем толком проверить свой код. Там, где нужно отрешиться и посмотреть со стороны, у нас это сделать не получается. И даже доведя очередное решение до «боя» мы продолжаем переживать – «А все ли отработает правильно? Какие ошибки всплывут?» Получается такая «спираль», и постепенно становится все хуже и хуже…
Чем больше ответственность, чем сложней и больше требований к вашему труду – тем больше вам платят денег. Когда вы попали в струю и переходите к более сложной и ответственной работе – есть опасность, что вы сами себя загоните в ловушку и перестанете справляться с моральным давлением.
Решение тут только одно – отслеживать свое состояние и сознательно избегать «перегрузки». Избегайте не комфортных коллективов, уклоняйтесь от конфликтов, избегайте выматывающей и нервной работы. Если вы приходите домой и не можете расслабиться – то нужно что-то менять. Или с вашим подходом к работе или с самой работой.
Для успешной работы программистом вы должны находиться в умерено-комфортной зоне. Не так, чтобы вообще не надо было напрягаться – для движения вперед нужен постоянный стимул. Стагнация – это тоже конец для программиста. Но и не так, чтобы нервные потрясения разрушали вашу психику и здоровье.
Если же вы все-таки решили продолжить работу, которую вы психологически не тянете - хотя бы четко определитесь ради чего это. Деньги вам здоровья не вернут.
Могу рассказать про свой опыт. После института я пошел на небольшую фирму, работающую в сфере банковского программного обеспечения. Нужно было внедрять зарубежную дорогую платформу в банки бывшего СССР. Работа была в командировках, сложная, ответственная… и несколько авантюрная. Мне полгода пришлось просидеть на небольшой зарплате, прежде чем я обучился и меня «продали». После этого зарплату с командировочными я получал, как два опытных программиста. С работой я справился, людей не подвел, успешно закрыл нужные этапы… но, через девять месяцев командировок, я уволился.
Мне чисто психологически оказалось тяжело ездить в командировки на постоянной основе… И по здоровью это тоже серьезно ударило. В итоге, я ушел на спокойную работу, где мне начали платить в четыре раза меньше…
Что самое смешное - сравнивая эти две работы, я по уровню жизни особенной разницы не увидел. Да, были доступны многие «дорогие» вещи, но деньги все равно утекали сквозь пальцы. И пользоваться я этими «дорогими» вещами толком не мог, у меня банально голова была забита работой и командировками. Есть деньги – хорошо, потратил и побежал дальше… А зачем зарабатывал – непонятно…
Единственное, почему я считаю, что время и здоровье не были потрачены зря – это ценный опыт и факт, что я смог зарабатывать хорошие деньги. Я доказал самому себе, что как профессионал я чего-то стою и смогу обеспечить семью. И попутно понял, что деньги не главное… Для бывшего студента это было важно…
Но это мой опыт… Для вас же важней ваша личная ситуация.
Если вы оказались на работе, где вам психологически тяжело – задайте себе вопросы «Почему так сложилось? Могу ли я изменить ситуацию? Зачем мне это терпеть?»
Если вы не нашли решение, и нет однозначного и четкого ответа зачем это терпеть – значит, надо менять работу. От ваших нервных срывов не будет ничего хорошего ни вашим коллегам, ни вашим близким.
Глава 1-9. Фоновые вопросы
Наша профессия непрерывно меняется. Появляются новые технологии, изменяются сферы применения программ, новые концепции становятся стандартами. И, чтобы остаться «на острие» нужно постоянно учиться. Посидев три-четыре года на одной работе, пусть и высокооплачиваемой можно с удивлением обнаружить, что мир изменился. Ваши коллеги говорят незнакомые слова, рассуждают об неизвестных вам технологиях… И при собеседовании на новую работу оказывается, что нужно знать совершенно новые для вас вещи.
Чтобы не отстать от современного мира выделяйте несколько часов в неделю на самообучение. Сделайте отдельный список, куда заносите заинтересовавшие вас термины, технологии или статьи. И раз в неделю просматривайте этот список и изучайте новое. Что-то может потребовать нескольких «сеансов», что-то освоится даже слишком быстро – ничего страшного – главное наладить процесс и поддерживать себя постоянно в тонусе.
Понятно, что не всегда возможно выделить дополнительное время. На работе может быть аврал, у вас может не остаться сил или свободное время нужно для более важных дел. Тоже ничего страшного – главное не поддаваться лени и при первой возможности все равно возвращаться к списку для изучения. В конце концов, главное в нашей профессии – это умение учиться. Мы это должны уметь, любить и практиковать.
Другой «фоновый» и очень важный вопрос – это спорт. Наша работа сидячая, связанная со стрессами, и это плохо отражается на нашем здоровье. Ожирение, подорванный иммунитет, хронические заболевания – все это бьет по нашей же трудоспособности. Повторюсь, на успешность работы программиста влияет практически все и здоровье в том числе. Поддержание своей трудоспособности – это обязанность в первую очередь самого программиста. Тимлид не будет стоять у вас над душой и загонять вас в спортзал. Это ваша личная проблема и с ней вы должны справляться самостоятельно.
Тело нужно держать в порядке, для этого требуется не так много времени. Утренняя зарядка в рабочий день – десять минут, и два-три занятия спортом в неделю – еще несколько часов. Спорт какой вам нравится, но желательно получать нагрузку на все тело (плавание, например).
С развитием удаленной работы спорт или хобби, где есть общение с людьми, стал только востребований. Человек существо общественное, ему нужно общение. Если вы будете заниматься командными играми, волейбол или футбол – то вы разом убьете двух зайцев. Получите и общение, и физическую нагрузку.
Ищите, что вам нравится, куда удобно ходить, стройте комфортный для вас график. А с вопросом – «Где на все это взять время?» я попробую помочь в третьей части, посвященной работе над собой.
И да, при поиске работы обращайте внимание поддерживает ли работодатель занятие спортом и обучение сотрудников. Это означает, что работодатель заботится о своих сотрудниках и понимает их потребности.
Третий момент, который я бы хотел затронуть – это отдых. Отдых – это такая же важная часть работы, как и сама работа (не путать отдых с ленью!). Если вы нормально не отдыхаете – хорошим программистом вы не будете. Чтобы иметь светлую голову необходимо нормально высыпаться, избегать стрессов и приходить на работу свежим и отдохнувшим.
Опять же забота об этом – ваше личное дело. Никакой тимлид не будет стоять у вас над душой и заставлять вас спать по восемь часов в сутки. Если хотите стать профессионалом вам жизненно необходимо выработать график и принципы, позволяющие вам хорошо отдыхать и эффективно работать. И совместить с тем же обучением и спортом…
Как все это эффективно совместить – вопрос индивидуальный, зависит от вашей работы, от ваших предпочтений и возможностей, дать универсальный рецепт я не могу. Зато могу дать пару советов.
Во-первых, пробуйте разные графики, разные методики повышения эффективности труда и фиксируйте результаты. Я удаленно работаю много лет и все это время вел эксель таблицу, где фиксирую результаты каждой недели. Я нашел свой «потолок» и вывел закономерности. У меня, например, не получается полноценно выкладываться более трех дней подряд. На третий-четвертый день у меня происходит падение производительности и нужен перерыв. В режиме аврала, если «партии надо», я могу проработать и четыре дня, но потом просто выгораю.
Выясните свой потолок. Занимайтесь сложными делами с утра, на свежую голову, уберите от себя все лишнее, что не нужно или мешает работе. Есть куча материалов и советов, как повысить свою эффективность – просто этим надо заниматься, пробовать разные методики и что-то для вас подойдет.
Во-вторых, не надо изменения вводить «нахрапом». Если вы решаете, что «завтра я начну новую жизнь» - то, скорее всего, у вас ничего не получится. Изменения лучше и результативней вводить постепенно, через культивацию полезных привычек. Начните с пятиминутной утренней разминки. Выделите удобное время и место, и перед утреней чашкой кофе делайте несколько упражнений. Через пару недель начните заниматься в субботу любимым спортом… сделайте это традицией.
Если что-то не получается – не расстраивайтесь. Попробуйте позже, зайдите с другой стороны – главное сохранить поступательное движение вперед, и постепенно, небольшими шагами, менять свою жизнь к лучшему.
Часть 2 Работа в команде - Глава 2-1. Вы пришли в новую команду
Вы пришли на новую работу… И сразу настраивайтесь на два – три месяца упорного труда. А еще лучше к этому готовиться заранее, как только вы приняли решение искать работу. Причин этому несколько.
Во-первых, вам нужно хорошо себя зарекомендовать. Первое впечатление важно, и чтобы оно было положительным – надо постараться. Кроме того, у тех, кто принимает людей на работу, есть такая мысль – «Если человек не хочет упорно работать при приеме на работу – будет ли он вообще когда-нибудь хорошо работать?»
Во-вторых, обычно вы приходите в уже существующий проект и вам нужно «догнать» остальных сотрудников, вникнуть в методологию, принятую на предприятии и т.д. и т.п. Есть определенный «порог входа», освоение определенного объема знаний, прежде чем новый сотрудник начнет приносит компании пользы. Вам, за испытательный срок, нужно его перешагнуть и успеть продемонстрировать способность приносить оную пользу.
Испытательный срок обычно два-три месяца. За этот срок вам надо встроиться в существующие процессы и выдать какой-то полезный результат. Фактически за это время вы делаете двойную работу – с одной стороны ускоренно учитесь, а с другой – пытаетесь сделать что-то сопоставимое с уже «обученными» сотрудниками.
В-третьих, наладить хорошие отношения с командой. С вашими коллегами, которые наваяли километры кода, от которого у вас болит голова. С менеджерами, требующими от вас непонятную ерунду. С пользователями, которые толком не могут сказать ни что им надо, ни что у них не работает… Все это надо преодолеть, понять и показать результат… Короче говоря, вам нужно запастись силами, терпением и работать, работать, работать…
В жизни это не так страшно, как может показаться по написанному выше. Обычно, в адекватном коллективе адекватные же требования к новичкам, и все вполне достижимо... Но, потрудиться придется в любом случае. Так что, настраивайтесь заранее.
Со стороны претендента более-менее понятно - давайте теперь взглянем со стороны нанимателя – что нужно от нового программиста работодателю?
Во-первых – адекватность (я даже подчеркну это слово). Само это понятие размыто, и четкое определение сложно сформулировать. Но я выделю наличие прогнозируемой обратной связи – когда вы общаетесь с человеком и осознаете, что он вас понимает и сделает то, что нужно. Когда руководитель ставит адекватному сотруднику задачу – он может прогнозировать сроки и качество выполнения задачи. Когда сокомандники общаются со своим адекватным коллегой – они получают от него, то что им нужно. Без оной «обратной связи», хотя бы в каких-то общих чертах - что вот этот человек способен закрыть вот это направление, найм сотрудника смысла не имеет.
Еще в «адекватность» входит способность нормально общаться, получать необходимые знания, уточнять задание и не плодить проблемы для других людей на пустом месте…
Грубо говоря, работодателю нужен нормальный, адекватный сотрудник, который будет спокойно выполнять свою работу. Никаких звезд с неба, гениальных открытий, передовых знаний или чего-то уникального не требуется. Но, как ни странно, довольно мало новичков оную адекватность демонстрируют…
Во-вторых – ответственность. Ответственность тоже понятие многогранное и оно меняется в зависимости от профиля работы. Ответственность тимлида совсем другая, нежели рядового программиста. Но, здесь я под ответственностью подразумеваю в первую очередь серьезное отношение к своей работе. Какая бы ни была ваша работа - относитесь к ней серьезно, старайтесь сделать ее качественно, чтобы люди могли на вас положиться. А если что-то не получается – своевременно сообщайте об этом начальству или коллегам.
Ответственность в чем-то перекликается с адекватностью. Но адекватность я связал с наличием четкой обратной связи, а ответственность – это возможность положиться на сотрудника и быть уверенным, что он сделает свою работу качественно.
Этих двух качеств достаточно, чтобы вас с удовольствием взяли на любую работу. А если вы при этом еще программировать умеете – то и вовсе замечательно.
Шутка. Но, в этой шутке есть доля шутки, а все остальное правда.
Третья вещь, не совсем очевидная претендентам – это оценка по критерию ПП (польза-проблемы). Люди делятся на тех, кто приносит пользу и тех – кто приносит проблемы. Причем как польза, так и проблемы могут быть совершенно не связанными с написанием кода. Это могут быть одни и те же люди, но вот тех, кто приносит проблемы – не любят. Причем отношение любят-не любят субъективно и какая-то малость или пустяковый конфликт может перевесить гору пользы – а могут быть проигнорированы… Оценки людей по критерию «нравится» - «не нравится» сложно просчитать, поэтому лучше не приносите проблем совсем.
Типичная ошибка новичков на новом месте работы – это попытка насадить свое собственное, правильное, видение в существующий проект. В процессе новички говорят коллегам обидные вещи про их код, архитектурные решения и указывают на ошибки в грубой форме... Возникают конфликты, обиды, они уходят «под ковер» или с ними приходится разбираться начальству – то и то плохо... Так вот – начальству совершенно не интересно заниматься гашением конфликтов или выяснять откуда в коллективе напряжение. Начальству нужен результат и нужна спокойная, рабочая команда. У него много других важных дел и когда кроме них приходится тратить время на замирение сотрудников – это вызывает сильное раздражение. Любой новичок, порождающий конфликты, переходит в категорию «проблем», пусть он даже на 100% прав. А от проблем избавляются.
Это не значит, что нужно молчать в тряпочку дабы никого не обидеть. Это значит, что нужно высказывать свое мнение аккуратно, вежливо и в конструктивном ключе – не порождая конфликты, а принося пользу команде.
Будьте адекватными людьми. Ударно работайте и не создавайте проблем. Это все, что от вас требуется.
Глава 2-2. Вежливость и тактичность
Итак, вы пришли на новую работу и готовы продемонстрировать адекватность, ответственность и ударный труд. У вас есть правильный настрой и понимание, что от вас требуется – теперь давайте поговорим более подробно о том, как профессионал работает.
Отличительная черта профессионала – вежливость. Мы хоть и пишем программы, но основа нашей работы – общение с людьми. Так вот – будьте вежливы. Держите себя ровно, относитесь с уважением к боле старшим, как по возрасту, так и по опыту коллегам. Помогайте молодым, но не допускайте панибратства. И держите некоторую дистанцию, пока не освоитесь в коллективе и не поймете, что за люди вокруг вас. Это убережет вас от многих проблем.
В сложившихся коллективах обычно уже есть определенный стиль общения. Где-то общаются на «ты», где-то на «вы». Где-то начальник «с народом» и пьет алкоголь на праздниках, где-то держит дистанцию и обращается к подчиненным только по имени-отчеству. Так вот - не надо пытаться что-то менять, старайтесь влиться в коллектив безболезненно и в процессе понять почему такие отношения сложились.
Обычно отношения складываются так, как людям удобней общаться. Кроме того, у всех разное воспитание, кто-то кому-то старый друг, и как для «тыканий», так и для «выканий» есть объективные причины. Не спешите, ненавязчиво разберитесь в этих причинах и покажите себя с хорошей стороны. И, повторюсь, пока вы будете разбираться – будьте вежливы и доброжелательны, это вам сослужит хорошую службу.
Так или иначе, не смотря на всякую вежливость, вам придется делать замечания, задавать вопросы коллегам, просить уточнения от заказчика. Старайтесь делать это тактично, не надоедая, не переходя на личности, с максимальным конструктивом. Ваша задача – сделать свою работу и сделать ее хорошо. А не доказать менеджеру, что он не умеет формулировать свои мысли, коллеге – что его код отстой, а начальнику – какой он плохой руководитель.
Воздерживайтесь от любого «негатива», пусть даже у вас наболело, вы бессмысленно потратили кучу своего времени и т.п. Взрослых людей перевоспитать очень тяжело, да и это не ваша задача. Ваша задача – сделать свою работу качественно и не собирая негатива.
Попробую объяснить, как это можно сделать на конкретных примерах.
Вы пришли на работу и вам нужно разобраться что и как работает. Вам дали документацию, что-то объяснили, что-то показали и вы начали работать. В процессе объяснений не стесняйтесь вести шпаргалку. Заведите себе отдельную папку, куда собирайте все инструкции, нужные для работы документы и настройки. Не ленитесь записывать пояснения, которые вам передали устно. Люди не любят повторять одни и те же вещи несколько раз. И лучше себя проявить педантом, который все внимательно слушает и записывает, что ему говорят, чем зарекомендовать себя неответственным, забывчивым человеком.
Далее – вы разбираетесь с каким-то функционалом. Вам не понятна одна, вторая, третья вещь… Прежде чем идти и задавать вопросы куратору или наставнику (если он у вас вообще есть) попробуйте сначала разобраться сами, насколько это возможно… Но нельзя увлекаться и затягивать время. Если вопросов много – подготовьте список. Причем формулируйте вопросы так, чтобы человек отвечающий на ваши вопросы сразу понял, что вам нужно. Люди не любят, когда новички не пытаются разобраться сами, а бездумно используют коллег в виде справочной. Тут важно продемонстрировать, что вы сами пытаетесь разобраться и прикладываете к этому усилия, а коллег дергаете, только по необходимости.
Итак, вы разобрались с нужным участком работы и находите плохо оформленный код, в нем какие-то ошибки и устаревший функционал. Не нужно сразу ломиться и требовать исправлений. Выпишите себе в файлик замечания, потом выберите какую-то очевидно «плохую» вещь и обратитесь к коллегам с предложением ее исправить, вежливо. При этом не надо привязывать этот вопрос к конкретным личностям. Например – находить через историю того, кто сделал эту ошибку, тыкать в него этой ошибкой и что-то требовать. Отталкивайтесь от конструктива, что мы можем сделать лучше для компании и проекта, обезличено. Например:
«При анализе кода было обнаружено, что функция Х некорректно работает при условиях У. Ее можно исправить вот так. Код станет работать быстрей на 30% и стабильней.»
Вместо:
«Вася написал функцию Х через ***. Она падает при передаче NULL, и половину кода можно оттуда выкинуть.»
Люди воспринимают фразу «я нашел у тебя ошибку» как обвинение. Обвинение взывает ответную реакцию, чаще всего агрессию – обвинить человека в ответ, затаить зло и т.п. Обиды, ответные обвинения, оправдания – никому не нужны. Вам и команде нужно просто исправить конкретную функцию и получить конкретную пользу проекту. Вот на этом и нужно делать акцент.
Продолжим… Вы обнаружили «ошибки», рассказали об одной из них, причем вежливо – теперь ждите ответной реакции коллег. Обычно ответом будет сдержанный конструктив, вам скажут - «Спасибо, но сейчас нет времени для исправлений, внесем изменения чуть позже». В этот момент не надо пытаться что-то навязать, потрясать списком ошибок и требовать их исправления прямо сейчас (если, конечно, ваша работа не заключается именно в этом). Оцените реакцию коллег, нужны ли им на самом деле ваши исправления? Как они воспринимают критику? Если реакция положительная и они искренне рады вашей помощи – отдайте им весь список. Откладывают на потом – посмотрите, когда у них дойдут руки до исправления.
Не хотят исправлять, опять же – навязываться не нужно. Может им лень, а может вы чего-то не понимаете или сейчас действительно нет времени. Не надо никого обвинять, просто сделайте для себя определенные выводы. В любом случае, если вас коллектив не устраивает, вы всегда можете начать искать работу в другом месте. А конфликты и обвинения ничего не дадут ни вам, ни коллективу.
Теперь попробуем зайти со стороны участника уже существующего коллектива. Предположим, что вас назначили проверять код новичка. Вы делаете замечания, но новичок «лезет в бутылку» возражает вам, и исправлять свой код не хочет. Не надо ругаться, идти на конфликт, если моменты не принципиальные – можете даже его код одобрить. Вместо ссоры – подойдите к начальству, приватно, опишите ситуацию – что мол человек вместо исправлений затягивает работу и тратит ваше время. Если человек на испытательном сроке, то несколько таких «звоночков» и испытательный срок для него закончится.
Другой вариант – неприятный вам человек уже работает, и вы иногда с ним пересекаетесь. Оный человек делает свою работу некачественно, пишет непонятный код, а ваши вопросы игнорирует. Опять же – не надо с ним ругаться, ситуацию вы не исправите. Сократите контакты с ним до минимума и в приватном порядке объясните начальству, что вы не хотите с ним работать. Объяснять надо вежливо, аргументировано и спокойно. Обычно руководители, по возможности, идут на встречу и «разводят по углам» не сработавшихся людей.
Представим себе другую ситуация – вы уже небольшой начальник и к вам в подчинение приходит «troublemaker». Человек вроде толковый, но вот он поругался с коллегой из-за какого-то пустяка, и вы вынуждены их мирить. На следующий день этот же новичок обзывает тестеровщика идиотом. Он почему-то тоже обижается, и вы опять вынуждены «проводить беседы». А у вас сроки горят, своей работы выше крыши… В этой ситуации не надо человека перевоспитывать и объяснять ему необходимость корпоративной этики. Так же не стоит ожидать, что человек проникнется и не будет больше проблем приносить, даже если он уже «все понял и обещает исправиться». Люди просто так не меняются, для этого им нужно что-то более убедительное нежели слова. Вежливо поблагодарите за работу и оформляйте его увольнение – в вашем коллективе он уже не приживется.
Вежливость, тактичность, настрой на продуктивную работу – отличительные черты профессионала. Программист — творческая профессия. Конфликты, неприятные люди на работе, напряженность в коллективе – все это снижает производительность. И во всех нормальных коллективах таких моментов стараются избегать. Не потому, что начальство не умеет разрешать конфликты… а потому, что это банально не выгодно.
Глава 2-3. Помощь и понимание
Есть еще два «слона» на которых строится эффективная работа коллектива – это взаимная помощь и взаимное понимание.
Когда вы только начинаете работать программистом помощь коллег просто спасает. Институты и курсы не подготавливают людей к трудовым реалиям. Фактически любому вчерашнему студенту нужен наставник, который объяснит разницу между лабораторными работами и реальным продуктом… Новичку же в команде, даже опытному, так же требуется помощь, и документации тут не спасает, нужно живое общение и советы от коллег. Так вот – не жалейте время на помощь другим людям, и относитесь с благодарностью, когда вы оную помощь получаете.
В любом нормальном коллективе, среди адекватных людей, помощь не забывается. Те, кому вы помогли сегодня, завтра помогут вам. Да, есть люди, которые не ценят чужие усилия, и относятся к коллегам потребительски… Но, в коллективе такие люди достаточно быстро вычисляются, и получают той же монетой.
Есть и другой момент – когда вы помогаете нормальным людям, но из-за каких-то условий вы от них ответной помощи не дождетесь. Например, вчерашние студенты, они опытному программисту никак не помогут ближайшие лет пять-десять. Но, с моей точки зрения, просто делать добро людям – это правильно. Мне, в свое время, очень помогла помощь от более опытных товарищей. И если мы будем друг-другу помогать, даже без поиска выгоды – это громадный плюс всем как на работе, так и в жизни.
Причем помощь не ограничивается схемой новичок-опытный. Она распространяется на все повседневные отношения. Нужна вам информация по незнакомому модулю, разрабатываемого вашим коллегой. Вы к нему обратились – тут же получили ответ. Да, вы бы сами все нашли, затратив полчаса. Потом коллега к вам обратится, и тоже сэкономит свое время. И таких моментов за день может набраться несколько штук, и взаимная помощь серьезно увеличит эффективность всей команды.
Обращайте внимание на возможность сэкономить другим людям время. Например, вы написали решение какой-то задачи, вычитывающему вы можете заранее написать пояснения, чтобы он быстрей разобрался в вашем коде. Тестеру вы можете подготовить инструкцию пошаговую, как проверить ваши изменения, на что обратить повышенное внимание… Я повторяюсь – но, поверьте, люди замечают и ценят такие вещи. Если вы будете тратить время на такие мелочи, то коллеги будут к вам лучше относиться, и команда будет лучше работать.
А теперь представьте, что коллегу, от которого вам нужна информация, вы на дух не переносите, как и он вас, а с тестировщиком вы благополучно поругались. Информацией вы не обмениваетесь, время не экономите. Тестировщик сначала мучается с вашим кодом, а потом уже вы мучаетесь с поиском ошибок, без помощи тестировщика. Эффективность работы такой «команды» может упасть в разы. Обычно это заканчивается увольнением части сотрудников или провалом проекта.
Другой повседневный аспект, на который я хочу снова обратить ваше внимание – это понимание. Недопонимание – основная причина исправлений и доработок кода. Хуже того – неправильно работающая программа имеет все шансы дойти до продакшена и неправильно отработать уже там… Происходит это из-за того, что люди мало внимания уделяют точности передачи своих мыслей. Заказчик озвучивает задание в ключе понятном ему лично. Менеджеры и бизнес специалисты говорят в терминах им привычны. И программистов, сторонние люди порой понимаю с трудом… А какие-то вещи могут вообще не озвучиваться, потому что про них забыли или они считаются интуитивно понятными…
Программисты сталкиваются с этим постоянно. И для нас жизненно важно добиваться понимания, как со стороны заказчика, так и со стороны коллег. И это зачастую далеко не так просто, как может показаться… Приведу пару типичных примеров:
«Нужно сделать отчет по выработке за текущий месяц»
Тут же может возникнуть вопросы: А что в нем должно быть? Для кого он? А «текущий месяц» это какой? Который сейчас идет, или предыдущий? После диалога с заказчиком выясняется, что отчет по выработке тех. отдела нужен бухгалтерии для распределения премий. А под «текущим» имеется ввиду прошлый месяц.
«Надо прописать по этим позициям, НДС равный 10% (длинный список прилагается)»
Возможный вопрос - «А у нас уже есть позиции с НДС равным 10%, которые не попали в список, что с ними делать?». По результатам выясняется, что оным позициям нужно прописать НДС равный 20%... Про это думали, но в задании забыли явно упомянуть…
Есть путаница в терминологии. Например, вы работаете в онлайн магазине и ваш продукт может находиться в «категории», на «полке» или в «наборе». Это все отдельные не пересекающиеся сущности, используемые в разном функционале. И все три понятия стабильно путают как менеджеры, так и разработчики… Не специально – просто говорят одно, а думают другое. Чтобы с этим как-то бороться, полезно в команде иметь справочник терминов, в котором внутренним понятиям задано однозначное определение и везде требовать использовать термины в соответствии со справочником.
В нашей работе всегда нужно добиваться понимания, как вы должны полноценно понимать, что от вас хотят, так и ваши коллеги должны понимать вас. При этом важно не сильно «занудствовать». Проявляйте тактичность, извиняйтесь за беспокойство, объясняйте зачем все это нужно, растягиваете «подходы» за информацией по времени… Задавайте вопросы в удобный момент, между делом.
Ненавязчиво добиваться понимания, это тоже часть нашей работы. И профессионал должен уметь это делать хорошо.
Глава 2-4. Единообразие и простота
Другой способ достичь и поддерживать взаимопонимание и удобство работы с кодом - это стремление к единообразию и простоте. Единообразие нужно внедрять и поддерживать везде, где только можно. В оформлении кода, в используемых модулях, в API, в структуре баз данных, документации… Естественно, с учетом целесообразности.Где-то применение, например, разных модулей обусловлено производственной необходимостью. Стандарты кода, в разных проектах для разных заказчиков могут отличаться… Но, везде, где мы можем с небольшими затратами достичь единообразия – к нему надо стремиться, и это существенно повышает эффективность работы команды.
Любое разночтение в документации, коде, используемых модулях и т.п. ведет к потерям времени, непониманию и, как следствие, к ошибкам. Бороться с этим можно и нужно, на всех участках проекта.
Самое простое – начать с определений. В идеале любая сущность, в коде, в базе данных, в документации, в устном общении, должна иметь одно однозначное определение. Если валюта у нас называется currency – она должна везде называться currency. Срок действия – valid_time. Текущий день – today и т.д. и т.п.
Далее – реализованный функционал, он должен реализован один раз в одном месте. Если в проекте использует, например, округление, то везде должна использоваться только одна, реализованная в одном единственном месте функция округления. Если же у каждый будет делать округление как бог на душу положит, неизбежно появление расхождений. На веб клиенте у вас будет одна сумма, при пополнении счета другая, при оплате третья. Отлавливаются и исправляются подобные баги тяжело… поэтому, лучше соблюдать элементарный порядок сразу и не доводить до такого.
Разнообразие используемых сторонних модулей и библиотек должно быть сведено к минимуму. Используем мы, например, для работы со строками модуль А. И во всем проекте для подобных задач должен использоваться только он, а не три-четыре аналога в следствие предпочтений разных членов команды.
Код… Код должен быть написан в едином стиле. Даже если стиль проекта расходится с вашими предпочтениями, даже если у вас принят другой стиль. Когда вы вносите изменения в проект, оные изменения должны быть выполнены в стиле проекта. Если же надо поменять стиль – то стиль меняется целиком, во всем проекте. А не так чтобы новые заплатки в одном стиле, старые во втором, исходный код в третьем…
При приходе на новый проект всегда читайте существующие документы проекта. Ознакомьтесь со стилем, правилами наименования функций и переменных, посмотрите перечень используемых модулей. Не надо придумывать велосипед, и рисовать функцию, например, получения текущей даты – поищите уже существующую и используйте ее. По максимуму используйте уже существующий код. Пишите в уже принятом стиле. И всегда держите в мыслях, что после вас, на ваш код, придут другие люди, которые тоже будут этот проект изучать, и мы должны максимально облегчить для них работу.
Если правил оформления кода в природе не существует, попробуйте постепенно, не торопясь, ввести собственные. Лучше всего использовать как базу уже существующие и распространённые стандарты, от того же Google, как пример.
Второй принцип, ведущий к взаимопониманию и эффективной работе команды – это стремление к максимальной простоте. В документации, коде, структуре базы данных – все части проекта желательно периодически проверять и задаваться вопросам – «А можно ли это сделать проще?» Сделать просто, на самом деле, довольно сложно. Если у вас есть десяток требований от заказчика, гораздо проще бездумно наклепать десять if-ов, чем свести их в единую, логичную и простую структуру. Ради простоты нужно тратить время на анализ, вести диалог с заказчиком, проводить рефактор проекта. Но, в качестве награды, вы получите понятный, хорошо работающий проект, который приятно сопровождать и развивать.
Любой используемый, приносящий деньги, функционал имеет тенденцию разрастаться. Возьмем, например, тот же интернет-магазин. На старте вы интегрировали в него стандартную оплату по карточке. Но, сайт развивается, аудитория увеличивается и оказывается, что не всем клиентам удобно платить по карте. Нужен PayPal, Qiwi, WebMoney, мобильные операторы. Вы добавляете одно, второе, третье, сверху добавляются требования от маркетинга – бонусы, скидки, партнерские программы… В результате простой модуль, о котором у вас не болела голова, вырождается в нечто непонятное и громоздкое.
Процесс роста естественен, предугадать его не получается, и держать код в порядке возможно только за счет периодического осознанного рефактора. Добавили несколько «фич», набрали некоторую критическую массу и переработали код модуля на более понятную структуру, которая логично накрывает все текущие потребности.
Кстати, еще один интересный момент – при планировании желательно закладываться только на текущий известный функционал. Попытки предугадать и заранее сделать универсальный, на все случаи жизни, модуль, обычно оказываются лишними и чрезмерно усложняют код. Обычно мы угадываем не правильно, делаем лишнюю, даже вредную, работу.
Глава 2-5. Хороший код – понятный код
При командной работе хороший код – это в первую очередь понятный код. Вы можете написать работающий код, делающий все что нужно, но, если ваши коллеги не могут легко в нем ориентироваться – его в производстве использовать нельзя. Может показаться парадоксальным, но, не работающий и понятный код, лучше рабочего и непонятного…
Как я писал выше – любое непонимание ведет к проблемам. Если ваш код не понимают коллеги – они не смогут с ним корректно работать. Из-за непонимания постоянно будет задерживаться работа и плодиться ошибки. Естественно, в команде это никому не нужно, и в любой нормальной команде ведется борьба за понятный код. И с этим связаны типичные требования к коду – писать программы так, чтобы все было понятно с первого взгляда.
В прошлых главах я говорил про такие вещи как соблюдение общего стиля, единообразие и простоту. Все это хорошо помогает сделать код понятным. Но, этого недостаточно… Все мы люди, а понимание между людьми зачастую лежит в области психологии, и писать понятный всем код, не так просто… Попробую рассказать несколько типичных требований к коду:
Одна строка – одно действиеЧасто встречающееся требование к коду. Требование вполне очевидное, но, на всякий случай, я объясню. Наш мозг наиболее быстро и качественно оперирует с одним объектом. И, для легкого понимания нашей программы, оптимально разбить весь процесс на отдельные, легко понятные действия.
Функция должна выполнять только одну задачуТоже часто встречающееся требование. Обоснования точно такие же, как в предыдущем правиле. Максимальная простота – путь к гениальному коду.
Название функций и переменных должны говорить о их назначенииПравильные названия очень помогают читать код «как есть». В идеале ваш код программы представляет собой простой текст, который рассказывает о себе сам. Приведу пример типичной задачи проверки баланса пользователя перед покупкой.
Текст:
Получаем баланс пользователя.
Сверяем его с суммой покупки.
Если денег не хватает – сообщаем об ошибке.
Если денег хватает – выдаем пользователю его заказ.
Программа:
user_balance = get_user_balance(user_id)
if (order_price > user_balance)
raise UserDontHaveEnoughMoney
issue_order(user_id, order_id)
Как вы видите, если подбирать правильные имена, то текст программы легко читается.
Сокращения вредныСокращения требуют расшифровки. Сначала человек читает сокращение, потом он понимает, что это сокращение, вспоминает расшифровку и «накладывает» ее на текст – только после этого он читает программу. Пусть это миллисекунды, но это дополнительные операции, которых можно избежать. Причем, совет избегать сокращений касается и функционала языка.
i = i + 1
Читается быстрей чем:
i += 1
Опять же, у этого правила есть исключения – случаи, когда сокращения уже являются для читателей устоявшимися терминами и воспринимаются сразу как «слово». Это могут быть общепринятые сокращения – например НДС (он же VAT на английском), или устоявшиеся в вашей команде термины. Решать, что подходит, а что нет – вам придется самостоятельно. Главное тут, чтобы ваши коллеги текст программы воспринимали напрямую.
Утверждения воспринимаются лучше, чем отрицанияЭто особенность человеческой психологии. Отрицания вообще плохо воспринимаются людьми, потому что это двойная операция – сначала надо понять определение, а потом найти его отсутствие… Это даже звучит сложно… Но, на практике лучше избегать отрицаний в тех же if-условиях. Например i != 0 будет читаться хуже чем i > 0. Проверять на наличие переменной-флага лучше чем на ее отсутствие – if user_have_rights: - лучше чем if !user_have_rights:
Это может показаться мелочью, но из таких мелочей и состоит хороший код.
Двойное отрицание вообще не воспринимаетсяПричина описана выше. К сожалению, я встречал «многоэтажные» if-конструкции со вложенными отрицаниями, раскодировать их было еще той морокой… Если вы собираетесь такое «родить» - то лучше не надо. Разбейте один большой if на несколько – так будет проще и вам и вашим коллегам.
Никаких «служебных» переменных или «волшебных» чиселНельзя использовать переменные или числа с непонятным посторонним людям значениям. Если у вас есть какая-то константа, тот же НДС, необходимо под нее завести отдельную переменную с говорящим названием. В ряде языков есть служебные переменные, содержащие ошибку, параметры функции и т.п., и некоторые программисты используют их напрямую. Тем же, кто читает потом их код, приходится проводить расследование, чтобы понять, что содержит эта переменная в данном, конкретном случае. Так делать нельзя. Даже если вам необходимо использовать информацию из служебной переменной, перегоните эти данные в новую переменную с говорящим именем и используйте ее, чтобы ваш код читался as-is.
Никаких присвоений в if-условияхНекоторые языки позволяют выполнять присвоение значений переменным прямо в if-условиях. Никогда такого не делайте. Люди читают if с намерением прочитать условие. Если там будет стоять = вместо == этот оператор будет просто проигнорирован и прочитан как сравнение. И потом будут все шансы поймать очень тяжелую, трудно отлавливаемую ошибку. И оправданный гнев команды на автора оного чуда.
Комментарии появляются только когда текста программы недостаточноТекст программы сам должен рассказать, что он делает. Но, этого порой недостаточно – может возникнуть вопрос почему сделано именно так? Или необходимо описать нюансы, полезные читающему код. Так вот – комментарии служат для добавления полезной информации, почему программа написана именно так. А не для объяснения вещей, очевидных из кода.
Этот список не полный и у меня нет цели составить всеобъемлющий перечень. Я хочу, чтобы вы обратили внимание на то, что все правила выше происходят из особенностей восприятия информации человеком. Самостоятельно подмечайте нюансы, мешающие вам читать код. Попробуйте понять почему чей-то код читать легко, а чей-то не очень. И, со временем, вы выработаете свой список правил.
Глава 2-6. Следи за собой!
Про хороший код я вам рассказал, и напоследок хотел бы еще раз вернуться к поведению людей на рабочем месте. Порой, когда новички приходят в коллектив, можно наблюдать, как они в «свободное от работы время» начинают заниматься на работе посторонними вещами - смотрят фильмы, играют в игры, общаются в соц. сетях и почему-то думают, что об этом никто не догадывается.
Это не так. Коллектив видит все. Это только кажется, что все уткнулись в мониторы и на вас внимание не обращают. Но, все видят кто, куда, с кем пошел… как работает, что делает в рабочее время и с удовольствием все это обсуждают. И если с вами не обсуждают нюансы поведения «коллег» – это значит, что их обсуждают без вас. Причем, чем больше компания – тем причудливей слухи.
Даже до приема на испытательный срок, HR отдел и безопасники проверят ваши страницы в соц. сетях. Поищут ваши фотографии, почитают что вы пишите на форумах, и если что-то не понравится - вас «отфутболят», и вам никто не скажет из-за чего.
На моей памяти был такой случай, когда кандидата «зарубили» девушки HR отдела, потому что нашли в соцсетях фото где он лижет топор. Фото явно постановочное и человек просто… шутил. Но, незадолго до этого в соседнем от офиса здании, какой-то сумасшедший бегал с топором… На несколько дней раньше, может быть фото не привлекло бы внимания, но, в этот момент, из-за «шутки» человека не взяли на работу.
Следите за собой. Особенно, когда вы приходите на новую работу, где вас толком никто не знает и с удовольствием додумают про вас всякое… чему вы не обрадуетесь. И, тем более, не оставляйте нигде каких-либо компрометирующих или «шутейных» материалов. То, что вам сейчас кажется удачной шуткой, через несколько лет может вызвать неоднозначную реакцию у посторонних людей и испортить вам карьеру.
Подумайте дважды, прежде чем заводить роман с коллегой. Все ваши ухаживания станут предметом живейших обсуждений других сотрудников. Что они себе надумают, и как это скажется на вашей работе – одному богу известно.
На работе нужно заниматься работой, даже если вы все сделали, что нужно, и вам хочется отдохнуть и посмотреть фильм перед концом работы. Ваш фильм может увидеть начальник, например, в отражении от черного окна поздним вечером, и задать справедливый вопрос – «А чем ты там занимаешься?». Как это произошло с одним моим знакомым. Знакомый не растерялся, и начал бодро вешать лапшу на уши, как он работает работу. И получилось очень неудобно, когда его таки ткнули в отражение фильма в окне.
Если у вас рабочий компьютер в офисе большой компании – то практически сто процентов, что он проверяется службой безопасности. Они могут посмотреть, как содержимое компьютера, так и то что у вас на мониторе, так и поднять историю, куда вы ходили со своего телефона через офисный WiFi. Обычно на мелкие «грешки» закрывают глаза, может вы даже будете постоянно видеть, что ваши коллеги чем-то «неправильным» занимаются... Но, тут опять же, не надо рассчитывать, что лично вас пронесет, особенно на испытательном сроке.
Так же, держитесь подальше от политики и острых тем. Внутри компании вы можете банально поругаться с вашими коллегами, что никому не нужно. Все ваши высказывания в соцсетях, флаги, значки на фото в фейсбуке, всегда могут истолковать превратно и использовать против вас или вашей компании. А если это будет хоть кому-то выгодно - то это обязательно сделают. Не надо подставляться и подставлять свою компанию.
На работе надо заниматься работой и не смешивать ее с посторонними вещами. Лучше взять это за правило и всегда ему следовать.
Еще пару слов скажу о «нечестных» методах конкурентной борьбы внутри коллектива. Иногда приходится сталкиваться с людьми, не гнушающихся лжи, перекидывания ответственности и откровенных «подстав». Это неопрятный опыт, но – это тоже часть нашей работы.
Типичный примером подобного у программистов – это опытный сотрудник, пишущий программы «под себя» и отказывающегося делиться знаниями с новыми сотрудниками. Таким образом они «охраняют» свое место, или даже напрямую шантажируют руководство, выбивая себе большую зарплату. Мол кругом балбесы – а я молодец, тащу на себе кучу вещей, которые кроме меня никто сделать не может. За свою карьеру я подобных людей видел не раз и не два… и приходилось за ними разгребать «работающий» код, который на самом деле надо выкинуть на помойку.
И даже с такими людьми не стоит вступать в конфликты, и тем более не стоит идти по подобному пути. У вас есть своя работа и ее надо делать хорошо, а удаление из коллектива подобного «шантажиста» - это забота начальства. И, как правило, подобная операция требует подготовки. Если же начальство не в курсе об «истинной сущности» некоторых сотрудников, спокойно, в приватном порядке расскажите о своих впечатлениях и объясните, почему у вас сложилось такое мнение.
Любое «нечестное» поведение может какое-то время «прокатывать». Но, потом вся компания будет в курсе кто кого подсидел, и кто перекинул вину за срыв проекта со своего отдела на соседний. И отношение к подобным людям будет соответствующим.
Не ведитесь на подобные «соблазны» и старайтесь делать свою работу честно и качественно. Так будет лучше для вас самих же.
Глава 2-7. Ориентируйтесь на людей
Со временем я пришел к несколько неожиданному выводу – для успешной карьеры главное не технические скилы. Главное – репутация, связи и друзья. Если вы заработали хорошую репутацию, и имеете много знакомых в профессии, то без работы вы не останетесь, причем работы хорошей. Ваши коллеги сами будут приглашать вас в интересные проекты, на хорошие позиции. Вам не надо будет проходить через сито HR, проходить собеседования, испытательные сроки и годами доказывать, что на вас можно положиться.
Репутация работает в обе стороны. Если вы станете начальником, то в первую очередь будете вербовать в команду проверенных людей. Сначала тех, кого вы знаете лично, потом через своих знакомых. В наш современный век и в нашей современной профессии личные контакты все равно важней резюме. Набор же незнакомых людей, это всегда лотерея и куча потерянного времени.
Это еще одна причина, почему при смене места работы нужно обращать пристальное внимание на коллектив. В коллективе, где вам неприятно работать, скорее всего полезных контактов вы не заведете. Кроме того, зарплата у нас, как правило, идет «по рынку». Задачи, тоже, как правило, ставятся решаемые… А вот условия работы могут очень сильно различаться, и главное, что отличает комфортную работу от невыносимой – это люди, с которыми приходится работать. Подбирайте работу по принципу «да, с ними я хочу работать», и сэкономите себе много времени и нервов.
При приеме на работу собеседования обычно проводит непосредственное начальство, те же тимлиды. Иногда процесс собеседования разбивается на две части, руководитель проверяет софт-скилы, а привлеченные ведущие специалисты техническую часть. Вы же, если принимаете участие в собеседовании как соискатель, обратите внимание на свое впечатление от собеседующих. Насколько они адекватные люди, как себя ставят при разговоре. Поинтересуйтесь с кем вам придется работать, за что отвечать, кто будет начальником. Задайте себе вопрос – а приятно ли вам будет работать с теми людьми, что вас собеседуют?
Ищите коллективы с компетентными и адекватными людьми. Может так статься, что с ними вы пройдете не один проект и будете помогать друг другу долгие годы.
У программистов есть такая мечта – найти свою «dream-team», компанию друзей, с которыми вы будете с удовольствием работать с полной отдачей. Делать интересные проекты, достигать каких-то вершин… Ищите свою команду мечты, может ее вы не найдете, но коллег с которым вам приятно работать найдете наверняка.
Цените и держитесь друзей. В жизни случается всякое… у программистов несколько авантюрная профессия, и вы можете столкнуться с тем, что компания прогорит или заказчик вас банально кинет. Но, когда у вас есть друзья и хорошая репутация, найти себе новое место работы проблем не составит.
А если друзья вас приводят на свою фирму, то постарайтесь оправдать их рекомендации. Это важней чем зарплата. Тем более если кто-то из ваших друзей станет вашим начальником и тащит вас дальше. Нельзя в этот момент расхолаживаться и считать, что «жизнь удалась». Нужно оправдывать возложенные на вас надежды и не подставлять своего друга. Работать качественно и тянуть свою лямку, даже если вам никто слова не скажет, потому что вы друг начальника.
Часть 3 Работа над собой - Глава 3-1. Три кита плюс слон
Работа над собой, наверное, самая сложная часть нашей работы… Программирование требует способности концентрироваться, учится, придумывать что-то новое… и все это делать на постоянной основе, день за днем, год за годом. У обычного человека на это нет ни времени, ни моральных сил. Но, успешные программисты есть, и их довольно много… Это такие необычные, уникальные люди?
Нет. Успешных программистов, отличает от других людей способность работать над собой. Способность побеждать лень, концентрироваться на работе и эффективно работать вне зависимости от «внешних» трудностей. Наш единственный ресурс – это время. И если мы сможем его стабильно преобразовывать в эффективную работу – мы можем работать программистами. Ну а если нет – то лучше поискать другую сферу деятельности.
Эта часть посвящена именно работе над собой. И, с моей точки зрения, это самая важная часть книги. Условно материал можно разбить на «работу» внешнюю – организация труда, питание, отдых и «работу» внутреннею – рабочие психологические приемы, создание рабочего настроя, все что нам поможет концентрироваться и эффективно работать. Что-то из этого вам может подойти, что-то нет… а что-то вам уже давно известно. Но, если мы хотим эффективно работать – мы должны продолжать развиваться. И, в том числе, перерабатывать чужой опыт. Процесс сей постоянен, и я надеюсь в нем вам помочь.
Итак, начнем с организации труда. На эту тему есть множество материалов. И все что я скажу уже давно известно. Но, все эти материалы и советы можно свести к трем вещам:
Режим. Грамотно составить и выдерживать расписание, которое позволяет вам работать с полной отдачей и полноценно отдыхать.Планирование. Перед работой составлять план, правильно расставлять приоритеты и определять порядок выполнения задач.Дисциплина. Четко следовать плану. Работать с полноценной отдачей и не отвлекаться на посторонние дела.И, отдельным пунктом, особенно важным для начинающих программистов, я упомяну Контроль – ведение постоянного «лога», сколько вы отработали за день, насколько успешно, что вам мешало в процессе и что помогало. Это вам поможет понять свой «потолок» и выработать эффективный и комфортный график работы.
Пройдусь более подробно по всем пунктам в виде отдельных глав.
Глава 3-2. Режим
Плодотворный рабочий день, начинается вечером предыдущего дня. Для хорошей работы, вы должны вовремя и со спокойной душой лечь спать. Хорошо выспаться и с хорошим же настроением прийти на работу. Какие-то домашние ссоры, стрессы или ночные загулы перед работой, противопоказаны для программиста. Принимайте осознанные меры, дабы дома у вас была тишина и покой. Если же не получается оной тишины достигнуть, например, у вас семья и маленькие дети не дают спать по ночам, – то не рассчитывайте на трудовые подвиги пока вы не начнете стабильно высыпаться.
Для полноценного сна обычному человеку требуется порядка восьми часов. Даже если у вас получается выспаться быстрей, то все равно закладывайте еще полчаса запаса. Сон у программиста должен быть спокойный и с запасом времени. Экономить на сне нельзя, это сразу скажется на вашей эффективности.
Так же, не взирая на график работы, загруженность, важность проектов и прочее – как минимум раз в неделю должен быть один полноценный выходной, когда вы о работе вообще не думаете. Обычно это воскресение. Среди фрилансеров есть правило – не работать в воскресенье. Поверьте, это правило не на пустом месте появилось. Работа же каждый день приведет к тому, что вы будете неспособны работать вообще. И, желательно, раз в квартал иметь неделю отпуска.
Режим и график работы, приходится подбирать индивидуально. У всех разные условия работы, разное начальство и разные предпочтения. Я же только советую вам заняться этим осознанно. В начале карьеры попробуете разные варианты. Посмотрите, что вам нравится, что не нравится и насколько эффективно у вас получается работать при разных графиках. И дальше вы сможете подбирать эффективный режим под текущие условия вашей работы.
Для меня начинать рабочий день, лучше всего с сессии планирования. Обычно это занимает минут десять-пятнадцать. Я прихожу на работу, выпиваю чашечку кофе и составляю план что и как я буду делать. Важные или сложные (например, вычитку чужого кода) дела лучше делать утром, на свежую голову. Так же желательно плодотворное утро освободить от посторонних помех и тем более не тратить его на посторонние вещи. Подчеркиваю – очень важно начать утро с эффективной работы. Для этого мы заранее стараемся «освободить» утро и сразу делаем самые срочные и важные дела, не откладывая их на потом.
Кстати, если вы будете читать литературу по эффективному тайм менеджменту, то там встречаются советы устраивать сессию планирования перед сном. Мол за ночь ваше подсознание поработает над списком дел и все разложит по полочкам. У меня лично так не получается, вечером, после успешного рабочего дня, у меня голова гудит и о работе думать совсем не хочется. Но, может быть для вашей головы будет удобен другой график… пробуйте разные варианты, подбирайте то, что подойдет лично вам.
Обед… Для эффективной работы во второй половине дня необходимо «перезагрузить» голову. Обед для этого прекрасно подходит. Если вам позволяет график работы – организовывайте себе полутора или даже двухчасовой обеденный перерыв. Плотно перекусите, погуляйте на свежем воздухе, а еще лучше поспите хотя бы полчаса. За небольшой обеденный сон голова перегрузится, и вы снова будете готовы к трудовым свершениям… Правда не так как утром, но все же гораздо лучше, чем с коротким отдыхом.
Еще полезная «фишка» - делать разгрузочный день в среду. По моему опыту, я больше трех дней подряд эффективно программировать не могу. В четверг у меня уже заметно падает продуктивность, а в пятницу я откровенно торможу. Чтобы с этим бороться я стараюсь освобождать среду от любых сложных задач. Заниматься текучкой, бумажками, мелочами, организационными вопросами… все что сделать надо, но без нагрузки на мозг. Это неплохо помогает отдохнуть и эффективно отработать четверг-пятницу.
Понятно, что не все могут себе позволить такое «богатство», но сейчас многие работают на удаленке и могут попробовать разные графики. Пользуйтесь моментом и подбирайте себе удобный режим работы. Это в первую очередь в ваших интересах.
Глава 3-3. Планирование
Про планирование есть множество литературы, разного рода графики, диаграммы, способы ведения ежедневника. И я снова вряд ли вам расскажу что-то уникальное. Но, для успешной работы планирование просто необходимо. Тут я повторю основы и расскажу про свой личный опыт.
Планированием нужно планомерно заниматься! И вам нужно иметь список дел, порядок их выполнения и четко понимать, что и как вы будете делать. Лучше всего список дел разбить на два – ближнее время (день) и отдаленное (неделя-месяц). А еще неплохо, лично для себя, написать стратегический список – то, что вы хотите достичь, через пять-десять лет. Определить для себя вполне реальные цели, ради которых вы каждый день напрягаетесь на работе – это неплохой способ мотивации.
Дневной список нужен для планирования рабочего дня. Как правило, утром мы знаем, чем мы будем сегодня заниматься. Предположим, вы уже выработали режим и примерно представляете, что вы успеете за сегодня сделать. Дело остается за малым, распределить задачи по важности-срочности и определить порядок их выполнения. Как я говорил ранее – важные и сложные дела лучше делать утром, и постараться оное утро освободить от всяческих помех.
Далее, идет недельный список дел и определение уже его порядка выполнения. Как правило, в начале недели, вы отдохнули после выходных и самые важные и ответственные задачи лучше делать в понедельник-вторник. Среду, я лично предпочитаю делать разгрузочным днем - и задач в этот день ставлю по минимум, занимаюсь какой-то необходимой текучкой с прицелом, чтобы немного отдохнуть. А в четверг-пятницу добиваю остатки.
Есть много вариантов вести список дел. Я пробовал разное и остановился на «bullet journal». Bullet тут имеет значение «жирная точка» а не «пуля», и отличие оного метода в лаконичном и понятном отображении списка дел. Что надо сделать – жирная точка, выполненная задача – крестик, отмененная задача – зачеркнута. Варианты обозначений можете подобрать под себя… Главное, опять же, просто начать вести список дел и подобрать, что вам удобно лично.
И да, если вы только начали планировать свои дела на день, то в девяноста процентах случаях люди сталкиваются с переоценкой своих возможностей. Как и программирование занимает больше времени чем кажется, так и возникают какие-то новые дела, отвлекают коллеги, звонят близкие люди со своими проблемами. Советую заложить буфер на возникшие помехи в 20-30% времени. Так ваши планы станут гораздо более приближенными к реальности.
Что касается программистов, наверняка у вас на работе есть какая-то система управления проектами. В оной системе управления вы можете посмотреть какие задачи на вас висят и в каком статусе. Скорее всего вам доступен оный перечень в виде Kanban доски. Для тех кто не в курсе – это просто табличка со столбцами «Черновик», «Можно делать», «В процессе», «Готово». По этим столбцам распределены квадратики задач, которые постепенно переползают из «Черновика» в «Готово». Если вы не знаете, что такое Kanban доска – погуглите, это займет несколько минут.
Вам будет полезно иметь визуализацию состояния ваших задач. Это может быть встроенный инструмент в систему управления. Это могут быть бумажные стикеры на стенке. Это может быть что-то иное. Главное, чтобы вы буквально за один взгляд получали актуальную информацию о состоянии ваших задач.
В принципе для планирования работы достаточно блокнота для заметок и пачки стикеров, с пустым местом на стене. Я предпочитаю именно бумажный вариант, для меня описание задач на бумаге маркерами и ручкой служит дополнительным этапом обдумывания. Но, кому этим лень заниматься есть множество программ и интернет ресурсов, например - https://kanbanflow.com/
Пробуйте разные приложения и разные методы – ищите что удобно для вас лично.
Глава 3-4. Дисциплина
Предположим, что планированием и выдерживанием режима вы как-то разобрались. Обычно начать планировать список дел и как-то выдерживать режим не сложно… Сложно это делать каждый рабочий день на протяжении всей жизни. Но, предположим, что вы начали работать над собой, планируете, выдерживаете режим и видите хороший эффект от этих усилий. Но он недостаточен. Много времени уходит в никуда, на пустые, посторонние вещи. Вы отвлекаетесь сами, вас отвлекают коллеги. Планы трещат, сроки горят, работать надо, но не получается, пока не наступит самый край… Так вот, проблема «прокрастинации» (откладывание дел) есть у всех. Бороться с ней можно и нужно самодисциплиной. И только при помощи дисциплины вы сможете сесть и сразу, с полной отдачей, сделать неприятную вам работу, не отвлекаясь и не откладывая ее на потом.
Сказать подобное просто… а выработать оную самодисциплину сложно. Обычно людям для упорной работы нужна серьезная мотивация. Угроза наказания от начальника, боязнь, что вы подведете людей, вас уволят и т.п. Но, если мотивации нет и у вас на душой не стоит начальник с дубиной, это все уходит на второй план и лень незаметно вас подтачивает. Чисто на волевых усилиях себя контролировать и постоянно плодотворно работать могут единицы. Эти единицы, как правило, и становятся незаменимыми специалистами и начальниками.
Дисциплина и способность постоянно работать с высоким уровнем качества, без постороннего контроля – это ключевая особенность любого профессионала. Если вы хотите стать успешным программистом, вам надо научиться бороться с ленью. Для этого есть много способов, но, опять же, нет универсального, волшебного рецепта. Вам придется подбирать все под себя лично, и лично, своими ногами, идти по дороге самосовершенствования.
Во многом «борьба с прокрастинацией» (кстати, погуглите это словосочетание) это удел психологии, но в этой главе я постараюсь начать рассказ с процесса организации работы и потом, в других главах, перейти к психологическим приемам.
Организационно бороться с ленью мы можем следующим образом:
Сделайте план на день, чтобы у вас был четкий список задач и порядок их выполнения.Удалите с рабочего места все лишнее. У вас, в поле вашего зрения, не должно быть ничего, что вам не нужно при непосредственной работе.Уберите с рабочего компьютера посторонние чаты, сообщения, оповещения, новости, социальные сети и тому подобное.Рабочее время надо регистрировать явно. В блокноте, через приложение, но если вы отвлекаетесь – то рабочее время не начисляется, и вы это должны видеть.Если по плану надо сесть и начать работу, вы ее начинаете. Пусть перешагивая через себя, но начать нужно вовремя. Главное «зацепиться» и начать работу.
И это только начало. Базис и зацепки, которыми вы можете облегчить вашу работу.
Еще я хочу вам посоветовать вести «дневник» и записывать в него, что вам за день мешало работать и что помогало. Во всяком случае в начале вашего пути, когда вы сами еще толком не осознаете свои проблемы. Просто сесть в конце рабочего дня и записать – что вам испортило всю «малину», а что помогло настроиться на работу. Все эти моменты индивидуальны, зависят от психологии, но вам так или иначе, придется вырабатывать свой способ эффективно работать.
Есть наборы различных советов, как бороться с ленью, повысить свою эффективность, управлять временем и тому подобное. Когда я начинал работать, софт-скилы, эффективность, тайм-менеджмент не было популярной темой, и я фактическим сам на своем опыте дошел до многих вещей. Сейчас я пишу эту книгу, записываю разные советы и, между делом, открываю Брайн Трейси «Съеште Лягушку!» - практически все им описанное или перекликается с моим опытом или даже уже записано в эту книгу. Только книга Трейси переведена в 2008 году, а я пишу свою в 2021. Если бы я начал работать над свой эффективностью в начале карьеры, то, наверное, успел бы достичь больших результатов за меньшее время. Будьте мудрей меня, начинайте работать над собой со старта карьеры.
Но, вернемся к организационным вопросам. Помимо постоянной регистрации рабочего времени мне хорошо помогли два метода. Первый – это метод «помидоров», название взято от тикающего кухонного таймера в виде помидора. Суть его в разбиении рабочего времени на периоды концентрации, обычно по двадцать пять минут. И периоды отдыха, короткие – пять минут, и длинные - полчаса. Отработали четыре помидора с короткими перерывами, делаете длинный перерыв. Во время перерыва отдыхаете, во время «помидора» ни на что не отвлекаетесь. Если же, например, вам позвонили, и вы отвлеклись – то «помидор» надо сбросить.
Метод помидоров отличная вещь для тренировки дисциплины и концентрации. Особенно мне понравилось ставить громкий тикающий таймер, который психологически помогает работать и не отвлекаться. Проблема только в том, что для программистов он плохо подходит:
Самая эффективная работа у программистов начинается после «погружения в проблему». Обычно такое погружение длится полтора-два часа. Попытки «выныривать» через 25-30 минут, ломают погружение и вредят работе.Наша работа связана не только с компьютерами, но и с общением, с коллегами с заказчиком. Вот мы пишем код, помидор тикает – а тут подходит коллега с рабочим вопросом...Так же прямо во время работы, нам самим приходится уточнять многие нюансы у коллег у заказчиков… Помидор тикает, нам для дальнейшей работы нужно уточнить какой-то вопрос – а коллега на чат не отвечает.При всех минусах я всем советую попробовать этот метод (более подробное описание есть в интернете). И обязательно, чтобы слышно было тиканье таймера. Подберите какой-нибудь проект где вы можете работать отвлекаясь по минимуму. И попробуйте кушать «помидоры», насколько у вас получится выдерживать 25-минутки без отвлечений.
Второй метод – «погружения», выработался у меня за несколько лет посдельной работы. Он уже «заточен» конкретно под программирование. Со временем я обратил внимание на то, что эффективно программировать получается на протяжении некой сессии в размере часа-двух. Я примерно за полчаса «погружаюсь» в проблему, мой мозг отключается от внешних раздражителей и концентрируется на работе. Потом следует примерно час напряженной работы «на глубине», мозг перегревается, ощущается «нехватка кислорода», работа больше не идет, приходится «выныривать» и делать перерыв не менее получаса. 80% сложной и ответственной работы я выполнял именно за счет такого «погружения».
Таких заходов, за обычный рабочий день получается сделать всего три. Если же считать чистое время сессий, даже с «погружением в проблему», получается порядка 4-х часов в обычный рабочий день. То есть за 8-часовой рабочий день, даже с большим обеденным перерывом превращается в 3-4 часа эффективной работы. За 12-часовой, авральный, рабочий день, время эффективной работы у меня получалось растянуть до 6 часов максимум. Это когда в 9 утра приходишь на работу, а домой уходишь после 22 вечера в состоянии выжатой тряпки. Повторюсь – это на посдельной работе, где платили за фактический результат.
Для меня такая ситуация была неприятным открытием. Вроде как рабочее время есть, вроде как выкладываешься, но, по сути, половина рабочего времени уходит в никуда. Но, сделать с этим у меня ничего сделать не получилось. Все потуги кардинально картины не меняли. Хороший отдых, кофе, шоколад, высокая мотивация поднимали эффективность… но выходили все те же 3-4 сессии в день… Расскажу про этот режим более подробно.
Результативный рабочий день у меня получался если удавалось прогнать два погружения до обеда. Третье уже шло после обеденного перерыва и потом, до конца рабочего дня, я занимался текучкой. Документация, тестирование, оформление задач, выяснения каких-то вопрос у коллег. Вся работа, не требующая серьезной концентрации, выполняется в конце рабочего дня. В таком режиме у меня получалось добиться максимальной эффективности.
Когда я прихожу на работу, я завариваю себе кофе и пишу список дел на сегодня. Определяю порядок их выполнения и задаюсь вопросом - «А что мне может понадобиться в процессе?». Если это какие-то простые вопросы, то стараюсь выяснить их сразу, чтобы ничего не отвлекало во время «погружения».
Сама сессия начинается с перечитывания ТЗ(технического задания). Я читаю во второй-третий раз задачу, иногда ее выписываю в блокнот и так же выписываю все вопросы, которые у меня возникают. Если я работаю над уже давно начатой задачей – перечитываю код, вспоминаю что и почему я делал. В процессе я могу отвлекаться, читать новости, форумы. Особенно утром, когда лень начинать работать. Выглядит это примерно так – я пару минут читаю задание, «спотыкаюсь», иду пару минут читать новости. Новости меня быстро разочаровывают, и я снова читаю задание, что-то выписываю, опять «спотыкаюсь», лезу на форум. Через пару минут возвращаюсь… И так проходит примерно минут двадцать. «Спотыкания» становятся все реже и реже, я все глубже погружаюсь в задачу. И где-то минут через двадцать-тридцать, от начала погружения, уже с головой ухожу в проблему – начинаю анализировать, смотреть код, программировать. И работаю до упора, пока мозг не начнет подавать признаки перегрева.
Тут важно, чтобы во время работы «на глубине» никто не отвлекал. Какой-то левый, глупый вопрос, посторонний звонок может запросто выбить из рабочего настроя. И тратить снова полчаса на погружение в сложную проблему, ни разу не приятно и ощущаешь себя каким-то дураком. А когда это случается два-три раза подряд, бывает сложно успокоиться.
В целом режим, методика работы зависит от ваших условий. Если вы можете бить спокойно бить задачи на мелкие части и не требуется серьезной концентрации – то вы спокойно можете работать через «помидоры». Со сложными задачами можно разбираться через «погружение». Можно комбинировать эти два метода. Я, когда начал работать с «помидорами», подобрал приложение где можно пропускать перерывы, спокойно ставить помидор на паузу и, главное, есть громкий звук тикающего таймера (приложение называется «Focus To-Do»). Если я «погрузился» – то я просто пропускаю перерывы. А если меня дергают с какими-то вопросами – то ставлю помидор на паузу, так делать лучше, чем злиться из-за «испорченного помидора».
Пробуйте разные методики, записывайте что вам понравилось и что не получилось. Оценивайте почему. Не надо спешить и пытаться все получить сразу. Попробуйте работать по «помидорам» несколько дней. Что-то не получится, что-то получится – запишите. На следующей неделе попробуйте другую методику. Подберите свой индивидуальный стиль под ваши условия работы. Почитайте советы по эффективному тайм-менеджменту. Выберите один совет – попробуйте его исполнять, на следующей неделе – следующий. Так, постепенно, вы наработаете свой опыт и поймете, что подходит лично вам.
Глава 3-5. Контроль
Опытный специалист уже знает свой потолок, знает свои возможности и понимает, лень ему портит работу. Молодому же специалисту зачастую непонятно – или он ленится или на самом деле у него кончились силы, может ли он еще сегодня из себя что-то выжать во время аврала или все уже бесполезно. Из-за этого «борьба с ленью» принимает неорганизованный вид и проходит не эффективно.
Так вот – чтобы понять себя и подобрать эффективный и удобный график полезно вести «лог» своей работы. Попробуете какой-то график работы – записывайте сколько в какой день у вас получилось отработать. Поработали неделю-другую, сохранили результаты, попробовали другой график – тоже сохранили результаты. Потом достаете «логи» и сравниваете эффективность. Так же логи очень помогают понять свою пиковую и недельную нагрузку.
Работая удаленно на по сдельной работе несколько лет я постоянно вел лог, и каждый рабочий день я записывал сколько я отработал и сколько я заработал. Это был простой эксель файл, где в две колонки я записывал время начала работ и время конца. Третья колонка считалась через разность первых двух и отображала отработанное время. Рядом автоматически подсчитывалась сумма за день. Так же в этом же файле я писал цели на день и недельный лог – сколько получилось отработать и заработать каждый день. Результаты каждой недели я записывал в отдельный файл и потом сводил статистику за месяц и год.
Благодаря такому подходу я выяснил что в обычный рабочий день у меня редко получается программировать больше 4-х часов. А в неделю в среднем получалось программировать порядка 18 часов. Максимум в день у меня получалось программировать 6 часов, но, это был авральный режим с зависанием на работе 11-12 реальных часов.
Но, это мой способ учета времени, когда я просто фиксировал его в эксель табличке. Вы же, если будете пробовать работать по помидорам можете сразу вести учет в помидорах. Так же в программах для работы по помидорам сразу есть и отчеты. Можно вести kaban доску с фиксацией отработанного времени. И есть куча программ, помогающих вести учет рабочего времени – просто подберите что-то под себя.
Еще полезная привычка – вести дневник. В конце рабочего дня потратьте пару минут и запишите, что в этот рабочий день вам мешало работать, а что помогало. Работа программистом во многом индивидуально и разные вещи влияют на людей совершенно по-разному. Мне, например, трудно сосредоточиться на работе если у меня произошел конфликт с женой. Приходится сначала разбираться с семейными проблемами, а потом уже работать.
Болезни, моральная накачка, график работы, выспались вы или нет, конфликты в коллективе. Важно понимать, что влияет на вашу трудоспособность. Конечно, со временем оное понимание приходит самостоятельно. Но, вы можете серьезно убыстрить процесс если будете целенаправленно обращать на это внимание. Быстрое повышение вашей эффективности в ваших же интересах.
Глава 3-6. Общение, спорт и отдых
Сейчас 2021й год, идет уже 2-й год эпидемии COVID-19 и большинство программистов отправили по домам на удаленную работу. Многие из нас мечтали сидеть в тиши, в собственной квартире, в том числе мечтал и я. Но, в реальности «всплыли» подводные камни. Человек существо общественное, и при работе на удаленке многим из нас не хватает мотивации, в виде начальника за спиной, и банального, человеческого общения. Если с отсутствием начальника можно и нужно бороться через самодисциплину, то с общение надо как-то возмещать. Иначе могут появиться чисто психологические проблемы.
Я советую – хотя бы раз в неделю, а лучше несколько раз выбирайтесь «в люди» погулять. Собирайтесь с друзьями, общайтесь, ходите в гости. Неплохо иметь какое-то хобби, где вы можете общаться с единомышленниками, играть в командные игры или заниматься командным спортом. Туризм, пеший и велосипедный – тоже отличная вещь, особенно в хорошей компании. Смена обстановки, общение, новые впечатления – все это благотворно для психики. А психика нам нужна здоровая и устойчивая.
Другой аспект нашей работы – это малоподвижность. Мы чуть ли не сутками сидим за компьютером. Общаемся, развлекаемся там же… В результате страдает здоровье, психика, появляются «профессиональные» болезни (сутулость, туннельный синдром). И это, кстати, тоже очень плохо для нашей работы. Здоровый дух может быть только в здоровом теле! А здоровый дух программисту очень нужен. Работоспособность, спокойствие и стрессоустойчивость – то, что нужно профессионалу. И для этого просто необходима регулярная физическая нагрузка.
Для этого нужно хотя бы пару раз в неделю ходить в спортзал и делать зарядку каждое утро. Плавание вместо спортзала – тоже отличный вариант. Регулярные пробежки или велотуризм - подбирайте что вам нравится, что доступно, на что у вас есть время. Но регулярная физическая нагрузка для программиста – это необходимость. Потратив на себя два-три часа в неделю, вы их с лихвой «отобьете» за счет большей трудоспособности.
Третий аспект, про который я уже не раз говорил – это отдых. Если вы ходите быть эффективным программистом – вам нужно хорошо высыпаться. А так же избегать стрессов и конфликтов… Наша работа творческая, требующая хорошей концентрации, коммуникабельности, психической устойчивости, хорошего воображения… А это все означает, что уставший, задёрганный программист, которому опостылела своя работа – работать будет из рук вон плохо. Если вы хотите стать хорошим профессионалом – вам нужно регулярно отдыхать, беречь свою психику и поддерживать позитивное настроение.
Регулярный и полноценный отдых, общение с друзьями, занятия спортом – все это поможет вам поддерживать тонус и хорошее настроение. А значит положительно отразится на вашей работе. В своем графике, не смотря на нагрузку, вы все это должны закладывать. Даже «в ущерб» работе. Да, иногда бывают в нашей работе моменты, когда приходится работать «на износ», но эти моменты редки и их надо осознанно избегать. Если же так получилось, что на вашей работе такой режим постоянен, и вы с этим ничего не можете поделать – нужно искать другую работу. Никакие деньги ваше здоровье не заменят.
Глава 3-7. Баланс энергии и внимания
В нашей работе есть некоторый… скажем так «парадокс». С утра, если настроение хорошее, погода хорошая, бывает, что энергия бьет через край и трудно сосредоточиться на скучной работе. Или наоборот, если не выспаться, энергии не хватает и вместо работы хочется спать… Много энергии плохо, мало энергии плохо.
Если хочется спать – то с этим борются через кофе, шоколад, сладости. Кстати, шутки что какой-то проект выехал на шоколадных батончиках - это не шутки. Некоторые пьют энергетики, вот только употреблять энергетики я не советую, и тем более не стоит есть разного рода таблетки. Все эти активные добавки, таблетки для работы мозга, до конца не изучены, и вы просто рискуете своим здоровьем. А здоровье важней работы. И лучше ограничиться «естественными» стимуляторами, тот же кофе, крепкий чай и шоколад. Но, еще лучше всего хорошо высыпаться, есть разнообразную, богатую витаминами еду. И тот же кофе не пить постоянно – а ограничиться одной-двумя чашками крепкого кофе в день.
Нормальный режим, хороший отдых и питание – залог здоровья и трудоспособности.
Хорошо, с сонливостью мы разобрались – а что делать, когда энергии слишком много? Мне помогают дыхательные упражнения… Просто сделать десять медленных вдохов-выдохов помогает успокоиться и прочистить голову. Потом, во время работы у меня есть, «паразитные» привычки. Я прихлебываю вкусный свежий чай, грызу зубочистки, перебираю четки. За счет таких «дополнительных» действий внимание рассеивается и становится легче сосредоточиться на нужной задачи.
Найдите хороший чай, который вам нравится. И утром, когда тяжело сосредоточиться на работе, заварите его в заварнике, желательно с теплым чехлом. Наливайте в маленькую чашку и потихоньку его прихлебываете сосредотачиваясь на вкусе. С таким посторонним, приятным делом, гораздо проще будет сконцентрироваться на работе.
Еще упомяну про такую байку как «Пик Балмера» - Балмер это бывший директор Майкрософта, и он каким-то образом посчитал, что если соблюсти правильную дозу алкоголя в крови, то программист входит в состояние оптимального баланса концентрации и расслабленности. И в оном состоянии он может писать сложные программы практически не напрягаясь… У меня же за пятнадцать лет общения с разными программистами, в том числе и с любителями «заложить за воротник», нашелся только один коллега, который признался, что в состоянии опьянения у него получается код лучше, чем на трезвую голову. Надо сказать, у этого коллеги отличный характер, он исполнительный, ответственный человек и с ним приятно было работать. Но… выпивать он все-таки избегал, и я так понял, что из-за выпивки он развелся с женой.
Не ищите простых путей. Не думаете, что если вы что-то выпьете, съедите таблетку, то у вас работа полетит. Для плодотворной работы лучше всего хорошо отдыхать. Дисциплина, отдых, маленькие психологические трюки, кофе, шоколад с чаем – вот наш удел. Старайтесь отдыхать получше. Подберите себе удобные вам привычки, помогающие в работе, и сладости, которые вам нравятся. И спокойно методично работайте не допуская авралов.
Глава 3-8. Привычки и настрой на работу
Мы поговорили про организацию, про дисциплину, про отдых, про баланс энергии… Теперь перейдем к самому сложному… к психологи и правильному настрою на работу.
Человек существо сложное… и наша работа зависит практически от всего… От физического и психологического состояния. Если физическое состояние мы можем как-то стабильно контролировать. Регулярно высыпаться, если надо выпивать кофе… то правильный психологический настрой поддерживать очень тяжело. Ссора в семье, конфликт на работе – может убить настроение и испортить рабочий день. Но, предположим, что катастроф у вас каждый день нет, и вы можете спокойно заниматься работой над собой. Целенаправленно культивируя нужное психологическое состояние.
И, снова я должен сказать, что универсального рецепта нет. Есть только долгая и тяжелая работа над собой. Воспитание сдержанности, воли, умения концентрироваться. В реальной жизни нужно себя постоянно контролировать, не давать воли эмоциям. Разбираться что вас задело и почему. Сокращать и исключать из вашей жизни факторы, которые выбивают вас из рабочего состояния. Создайте образ себя будущего, человека которым вы хотите стать, которого вы бы уважали, и в обыденной жизни старайтесь придерживаться этого образа. Поступать именно так, как вы должны поступить.
Только кропотливая работа над собой вас спасет… и несколько психологических трюков.
Самый простой способ изменить себя – это осознано завести полезные привычки. Та же зарядка утром. Наверное, нет ничего более простого и более полезного, чем утренняя зарядка. Но, так же все мы ленимся и буквально единицы делают регулярную зарядку. Простые пять минут зарядки утром помогут вам поддержать тонус и здоровье. А так же приучат к дисциплине.
Выберите себе несколько простых силовых упражнений – приседания, пресс, подтягивания, отжимания. И несколько упражнений общих или на растяжку – вращение головой, махи руками, наклоны. Скомбинируйте 5-6 упражнений, больше для старта не надо, и делайте их каждое рабочее утро в удобное время. Проснулись и перед завтраком – сделали… или пришли на работу, перед кофе – сделали. Неделю спокойно поделайте зарядку, и вы заметите, что вы сами, автоматически, готовы ее делать. Это уже не требует моральных усилий.
Добавили одну хорошую привычку – добавляйте следующую. Не надо пытаться делать весь свой день идеальным – порветесь. Шаг за шагом, постепенно изменяйтесь к лучшему. Делаете зарядку – сделайте привычным и планирование с утра. Долго раскачиваетесь перед работой – привяжите начало работы к первой чашке любимого чая или кофе. Привычка поддерживать на рабочем месте порядок, прогулка после обеда, посещение бассейна в среду и субботу. Оглянитесь – вас ждет множество возможностей сделать свою жизнь лучше. Просто надо начать.
Есть и вредные привычки… долго раскачиваться утром в понедельник, курение, лень, алкоголь, паразитные и матерные слова. От вредных привычек нужно избавляться, но от всего сразу избавиться сложно. Найдите что-то одно, что вас беспокоит и осознано с этим боритесь. Не можете бросить курить сразу – возьмите себе за правило не курить до обеда, и каждую неделю увеличивайте интервал. И так постепенно – шаг за шагом, добавляйте полезные привычки – удаляйте вредные.
Из таких шажков, подчас мелких и нудных, складывается дорога к самосовершенствованию. Да - это тяжело. На это тратится время и моральные силы. Но такими шагами вы получаете самое ценное – лучшего себя. Деньги, материальное благосостояние – это все наносное. Сегодня вам кажется, что для счастья нужна одна сумма – завтра другая. А если вы измените себя, сделаете из себя полноценного профессионала, то те же деньги придут к вам как следствие.
Воля к победе, трудоспособность, вежливость – все качества, что вы выработаете, они будут с вами всегда. Положительные качества будут помогать вам жить, отрицательные – будут портить вам жизнь. И чем раньше вы себя очистите, тем лучше жизнь у вас будет.
Глава 3-9. Маяки и зацепки
Кроме привычек я выделю еще два приема, помогающих успешно работать – маяки и зацепки. Маяк – это фраза, образ, идеал, служащий ориентиром и побудительным фактором. Примером такого маяка для меня были слова отца, которые я приводил в первой части - «работать надо на совесть и не обманывать ни себя, ни других людей. В долгой перспективе это всегда зачтется.» Я эту фразу запомнил, и она мне сильно помогла построить карьеру. Зацепки – это то, что вас «цепляет». Какой-то момент в жизни, желание, образ, сравнение, который цепляет вас, вызывает эмоции и побуждает вас действовать.
Работа с этими вещами часто идет не осознанно. Вы можете уважать качества своего отца, знакомого или какого-то образа из фильма, и не осознанно пытаться походить на него. Подражание - это стандартный механизм развития личности, это нормально. Но, часто перенимать начинают вещи ненужные и даже вредные, например – дети начинают курить или ругаться матом, думая, что они выглядят «круто». Или, пытаются в стиле руководства походить на Стива Джобса – но получается только часть с деспотичным тираном.
Если у вас уже есть жизненные ориентиры и вам уже есть на кого равняться. Посмотрите еще раз – а все ли вам нужно перенимать? У какого-то «идеала» обычно находятся «изъяны», а копируются легче всего именно вредные черты. Конкретизируйте одну-две черты, которые вы хотите перенять, и сосредоточьтесь на них.
Зацепки, в некотором роде проще и сложней. Найти их не сложно – обида на начальника, стремление быть лучшим, желание быть признанным. Даже обычное рабочее окружение со временем формирует у вас устойчивые образы в голове и влияет на вашу работу. А вот использовать их с хорошим эффектом сложней…
Например, вам нужно доделать сложную задачу. Сроки горят, но вы уже устали, делать ничего не хочется, код выродился в откровенную грязь… Все плохо, мотиваций нет, а завтра будет еще хуже... Вы пытаетесь собраться. Говорите себе – «Если я сегодня не добью эту задачу – мне завтра выест весь мозг начальник. Я подведу соседей, у которых тоже все сроки горят. У меня накроется премия. Все будет плохо! Надо собраться и наконец закончить!» Сами себя накручиваете, мотивируете – и это помогает сосредоточиться и закончить работу.
Помогает такое, конечно, не всегда и до аврала лучше не доводить – говорить себе: «Надо собраться и не откладывать работу на потом! А то будет как в прошлый раз (вспоминаете ночные бдения, орущего начальника, пустой кошелек). Сразу сажусь и все делаю качественно! Пихаю смежников, заказчика, делаю рабочий вариант в кротчайшие сроки!» И замотивировав себя, заранее раскачавшись – делаете работу заранее, без срыва сроков. Вы молодец – профессионал, а вот ваш коллега, пинавший балду до последнего, влетает на очередной выговор и его увольняют.
Сознательно работайте над собой, мотивируйте и настраивайте себя – это поможет вам сохранить рабочее место.
Зацепками бывают не только образы и воспоминания, но и вполне конкретные вещи. Приведу отрывок из книги «Война за креатив» Стивена Прессфилда.
«Я встаю, принимаю душ, завтракаю. Читаю газету, чищу зубы. Если нужно позвонить, звоню. Потом я пью свой кофе. Надеваю счастливые «рабочие» ботинки и завязываю счастливые шнурки — их подарила мне моя племянница Мередит. Я возвращаюсь в кабинет и включаю компьютер. Моя счастливая куртка с капюшоном висит на спинке стула, вместе с волшебным талисманом, который я купил у цыганки в Сент-Мари-де-ла-Мер всего за восемь баксов, и счастливым медальоном Ларго, который я однажды увидел во сне. Я надеваю его. В моей сокровищнице есть и счастливая пушка — сувенир, который мой друг Боб Версанди привез мне с Кубы, из крепости дель Морро. Я направляю ее миниатюрный ствол на свое рабочее место, чтобы она меня вдохновляла. Я читаю свою молитву — обращение к Музе из «Одиссеи» Гомера в переводе Лоуренса Аравийского, которую мне подарил мой старый друг Пол Ринк и которая обитает на полке рядом с моими запонками и счастливым желудем с поля битвы при Фермопилах. Половина одиннадцатого. Я погружаюсь в работу. Когда я начинаю делать опечатки, то понимаю, что устал. Прошло часа четыре или около того. Я чувствую, что вымотался. На сегодня довольно. Все, что я сделал, я копирую на диск и отношу его в бардачок своей машины — на случай, если произойдет пожар. Я выключаю компьютер. Уже три или половина четвертого. Мой рабочий день окончен. Сколько же страниц я написал? Неважно. Хорошо ли получилось? Я даже не думаю об этом. Главное: сегодня я преодолел Сопротивление.»
Смотрите – автор выполняет наработанный утренний ритуал. В него он вплетает разные значимые для него вещи – зацепки. «Рабочие» ботинки, шнурки, талисманы, молитва, пушка, ствол которой направлен на его рабочий стол.
За счет этих «танцев с бубном» он успешно настраивается на работу, и эффективно работает каждый рабочий день. Почему у него так получается? Потому что он удачно купил талисман у цыганки всего за восемь баксов? Ага, конечно… Да потому что он умеет работать со своим окружением и осознано им манипулирует, подстраивает его для настройки на работу. Все эти шнурки, талисманы – это зацепки, которые он вплел свое рабочее утро и последовательно дергает.
И все это вы можете взять на вооружение. Найдите значимые, наполненные для вас смыслом объекты и вплетите в свой ритуал подготовки к работе. Выпить утренний кофе из любимой кружки с принтом вашего кота. Написать список дневных целей, перьевой ручкой подаренной женой на юбилей. Когда вы выделяете цепляющие вас объекты и связываете их в ритуал наполненный для вас смыслом – вы добиваетесь полезного практического эффекта. Сознательно формируете в вашей психике режим перехода к работе.
Человек не компьютер, он не может по нажатию кнопки включиться в сложную творческую работу. Приходится тренировать волю и использовать такие, может глупые для постороннего, психологические трюки. Но, наша профессия требует стабильной творческой работы… Поэтому приходится цепляться за любые мелочи… Обращайте внимание на все, что вам может помочь в работе, и пробуйте вплетать в рабочий процесс. Для нас нет мелочей – есть только возможности стать лучше!
Глава 3-10. Смещение цели
В прошлой главе в цитате из «Война за креатив» есть еще два характерных момента, помимо «утреннего ритуала». Я повторю концовку:
«Я чувствую, что вымотался. На сегодня довольно. Все, что я сделал, я копирую на диск и отношу его в бардачок своей машины — на случай, если произойдет пожар. Я выключаю компьютер. Уже три или половина четвертого. Мой рабочий день окончен. Сколько же страниц я написал? Неважно. Хорошо ли получилось? Я даже не думаю об этом. Главное: сегодня я преодолел Сопротивление.»
Явное обозначение завершения работы, и даже какая-то награда самому себе за хорошо сделанную задачу – это отличный мотивационный прием. И, вторая хитрость - смещение цели, ему не важно сколько он проработал и чего достиг – ему важно, что он заставил себя работать и «преодолел Сопротивление». Это тоже эффективный психологический прием, который стоит опробовать.
Но, начну я немного издалека.
В обычной жизни мы себя серьезно тормозим. Вместо ориентации на вещи, гарантирующие нам стабильную и комфортную жизнь, мы мечтаем о халяве. Выиграть в лотерею, на ставках, получить инвестиции. Поиск «удачи» или ожидание халявы… серьезно тормозит развитие специалиста. Нам нужно постоянно учиться, совершенствовать профессиональные качества, работать над собой. А не «я сделал поставленную задачу и больше мне ничего не нужно».
Если вы хотите достичь чего-то серьезного – нужно принять тяжелый труд и постоянное развитие как основу жизни. Цель жизни – не достижение богатства, чтобы потом лежать потом на пляже с коктейлем в руке, а самосовершенствование и создание хороших вещей, полезных другим людям. Ради этого стоит жить и работать, а не ради денег и в погоней за «халявой». Если вы станете хорошим специалистом – то без денег вы не останетесь в любом случае. А если будете гнаться за мечтой о халяве и в пустую тратить время – потратите свои годы жизни в никуда.
Так вот – автор сознательно сместил цель дня с «написать столько-то листов» на «преодолеть Сопротивление». Сопротивление, у него, это эффект лени – то, что мешает нам работать. Автор сосредоточился на своей работе, он целенаправленно побеждает свою лень и, как следствие, имеет отличный результат каждый день. Вам ничего не мешает сделать тоже самое. Как в глобальном смысле – сознательно изменить цель жизни, так для цели каждого дня.
Сделайте целью вашего рабочего дня не задачу, назначенную руководством – а, например, отработать восемь «помидоров» или столько-то часов. Весомую, но достижимую цель, где-то рядом с вашим потолком. И закрывайте эту задачу каждый день, согласно своему, разработанному вами же графику.
Если вы побеждаете свою лень, и выполняете свой потолок каждый день – выполнять «в фоне» нагрузку обычного программиста для вас не составит труда. Причем вы будете делать свою работу заранее, а не когда «горят сроки». И у вас останется время на учебу и саморазвитие.
Глава 3-11. Медитация, дыхательные упражнения
Есть ряд дисциплин, направленных на работу с внутренним состоянием человека. Медитации, йога, цигун, ушу… Все они нам интересны с практической точки зрения – умение концентрироваться и управлять своими эмоциями очень полезно в нашей профессии. И это можно и нужно тренировать и для этого есть готовые методы тренировок.
Но, тут опять есть большое НО. Людям необходим индивидуальный подход – что-то, что цепляет одного, для другого полностью бесполезно. К тому же, очень много мусора и просто нет времени, да и желания, в чем-то разбираться. Зачастую, попробовав позаниматься, люди не получают практического эффекта и разочаровываются.
Я тоже пытался найти что-то полезное… и нашел. Меня «зацепило» совершенно случайно – в 90-е были книги в мягких переплетах, о различных боевых искусствах. И среди других книг, мне в руки попала книга про ниндзя. Там, кроме всяких фотографий стоек, описания оружия, было и практическое руководство медитативных упражнений, с простым и понятным описанием. Ради примера приведу оттуда пару упражнений:
«УПРАЖНЕНИЕ 1 Обычная медитация
Найдите тихое место, где вас никто не потревожит. Не нужно создавать полную тишину, общий небольшой естественный фон даже необходим.
Если возможно, положите на пол коврик и держите наготове маленькую жесткую подушку. Сядьте посередине коврика, вытянув ноги. Согните левую ногу и расположите ее возле живота, пяткой к себе, чтобы носок лежал на правом бедре. Затем положите правую йогу наружной частью стопы между бедром и голенью левой ноги. Наклонитесь вперед и положите под себя подушечку, чтобы вам было удобнее сидеть. Выпрямите верхнюю часть корпуса и прогните спину вперед, живот и грудная клетка должны находиться точно над вашей седалищной частью. Правую руку опустите тыльной стороной ладони на раскрытую ладонь левой руки. Концы больших пальцев касаются друг друга. Руки сложены, локти плотно прижаты к корпусу.
Это традиционное положение тела для медитации не имеет в себе ничего сверхъестественного или магического. Можно сидеть на обычном западном стуле со спинкой, сомкнув бедра и поставив стопы плотно на пол — это тоже хорошая поза для медитации.
Но восточное положение тела все-таки предпочтительнее, так как спинка стула слишком расслабляет спину, что может привести к возникновению усталости и даже ко сну. Традиционное положение тела имеет также символическое значение, приучая сосредоточиваться в определенной Позе.
Выпрямите позвоночник. Свободно опустите вперед руки. Отклонитесь несколько раз в стороны, чтобы почувствовать вертикальное положение корпуса и не терять его. Смотрите прямо; подбородок выдвиньте вперед как можно дальше. Расслабьте веки, но ни в коем случае не закрывайте глаза полностью. Рот закройте и дышите носом.
Эта сидячая поза является основой для медитации. Согнутые ноги помогают поддерживать расслабленное состояние позвоночника, поддерживая спину в неизменном положении. Следите, чтобы подбородок был подан вперед и спина чуть прогнута.
Когда вы примете эту позу, начинайте наблюдать свое внутреннее «Я».
Ощущайте свое дыхание. Сосредоточьтесь на ощущении дыхания. Вы чувствуете ток воздуха при вдохе и выдохе, чувствуете, как поднимается и опускается диафрагма. Вы ощущаете звук своего дыхания.
Произнесите слово «НИНДЗЯ» про себя. Где-то в голове что-то услышит этот звук. Отыщите, где находится это «что-то», слышащее этот звук. Сожмите руки в кулаки и расслабьте их опять. Что-то, что не участвует в этом движении, заметит это движение. Отыщите это «что-то» и идентифицируйте его.
Может быть, подумаем мы, это «что-то» принадлежит нашему духу, который просматривает наше тело. Но все несколько усложняется, так как когда мы произносим мысленно слово «ниндзя», наблюдатель рассматривает и наш работающий дух.
Что же это за вещь, которая держит нас под лупой, если она нам не принадлежит? Мы назовем его «НАБЛЮДАТЕЛЬ». Это участок сознания, являющийся его обратной стороной, обратной стороной мышления и чувств. Когда мы говорим «Я», мы имеем в виду именно этого наблюдателя. Это подсознание, и если оно не работает, то вы рассеяны, сонливы, а когда оно включено, то вам удается все.
Научитесь призывать этого наблюдателя и рассматривать различные вещи с его помощью. Во время дыхания наблюдатель контролирует его. Если вы расстроены, он рассматривает вашу нервозность, и вы видите, что вы расстроены. Поэкспериментируйте с вашим наблюдателем, чтобы яснее изучить, как он действует.»
Тут приведено обычное описание начала медитации… как сесть, на чем сосредоточиться. Как ни странно, но когда я пытался через найти в интернете что-то похожее с понятным практичным описанием, мне ничего толкового не попалось… Но, перейдем ко второму, более практичному упражнению.
«УПРАЖНЕНИЕ 2 Тренировка Наблюдателя
Когда вы уже обнаружили наблюдателя, начинайте его тренировать, он должен выполнять ваши указания. У среднего человека наблюдатель соответствует сознанию, рассеянной мысли; недостаток в самоосознании и рассеянность являются результатом того, что наблюдатель беспорядочно разбрасывается и воспринимает все попадающееся на его пути. Эта неопытность наблюдателя определяется как «интерес». Он не обращается на себя, разве что мельком, и поэтому необходимо держать наблюдателя под контролем, чтобы не быть застигнутым врасплох чувствами или событиями.
Второе упражнение называется «счет дыханий». Это название не совсем правильно, потому что главной целью упражнения является отнюдь не счет дыханий.
Счет дыханий — это простой и действенный метод, который позволяет направить активность наблюдателя на единственное задание.
Примите сидячее положение из первого упражнения. Привыкните к окружению и начинайте сосредоточивать свое внимание на дыхании. Дышите естественно, при этом мышцы живота выпячиваются и втягиваются. Не пытайтесь сознательно регулировать или контролировать дыхание. Дайте своему телу дышать так, как оно хочет.
Совместно с наблюдателем начинайте считать дыхательные движения. Каждый раз, когда вы вдыхаете, увеличивайте счет на единицу. Дойдя до девяти, начните опять с единицы. Ваше тело само знает, как себя вести: оно держится правильно, дыша естественно, время от времени моргает и делает глотательные движения. Обращайте внимание исключительно на счет наблюдателя.
Не нервничайте, если в вашем сознании возникнут посторонние мысли, и наблюдатель отвлечется на них. Представьте себе, что выполнение его основного задания сбилось, и начинайте считать снова, внимательнее. Когда вы расслабитесь, ваш дух успокоится на наблюдателе. Затем вы можете вскоре «услышать» счет: четырнадцать, пятнадцать, шестнадцать... Очнитесь и сконцентрируйтесь снова.
Это упражнение выглядит очень простым, но оно не так уж просто. Его простота помогает вам понять, правильно или неправильно вы его выполняете. Каждая ошибка становится заметной. Целью этого упражнения является сделать наблюдателя сознательно управляемым и не давать ему отвлекаться от поставленного задания. Это тяжелая работа.
Начинайте с коротких медитаций с наблюдателем. Это не утомительно, если ограничиться длительностью медитации до десяти минут. Непрерывно увеличивайте ее продолжительность, чтобы недели через две ваша медитация длилась около двадцати минут.
Естественно, время от времени вы будете отвлекаться. Шумы, визуальные помехи или мысли будут уводить ваше внимание в сторону. Не отчаивайтесь по этому поводу. Просто примите это к сведению и сконцентрируйтесь снова. Телесные недомогания каждый раз будут мешать вам все меньше.
Если ваша концентрация прервалась, оставайтесь спокойным и сидите как сидели. Бросьте взгляд на помеху и продолжайте счет. Когда вы научитесь полностью концентрироваться на духовной деятельности, вы сможете вообще не обращать внимания на мелкие физические затруднения.
Постоянно имейте в виду, что результаты этого упражнения позже найдут применение в боевых ситуациях и методах ниндзя. Счет необходим не для счета самого по себе, а для дисциплинирования сознания на сосредоточении. Это упражнение служит также для развития силы воли. Делайте его соревновательным, как в детстве, когда вы бегали наперегонки или играли в футбол. Без такой мотивировки оно может показаться труднее самой сложной физической тренировки.»
Даже если не углубляться в философию и в поиски «Наблюдателя» вы можете взять из первого упражнения описание подготовки к медитации, а потом выполнять второе упражнение на счет дыханий. У вас уже «на руках» есть практическая методика для контроля эмоций и тренировки концентрации.
В любой момент, когда эмоции и посторонние мысли мешают сосредоточиться, просто сядьте в своем рабочем кресле, прикройте глаза и сделайте девять медленных циклов вдохов-выдохов. Постарайтесь отрешиться от эмоций и сосредоточиться на дыхании. Это займет у вас полторы минуты. И даже один цикл заметно вас успокоит.
Если вам не поможет мой пример - попробуйте найти то, что «зацепит» вас. Это может быть сложно для вас лично… Но, любую дорогу можно осилить – главное целенаправленно идти по ней.
Книга, из которой взяты упражнения выше, называется «Нин-дзютсу. Книга 1. Дух воинов-теней» Стивен К. Хайес (Stephen K. Hayes). При желании ее можно найти в электронном варианте. Медитации посвящены 4-я и 5-я главы – рекомендую их внимательно прочесть.
Эпилог
Работа программистом сложная, интересная, местами нудная, а местами требует креативности и умения общаться с людьми. Она несет стрессы и содержит много неочевидных нюансов, часть из которых я попробовал вам объяснить. Быть хорошим программистом – сродни персонажу из сказки про Алису в стране чудес. Чтобы просто остаться на своем уровне – надо бежать со всех ног, а чтобы перейти на уровень выше – нужно бежать вдвое быстрей!
Но, решение всех проблем кроется в вас самих. Нужно контролировать себя, работать над собой, быть полезным членом команды… и развиваться. Постоянно учиться и развиваться. Время и ресурсы для этого есть – они кроются в нас самих. Множество сил и времени у «обычного человека» уходит в никуда. Через планирование и работу над собой, мы можем мобилизовать свои силы и в разы поднять свою производительность. Побежать в два-три раза быстрей.
Это ключ к тому, чтобы стать успешным профессионалом-программистом.
2022-01-02 19:17:52 (с) Якушенко Николай Викторович
Спасибо за чтение
Вернуться к книге
