Как стать разработчиком, которого хотят видеть в каждой команде

Помогать новым членам команды

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

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

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

Делиться информацией, которая может принести пользу другим

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

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

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

Предлагать помощь менее опытным разработчикам

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

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

Пробовать новые решения и делиться результатами

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

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

Сдерживать эго

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

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

Сделать свой код легким для понимания

Написание эффективного кода — это здорово. Но иногда самый эффективный код оказывается не самым легким для чтения.

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

Разделять как удачи, так и неудачи

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

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

Мыслить нестандартно

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

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

Передавать нужную информацию перед уходом из компании

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

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

Источник.