9 привычек, которые я хотел бы иметь в качестве младшего разработчика

 

Хорошие привычки помогают вам стать тем, кем вы хотите быть. Вредные привычки постепенно превратят вас в того, кем вы не хотите быть.

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

Большую часть времени я не осознавал своих привычек, но, оглядываясь назад, мне довольно ясно, какие привычки помогали мне расти, а какие мешали.

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

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

 

Станьте волонтером в делах, которые вы не знаете

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

А вторую половину вы знаете лишь смутно, потому что искали их в Google.

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

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

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

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

Если сборка требует исправления, и вы никогда не работали с системой сборки, приступайте к ней! Вы узнаете об управлении сборкой.

Если во внешнем интерфейсе JavaScript есть ошибка, и вы пока работали только с серверной частью Java, исправьте ее! Вы узнаете новые идиомы Javascript.

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

 

Попросите объединиться

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

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

В каком контексте? К каким кодовым базам нужно прикоснуться? Каковы явные и неявные соглашения в кодовой базе?

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

Таким образом, вы даже узнаете, как ваш партнер думает и решает проблемы. Вы можете получить от этого только прибыль! Даже если это просто новый ярлык IDE, который вы выучили.

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

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

 

Говорите о том, что вы делаете (и чего не делаете)

Я не помню, как часто я с энтузиазмом брался за задачу, думая, что сделаю это в течение дня, но в итоге все еще работаю над ней через неделю.

С опытом становится лучше, но я все равно делаю слишком оптимистичные оценки. Причин для оптимистической оценки слишком много:

необходимость быстро предоставить эту новую функцию, потому что крайний срок приближается,
давление, чтобы хорошо выглядеть среди сверстников,
вещи просто не работают так, как я от них ожидаю (это то, что чаще всего сбивает меня с толку, даже с многолетним опытом),
и многое другое ...
Скорее всего, большинство ваших оценок окажутся слишком оптимистичными. Что вы можете с этим поделать?

Вы можете управлять ожиданиями по пути.

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

Итак, если ваш менеджер / команда / менеджер проекта / менеджер по продукту / заинтересованное лицо ожидает от вас результатов, сообщайте им каждый день быструю информацию: «Это то, что я делал. Это следующий шаг. Это проблема, которую я» м облицовки. Вот варианты ".

Это позволит всем узнать о вашем прогрессе. Никто не будет винить вас, если вы наткнетесь на стену, пока вы держите их в курсе.

Это вызовет дискуссии типа "Почему это заняло так много времени?" вещь из прошлого. В качестве дополнительного преимущества обновление статуса вызовет обсуждения, которые могут помочь в решении проблем.

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

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

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

 

Написать блог

Я, наверное, не первый, кто это слышал, но все же скажу: пишите блог!

Это даже не обязательно должно быть публичным. Это может быть пара страниц вики компании или набор репозиториев GitHub с примерами кода и парой строк пояснительного текста.

Зачем?

Потому что письмо с намерением научить других (даже если это только вы в будущем) - отличный способ учиться и расти.

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

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

Затем я начал свой текущий блог 3 года назад и полгода писал без аудитории. Только тогда я заметил, что мой файл robots.txt не позволяет поисковым системам индексировать мой блог!

Итак, я изменил свой файл robots.txt, и люди начали читать мои материалы. Немного, но это дало мне мотивацию продолжать. Итак, я выжил, попутно улучшил свои писательские навыки и увеличил свой блог до> 200 000 просмотров страниц в месяц.

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

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

 

Вам нужен ноутбук

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

Список ваших достижений также помогает в повседневных ситуациях говорить о том, что вы делаете (см. Привычку «Говорить о том, что вы делаете»).

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

Честно говоря, я сам не очень хорошо в этом разбираюсь, потому что обычно ХОЧУ С ЭТОЙ БЕЗОПАСНОЙ ЗАДАЧИ ЗАДАЧИ, чтобы показать, что я чего-то добился!

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

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

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

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

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

 

Не гонитесь за серебряными пулями

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

Вы можете угадать мой ответ на этот вопрос?

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

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

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

Не поддавайтесь серебряным пулям. Их не существует.

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

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

 

Развивайте эти привычки!

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

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