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

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

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

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

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

Пассивное обучение и активное обучение

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

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

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

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

Если вы отличный ученик, то после урока вы разбиваете эти заметки на полезные части и просматриваете их.

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

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

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

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

Чтобы учиться, вы должны подать заявку

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

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

Вот здесь и появляются ваши побочные проекты.

Вы должны где-нибудь начать

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

Лучшее время для этого - во время ваших собственных проектов.

Работа над побочными проектами - это то же самое, что Стивен Карри отрабатывает три простых указателя. Мы все видели, как он с высокой точностью стрелял тройками больше, чем в НБА, находясь под прикрытием. Чего мы не заметили, так это того, когда он изо всех сил пытался забить три указателя даже в средней школе или колледже. Или когда он впервые перешел от стрельбы троек средней школы к тройкам длиной в НБА, и его процент стрельбы упал. Или когда он пропустил прыжок в короткую длину, который позволил бы его команде средней школы победить (все истории, которые я полностью выдумал о Стивене Карри, но дело в том, что он, должно быть, тренировался, прежде чем стал суперзвездой, а он, должно быть, потерпел неудачу).

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

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

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

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

Если вам все равно придется писать какой-то «неоптимальный» код, вы можете сделать это, не выходя из собственного репозитория git, а не в профессиональных системах на работе.

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