Полезные привычки для разработчика-джуниора. Часть 2

Перевод второй части статьи «9 Habits I Wish I Had as a Junior Developer». В первой части мы говорили о пользе парного программирования, выходе за рамки привычного, хорошей коммуникации с членами команды и ведении блога. В этой части разберем еще несколько полезных привычек.

Заведите себе записную книжку и систему записей

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

Я делаю записи, когда слушаю чьи-то выступления, когда жду автобус или обдумываю меню на неделю.

Также я веду списки книг, которые хочу прочесть, фреймворков, которые хочу опробовать, функционала, который хочу добавить в свои личные проекты. И, что более важно, я делаю пометки при чтении книг, потому что это помогает усваивать материал.

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

Дело в том, что я не доверяю своей памяти. Если у вас хорошая память и вы отлично помните все, о чем думали неделю назад, вам, пожалуй, блокнот не нужен. А ваша память такая же дырявая, как у меня, ведение записей в блокноте существенно меняет жизнь к лучшему.

Чтобы блокнот приносил максимум пользы, вам нужен системный подход. Вы должны убедить свой мозг, что все, что вы записываете в блокнот, не потеряется.

Отведите первые пару листов блокнота под содержание, чтобы позже можно было легко находить нужную информацию. Кроме того заведите привычку регулярно пересматривать свои записи и обрабатывать их.

Возьмем к примеру записи, сделанные при чтении книги. Когда я дочитал книгу, я просматриваю свои пометки и пишу обзор книги в своем блоге. Эти ревью практически никто не читает, но сам процесс написания ревью заставляет обдумать прочитанное и в результате лучше запомнить.

Записывайте свои победы

Записные книжки пригодятся и при выработке следующей привычки: документирования достижений.

Как я уже говорил, память у меня дырявая. Обычно я могу вспомнить, что ел вчера за обедом, но когда я сосредоточен на какой-то сложной задаче, мощность моей памяти заметно снижается.

Вот поэтому я предпочитаю записывать свои достижения в конце дня. Обычно это не какие-то выдающиеся дела, а просто маленькие победы. Например, баг, с которым удалось справиться, еще один шаг на пути к созданию новой фичи для программы и т. п. Я также записываю личные победы, вроде выполненной утренней зарядки.

Я просто составляю по вечерам список сделанного за день и записываю его в блокнот. Вы можете вносить подобные записи в табличку или пользоваться какой-то специальной программой, если вам так удобнее.

Со временем достижения накапливаются. Можно даже как-то отмечать самые важные, чтобы потом с легкостью их находить.

При случае, например в преддверии performance review, вы просматриваете свой список, находите соответствующие достижения и выносите в отдельный списочек. Ревью производительности всегда проходят гораздо лучше, если к ним подготовиться.

Также список достижений полезен, когда нужно рассказать, что вы делали.

Photo by Clément H on Unsplash

Резервируйте время для важных задач

В конце дня у меня часто возникает ощущение, что я так ничего и не сделал. И хотя документирование своих побед (или хотя бы завершенных задач) это важно, главное все же — завершать эти задачи.

Бывает, один митинг сменяется другим и внезапно наступает конец рабочего дня. После митинга вы хотели бы продолжить работу над своей задачей, но только вы успеваете разогреться, как уже начинается следующий митинг. И после этого митинга вам нужно начинать «разогреваться» заново, потому что вы уже потеряли контекст.

Переключение контекста убивает продуктивность.

Если я чему-то и научился в деле повышения продуктивности, так это тому, что обязательно нужно резервировать время для задач, которые должны быть выполнены. Если у вас не отведено времени для какой-то важной задачи, весьма вероятно, что вы так и не приступите к работе над ней. Ваше время будет съедено обычными повседневными делами или другой (запланированной) работой.

Управлять своим временем можно по разным методикам и, честно говоря, я перескакиваю с одного подхода к другому каждую пару месяцев. Но суть остается неизменной: для задач, которые вам нужно обязательно выполнить, нужно резервировать кусок времени в расписании.

Я отвожу один час утром, перед работой, на написание статей для моего блога (или для других сайтов). Чаще всего я также резервирую один час вечером (в то время, когда дети уже спят) для работы над личным проектом.

Сейчас у меня есть доска Trello с колонкой для каждого дня недели, куда я вношу задачи, которыми хочу заняться утром и вечером. Раз в неделю я обновляю эту доску и вношу туда записи на следующую неделю. Таким образом мне не приходится тратить драгоценное зарезервированное время на обдумывание того, чем заняться дальше.

У меня также есть аналогичная доска Trello для моей работы как разработчика. Каждое утро я продумываю, чем хочу заняться в течение дня, и заполняю соответствующую колонку этими задачами.

Кроме того, я ежедневно блокирую в своем расписании два часа для работы, требующей особой концентрации, чтобы коллеги не пытались назначать на это время какие-то митинги. Все это помогает мне справляться с задачами, запланированными на день.

В общем, не столь важно, как именно вы осуществляете менеджмент своего времени. Главное — в принципе делать это и перевести это в привычку. В противном случае ваши дни будут съедаться вещами, которые не слишком важны для вас.

Если дело застопорилось, сделайте перерыв

Разработчики программ в своей работе часто заходят в тупик. Ситуации, когда просто не видишь выхода, ужасно раздражают.

В таких случаях часто советуют сделать перерыв в работе, но это легче сказать, чем сделать. «Решение уже близко, я не могу прерваться сейчас!»

К тому же, если я сделаю перерыв сейчас, то после него мне снова придется «вклиниваться» в контекст. Зачем же добровольно переключать контекст, если такое переключение это основная причина потерь времени?

Дело в том, что когда работа застопорилась, вы не мыслите здраво. Вы думаете о том, что это очень тупо — застрять над такой проблемой, а вот ваши товарищи, наверное, легко бы все решили (как вариант — им всегда достаются задачи полегче). Но вы не думаете о том, как, собственно, решить проблему.

Сделайте перерыв и поработайте некоторое время над чем-то другим. Или — и это даже лучше — вернитесь к этой задаче на следующий день. Некоторое дистанцирование от проблемы позволит вам увидеть решения, которые раньше ускользали из вашего поля зрения.

Может, у вас еще такого не случалось, но я вас уверяю: очень, просто очень часто решение приходит в голову само на следующее утро. И главным образом потому, что вы видите путь, которого не видели раньше.

Переходим к следующему вопросу. Легко сказать «сделайте перерыв». А как понять, что вы уже перешли в «режим ступора», и как убедить себя на некоторое время бросить решать эту задачу?

Честно говоря, тут я сам не мастер, потому что обычно мне УЖАСНО ХОЧЕТСЯ РАСПРАВИТЬСЯ С ЭТОЙ ЧЕРТОВОЙ ЗАДАЧЕЙ, чтобы, наконец, показать какой-то результат!

Но мне помогает разделение дня на 30-минутные отрезки с недолгим отдыхом после каждого. Это называется приемом Pomodoro (название произошло от использования кухонного таймера в форме помидора).

После каждого «помидора» я спрашиваю себя, работаю ли я в режиме поиска решения, или же я застрял и мне следует заняться чем-то другим.

Прием помидора имеет дополнительный плюс: конец каждого юнита можно использовать в качестве триггера для других привычек.

Например, для привычки встать из-за стола и размяться, выпить воды. Это порой называется стеком привычек, потому что вы как бы накладываете одну на другую, и в результате получаете хороший эффект.

Не ищите волшебную палочку

Я написал книгу об одном архитектурном стиле и регулярно получаю письма с вопросами типа «Мне очень нравится этот архитектурный стиль и я хочу применить его во всех моих проектах! Как это сделать?»

И знаете, что я отвечаю?

Не существует никакого архитектурного стиля, который подходил бы для решения всех проблем.

Когда у вас маленький проект, вы строите простой CRUD API. А если у вас сложная модель, вы строите более замысловатую шестиугольную архитектуру. А при создании микросервисов в каждом отдельном контексте вы используете еще какой-то из сотни архитектурных стилей.

Аналогично, нет никакого фреймворка, который можно было бы использовать для абсолютно любого проекта. Так же, как нет универсального языка программирования или единого стиля кодинга.

Не пытайтесь найти универсальный рецепт. Таковых не существует.

Наличие своего мнения — хорошее дело, когда за мнением стоят достойные аргументы. «Это самый лучший архитектурный стиль» и «Я всегда так делаю» не относятся к достойным аргументам.

Только представьте, что в вашей команде есть разработчик, имеющий собственные предпочтения буквально во всем и с пеной у рта настаивающий на своем выборе, «потому что так лучше всего». Вы устанете от него очень быстро. Не будьте таким разработчиком.

Вырабатывайте эти привычки!

Ох, статья получилась гораздо длиннее, чем я рассчитывал. Надеюсь, советы из нее помогут вам в вашей карьере. Выберите пункт, который больше всего вас касается, и попытайтесь последовательно и настойчиво внедрить этот совет в свою повседневную жизнь.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх