Да, мы все были там. Нервничаем по поводу нашей первой работы в качестве разработчика. Думая: «Я даже не знаю, чем на самом деле занимается программист!». Но не волнуйся, я тебя поддержу. Или, может быть, вы старший разработчик и ищете способы помочь новичку в работе набрать скорость? Это тоже для вас.
Приближается лето, а это значит, что многие из вас недавно закончили учебу и скоро начнут работать. И знаешь, что? Это супер весело! Наконец, вы будете кодировать материал исключительно для его использования, а не для оценки!
Вы также начнете работать в командах. С самого начала я работаю в междисциплинарных командах государственного сектора Норвегии и многим обязан своей команде за достигнутый прогресс.
Это три самые важные вещи, которые я узнал, которые помогли мне увеличить скорость производства после того, как я начал работать новичком в технологическом бизнесе.
1) Задавайте вопросы с умом
Одной из первых ссылок, которые я получил от одного из моих коллег-разработчиков, была ссылка Как правильно задавать вопросы. Наверное, потому что я задавал много вопросов. Задавать вопросы - это по сути неплохая вещь, но есть тонкая грань между обменом необходимыми знаниями и использованием слишком большого количества времени других разработчиков.
Руководство довольно обширное. Я настоятельно рекомендую прочитать его, чтобы понять сообщество разработчиков открытого исходного кода и различные типы личностей, с которыми вы можете столкнуться среди программистов.
Однако самый важный совет, который я извлек из этого, заключается в том, что если вы сомневаетесь в том, чтобы задать вопрос, ограничьте его по времени. Потратьте еще 10 минут на поиск ответа самостоятельно. Вы либо закончите:
- Решая проблему самостоятельно, или
- Узнаешь что-то новое и, таким образом, сможешь уточнить свой вопрос.
На более конкретный вопрос легче ответить, он также говорит о том, что вы приложили усилия, чтобы попытаться разобраться в предмете самостоятельно.
2) Не валяйте дурака, используйте документацию
Конечно, Stack Overflow временами спасает жизнь, но давайте будем честными. Как часто вы застряли в джунглях Stack Overflow, пробуя вещи, которые вы действительно не понимаете, но сработали для Мэтта и Криса, а для Эрика не сработали?
Иногда бывает сложно читать документы, но как только вы освоитесь, истина окажется здесь. Читая документацию и ища то, что вам нужно, вы читаете гораздо больше и получаете гораздо более полное представление о языке программирования или фреймворке, который вы пытаетесь изучить.
Внезапно вы оказываете помощь пожилым людям и придираетесь к их коду при проверке кода (шутка, мы этого не делаем, все комментарии при проверке кода конструктивны).
Были даже разработаны инструменты, которые специально вам в этом помогут. Если у вас Mac, вы можете использовать Dash для сбора наборов документации с поддержкой более 200 API: Java, TypeScript, Ruby, вы называете это.
Документы содержат правду. Не тратьте время на то, что потенциально неправильно.
3) Сосредоточьтесь на одной задаче за раз
Затраты на переключение контекста. Чтобы понять проблему, нужно время, чтобы решить ее наилучшим образом. Чтобы избежать этих затрат, сосредоточьтесь на выполнении одной задачи через доску Scrum (или Kanban) за раз.
Кроме того, если задача кажется остановленной, вероятно, где-то есть узкое место в процессе реализации функций вашей командой. Это должно быть исправлено. В противном случае это только замедлит работу команды.
Принятие новой задачи в такой ситуации только увеличило бы объем платы и еще больше увеличило бы нагрузку на узкое место. Под увеличением объема доски я подразумеваю количество задач, выполняемых одновременно, и, следовательно, диапазон функций, над которыми команда работает одновременно.
Тестировщик в вашей команде застрял на задаче. Почему? Попросите ее найти узкое место и выполнить задачу. Возможно, вам нужен новый инструмент или способ генерировать тестовые данные для выполнения поставленной вами задачи - выполнить или выполнить. Может быть, это потому, что критический компонент в тестовой среде не имеет достаточного времени безотказной работы? Поднимите красный флаг и используйте свое время, чтобы исправить это.
Увеличивайте пропускную способность платы, а не ее объем.
Это мой вывод после двух лет обучения младшим инженером-программистом. Желаю удачи, всем новичкам поскорее стать квалифицированными, а всем пожилым - помните, что вы бесценны для нашего развития.
И старшим разработчикам, которым я так много научился за последние пару лет (вы знаете, кто вы) - спасибо.
