Кофе-брейк #48. 9 полезных привычек для junior-разработчика

Источник: Free Code Camp Вы когда-нибудь анализировали свои привычки? Хорошие помогают стать тем, кем вы хотите быть. Вредные привычки постепенно превратят вас в того, кем бы вы не хотели становиться. Проработав более 12 лет разработчиком программного обеспечения, у меня выработались определенные привычки, которыми я горжусь, а от некоторых я бы предпочел избавиться. Поначалу я не осознавал их значение, но потом мне стало ясно, какие из этих привычек мне помогали расти, а какие мешали. Это побудило меня провести инвентаризацию и написать о том, что, возможно, вдохновит вас сделать то же самое.

Добровольно беритесь за вещи, в которых не разбираетесь

В начале своей карьеры вы знаете не так уж много. Поэтому вы наверняка будете чувствовать себя самозванцем. Ведь компания платит вам зарплату, как специалисту, а вы даже не знаете половины названий тех технологий и фреймворков, с которыми работают ваши коллеги. А про вторую половину вы слышали только потому, что вовремя поискали в Google. Если заменить слова «в начале карьеры» на «в начале любого нового проекта», то можно получить довольно точное представление о карьере в сфере разработки софта. Каждый новый проект — это начало чего-то нового. Мы знакомимся с новыми людьми, разбираемся в новых требованиях, изучаем новые фреймворки. И так каждый раз. Вот почему так важно постоянно учиться новому. Если вы все время делаете лишь то, в чем хорошо разбираетесь, вы не сможете уверенно браться за новый проект. Перед вами всегда будет появляться страх перед неизвестностью. Взяв за правило самостоятельно браться за задачи, о которых вам ничего неизвестно, вы сможете получать новые навыки и знания. Если нужно исправить что-то в сборке, а вы никогда раньше с подобной работой не сталкивались, — беритесь за эту задачу! Вы получите необходимый опыт и новые навыки. Если во фронтэнд-коде JavaScript обнаружена ошибка, а вы пока работали только с бэкэндом Java, исправьте ее! Делать то, в чем вы не уверены, — отличный способ профессионального роста. Но не обманывайте ожидания окружающих. Не выставляйте себя асом во всем. Честно скажите, что вы не делали этого раньше, но хотели бы научиться.

Проситесь поработать с кем-нибудь в паре

Если вы на чем-то застряли или вообще не знаете, как выполнить поставленную перед вами задачу, попросите кого-то более опытного поработать с вами в паре. Парное программирование — это отличный способ сдвинуть работу с мертвой точки. Обсудите со своим коллегой требования: так вам будет легче разобраться, каков должен быть результат. Затем приступайте к обсуждению вариантов решения. Можно пойти еще дальше и предложить поработать в паре, чтобы вы писали код, а коллега вам подсказывал, и наоборот. Так вы научитесь как следует подходить к обдумыванию и решению задач. Новичку парное программирование приносит большую пользу. Примечание по поводу работы из дома. Когда нас перевели на удаленный формат работы, я столкнулся с совершенно новыми для меня проблемами. Я начал сомневаться, стоит ли просить коллег поработать со мной в паре. В офисе всё было просто: можно просто подойти к соседнему столу и обсудить этот вопрос. При удаленной работе и общении через видеоконференции все заметно усложнилось. Если для вас это тоже проблема, поговорите об этом с коллегами. Вам нужно лишь немного изменить привычные подходы и выработать новые привычки.

Сообщайте о том, что делаете (и чего не делаете)

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

• руководство требует побыстрее закончить новую фичу, потому что дедлайн близок;
• хочется хорошо выглядеть на фоне коллег по офису;
• многие вещи просто не работают так, как ожидалось;
• и многое, многое другое…

В общем, довольно вероятно, что ваша оценка времени также будет излишне оптимистичной. Как же это исправить? Вы можете управлять ожиданиями уже в процессе работы! Постоянно рассказывайте о том, чем вы занимаетесь, и всегда сообщайте, что именно вас задерживает. Я не имею в виду, что нужно выдавать апдейт статуса задачи каждые 15 минут. Просто следите за тем, чтобы люди, которых это касается, знали, на каком этапе работы вы находитесь. Лучше всего об этом сообщать в начале и конце рабочего дня. Если ваш руководитель или менеджер команды/проекта ожидает от вас результатов, докладывайте ему ежедневно: «Я работаю над тем-то и тем-то. Столкнулся с такой-то проблемой. Вот варианты ее решения». Так все заинтересованные лица будут знать о вашем прогрессе. Никто не станет вас винить, если вы вдруг столкнетесь с проблемой, — но только если вы при этом будете держать людей в курсе событий. Дополнительный плюс: сообщая о текущем статусе выполнения задачи, вы сможете услышать от других рекомендации или варианты решения проблемы. Возьмите за привычку регулярно сообщать заинтересованным лицам о результатах вашей работы.

Заведите блог

Наверное, я не первый, от кого вы услышали этот совет, но я все равно скажу: ведите блог! Совсем не обязательно, чтобы ваш блог был публичным. Это может быть пара страниц на wiki вашей компании или коллекция GitHub-репозиториев с примерами кода и несколькими строчками поясняющего текста. Зачем это нужно? Потому что когда вы пишете что-то для того, чтобы научить других (даже если эти «другие» — это вы сами в будущем), это отличный способ учиться и профессионально расти. Напишите о том, как вы смогли решить какую-то трудную проблему. Или о том, как работает новый фреймворк, выход которого вы давно ожидали. Можно также вести дневник того, что вы сделали на неделе. Это, кстати, поможет выработать привычку сообщать о том, над чем вы сейчас работаете. Я несколько раз начинал вести блог. Поначалу, конечно, очень трудно поддерживать мотивацию и заставлять себя писать, понимая, что вряд ли кто-либо читает ваши посты. Довольно странно писать в пустоту. По этой причине я и забрасывал свои блоги. И вот три года назад я завел очередной, свой нынешний блог. Я писал без какой-либо аудитории в течение полугода. И потом я обнаружил, что читателей у меня не было потому, что мой файл robots.txt не разрешал поисковикам индексировать блог! Короче, я изменил настройки в robots.txt, и люди начали читать мои статьи. Читателей было не много, но все равно они давали мне стимул не останавливаться. Постепенно я улучшил свои навыки письма, и теперь мой блог имеет до 200 тысяч просмотров в месяц. И все это из-за того, что я когда-то решил начать писать о новых фреймворках и проблемах, которые мне удалось решить. А делал я это для того, чтобы иметь возможность вернуться к своим записям, когда они мне понадобятся, а вовсе не потому, что хотел собрать большую аудиторию. Поначалу ведение блога покажется скучной рутиной, но со временем, если вы не остановитесь, это занятие начнет приносить вам удовлетворение. Если вы начнете писать с желанием учиться и учить, вы не только многое освоите, но и станете интересным для многих людей.

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

Я только недавно стал большим поклонником блокнотов. Не в виде программ, а настоящих, бумажных. Куда бы я ни пошел, я беру с собой блокнот и ручку. Так у меня есть возможность в любой момент записать то, что пришло мне в голову. Я делаю записи, когда слушаю чьи-то доклады, когда жду автобус или обдумываю, что приготовить на ужин. Также я использую блокнот для создания списка книг, которые хочу прочесть, фреймворков, которые хочу изучить, функций, которые хочу добавить в свои личные проекты. И, что более важно, я делаю пометки при чтении книг, потому что это помогает лучше сохранить полученные знания. Я записываю все, что приходит в голову. И если мне не удается по какой-либо причине что-то записать, я испытываю беспокойство до такой степени, что даже не могу уснуть. Всё дело в том, что я не доверяю своей памяти. Если у вас хорошая память и вы отлично помните все, о чем думали неделю назад, то, наверное, блокнот вам и не понадобится. Но если у вас с запоминанием проблемы, как у меня, тогда ведение записей в блокноте заметно меняет жизнь к лучшему. Чтобы блокнот приносил максимум пользы, вам нужен системный подход. Вы должны убедить себя, что все, что вы записываете в блокнот, не потеряется. Выделите первые пару листов блокнота под оглавление, чтобы позже можно было легко находить нужную информацию. Заведите привычку регулярно пересматривать свои записи. Возьмем, к примеру, записи, сделанные при чтении книги. Когда я дочитываю книгу, я просматриваю свои пометки и пишу рецензию на нее в своем блоге. Хотя этот текст почти никто не читает, сам процесс написания рецензии заставляет обдумать прочитанное и, в результате, лучше запомнить.

Документируйте свои победы

Записные книжки необходимы и при выработке привычки документирования своих достижений. Как я уже говорил, память у меня плохая. Конечно, я могу вспомнить, что ел вчера за обедом, но когда я сосредоточен на какой-то сложной задаче, мощность моей памяти заметно снижается. Вот поэтому у меня есть правило записывать свои достижения в конце каждого дня. Речь не идет о каких-то выдающихся делах, а просто о маленьких победах. Например, исправление бага, еще один шаг на пути к созданию новой функции и т. д. Я также записываю личные победы — например, выполнение утренней тренировки. Я просто составляю по вечерам список сделанного за день и записываю все это в блокнот. Вы можете вносить подобные записи в табличку или пользоваться какой-то специальной программой, если вам так удобнее. Со временем достижений становится больше. Можно даже как-то отмечать самые важные, чтобы потом с легкостью их находить. Например, перед подготовкой к обзору эффективности (performance review), вы просматриваете свой список, находите соответствующие достижения и выносите в отдельный списочек. Так обзор пройдет гораздо лучше. Также список достижений полезен, когда нужно рассказать, что вы делали.

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

В конце дня у меня часто возникает ощущение, что я сегодня ничего и не сделал. И хотя документирование своих побед (или хотя бы завершенных задач) это важно, главное все же — завершать эти задачи. Бывает, одно совещание сменяется другим и внезапно наступает конец рабочего дня. После совещания с коллегами вы хотели бы продолжить работу над своей задачей, но как только вы успеваете разогреться, как уже начинается новая видеоконференция. И после этого вам нужно «разогреваться» заново, потому что вы уже потеряли контекст. Это снижает вашу продуктивность. Если я чему-то и научился в деле повышения продуктивности, так это тому, что обязательно нужно резервировать время для выполнения важных задач. Если вы не возьмете за правило выделять время на важные задачи, очень вероятно, что вы так и не приступите к работе над ней. Ваше время будет съедено обычными повседневными делами. Управлять своим временем можно с помощью разных методов и, честно говоря, я перескакиваю с одного подхода к другому каждую пару месяцев. Но суть остается неизменной: для задач, которые вам нужно обязательно выполнить, нужно резервировать кусок времени в расписании. Я выделяю один час утром, перед работой, на написание статей для блога (или для других сайтов). Также отвожу один час вечером (когда дети уже спят) на работу над личным проектом. Сейчас у меня есть доска Trello с колонкой для каждого дня недели, куда я вношу задачи, которыми хочу заняться утром и вечером. Раз в неделю я обновляю эту доску и пишу туда, что мне нужно выполнить на следующей неделе. Так мне не приходится тратить драгоценное время на обдумывание того, чем заняться дальше. Кроме того, я ежедневно выделяю в своем расписании два часа для работы, требующей особой концентрации, чтобы коллеги не пытались назначать на это время какие-то совещания. Все это помогает мне справляться с задачами, запланированными на день. В общем, не столь важно, как именно вы осуществляете тайм-менеджмент. Главное — в принципе делать это и создать из этого привычку. В противном случае ваши дни будут съедаться вещами, которые не слишком важны для вас.

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

Разработчики очень часто заходят в тупик. И эти ситуации ужасно раздражают. В подобных случаях часто все советуют сделать перерыв в работе. Но иногда очень трудно следовать таким рекомендациям, ведь «решение уже близко, я не могу прерваться сейчас». И если я сделаю перерыв прямо сейчас, то после него мне снова придется «вклиниваться» в суть дела. Зачем же добровольно терять времени? Но дело в том, что когда вы застряли в работе, то это мешает вам мыслить здраво. Вы думаете о том, что это очень глупо — застрять над такой проблемой. Ведь ваши коллеги, наверное, легко бы с этим справились (другой вариант — им всегда достаются задачи полегче). При этом вы не думаете о том, как, вообще-то, решить проблему. Сделайте перерыв и поработайте некоторое время над чем-то другим. Или (что еще лучше) вернитесь к этой проблеме завтра. Некоторое дистанцирование от проблемы позволит вам увидеть решения, которые раньше ускользали из вашего поля зрения. Может, у вас еще такого не случалось, но я вас уверяю: очень часто нужное решение приходит в голову само собой. Если же у вас нет лишнего времени, можно применить метод Pomodoro — разделение задачи на 30-минутные отрезки с небольшим отдыхом между ними. После каждого этапа я спрашиваю себя, работаю ли я в режиме поиска решения, или же я застрял и мне следует заняться чем-то другим. У метода Pomodoro есть дополнительный плюс: конец каждого этапа можно использовать в качестве триггера для других привычек. Например, для формирования привычки встать из-за стола и размяться, выпить воды. Это порой называется стеком привычек, потому что вы как бы накладываете одну на другую, и в результате получаете хороший эффект.

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

Когда-то я написал книгу про определенный стиль в архитектуре программного обеспечения и регулярно получаю электронные письма с вопросами типа «Мне очень нравится этот стиль и я хочу применить его во всех моих проектах! Как это сделать?» И знаете, что я отвечаю? Не существует никакого архитектурного стиля, который подходил бы для решения всех проблем. Когда у вас маленький проект, вы создаете простой CRUD API. А если у вас сложная модель, вы строите более сложную шестиугольную архитектуру. А при создании микросервисов в каждом отдельном контексте вы используете еще какой-то из сотни архитектурных стилей. Нет никакого универсального фреймворка, который можно использовать для любого проекта. Как и нет единого языка программирования или стиля кодинга. Не пытайтесь найти волшебную палочку. Ее не существует. Наличие своего мнения — это хорошо, когда за мнением стоят достойные аргументы. «Это самый лучший архитектурный стиль» и «Я всегда так делаю» не относятся к достойным аргументам. Только представьте, что в вашей команде есть разработчик, у которого всегда есть собственные предпочтения и который с пеной у рта всегда доказывает свою правоту, «потому что так лучше всего». Вы устанете от него очень быстро. Не будьте таким разработчиком.