Один маленький шаг для вас, один большой шаг для вашей ИТ-карьеры

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

Повторить

Движение небольшими управляемыми шагами является краеугольным камнем многих распространенных методологий в нашей отрасли:

• Agile — это итерация изменений в продукте, чтобы выяснить, что нужно клиентам, в то время как

• Минимально жизнеспособный продукт (MVP) — направлен на создание первой версии, которую можно сравнить с рынком, а затем она повторяется оттуда.

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

Во время обучения

Лучшей идеей будет:

• выучить кусок материала, а затем

• используй это.

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

Во время работы над тикетом

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

• рефакторинг кода, над которым вы собираетесь работать

• добавление инфраструктуры кода — вспомогательные методы, обновление типов и т. д.

• внесение изменений в логику приложения

• добавление сквозных тестов для новой функции

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

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

Во время выполнения проектов

Неважно, работаете вы над коммерческими проектами или над открытым исходным кодом — везде вы слышите одну и ту же мантру:

• «Выпускайте раньше, выпускайте чаще».

• «Двигайся быстро и ломай вещи».

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

Избегайте падения в кроличью нору

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

Вы не одиноки

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

Как новичок, у вас есть два возможных режима отказа:

1. слишком быстро обращаюсь за помощью

1. обращаться за помощью слишком поздно

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

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

1. вы переходите от разработчика, который уходит через 2 недели, поэтому приоритет — получить от него как можно больше знаний

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

Научитесь расставаться

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

Всегда ищите обратную связь

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

• автоматические тесты, проходящие локально или на CI

• более опытный коллега или ваш наставник просматривает код

• представление нашего продукта внешнему миру и сбор отзывов

Хотите узнать больше? Ознакомьтесь с другими моими историями о HackerNoon: https://hackernoon.com/u/marcinwosinek