Можно ли тратить время на обучение на работе?

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

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

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

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

Короче говоря, это означает, что часть моей работы состоит в том, чтобы делать именно то, что вы описываете.

Допустимо ли вообще во время проекта тратить время на то, чтобы научиться выполнять поставленные задачи более эффективно?

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

Сюда входит изучение и опробование новых инструментов (библиотек, IDE и других инструментов).

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

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

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

Мое эмпирическое правило состоит в том, чтобы тратить 30% своего времени плюс-минус на изучение новых и лучших способов делать что-то (или углублять свое понимание того, что мы уже делаем). Я смотрю на это так: если я трачу десять минут на изучение техники, которая экономит десять минут, то, если я сделаю это один раз, я заплатил за время. Если я потрачу 2 часа на то, чтобы выучить что-то, что сэкономит 10 минут, мне придется сделать это 12 раз, чтобы за это заплатить. Но если это то, что я делаю часто, это действительно может стоить того.

Поначалу 30%, вероятно, будут нереальным количеством времени, которое вы можете посвятить этому. Но со временем время, которое вы вложили в то, чтобы стать более эффективным и лучшим в своей работе, начинает накапливаться до такой степени, что вы можете решить для себя, каков правильный баланс между выполнением работы и обучением, чтобы быть лучше в работе.

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

Допустимо ли вообще во время проекта тратить время на то, чтобы научиться выполнять поставленные задачи более эффективно?

Это, определенно это. Точно так же, когда вы решаете ошибку, вы решаете КОРЕНЬ, а не симптом. Приступая к задаче, выделите время, чтобы найти подходящие инструменты для работы и ознакомиться с API. Это почти всегда сэкономит вам время в долгосрочной перспективе.

Даже если это означает риск (например, попробовать сторонний фреймворк, который может использоваться или не использоваться... в зависимости от того, насколько хорошо он работает)?

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

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

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

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

Окончательное решение будет принимать ваш босс, поэтому я бы позаботился о том, чтобы вы выполнили две вещи:

1. Закончите дела, которые ваш босс хочет, чтобы вы сделали вовремя.
2. Если ваш босс позволяет или ожидает от вас улучшения ваших навыков (надеюсь, он не хочет, чтобы вы всю жизнь были младшим разработчиком), убедитесь, что вы изучаете то, что он считает важным. Могут быть планы по работе с другим стеком технологий. Те, кто опытен, могут пострадать в этой фирме.

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

Лидеры нефункциональных команд редко получают повышение в качественных компаниях. Если он/она не может получить повышение, вы не можете получить повышение.