Эти советы перенесут вас на несколько недель вперед

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

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

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

Вот 10 вещей из моего опыта, которые вам нужно знать:

1. Научитесь правильно обращаться за помощью

Поверьте, есть правильный и неправильный способ сделать это.

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

Так как же правильно обратиться к ним за помощью?

Начнем с неправильного пути.

Это неправильный способ сказать: «Привет, Джим, у меня проблема, и я не могу понять, что делать. Вы можете мне помочь?"

В чем проблема?

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

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

«Привет, Джим, у меня есть эта задача, и я, кажется, наткнулся на контрольно-пропускной пункт. Вот что я пробовал: X, Y, Z. Есть какие-нибудь мысли? "

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

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

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

2. Кодирование - лишь часть вашей работы

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

Но этого никогда не происходит. (На самом деле, я не думаю, что кто-то сможет это выдержать!)

Ваш опыт необходим и в других областях.

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

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

3. Не пытайтесь быть героем в первую неделю или месяц.

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

Не надо.

Не бросайтесь туда и не начинайте волонтерство для больших и важных дел.

Когда кто-то говорит: «Привет, команда, нам нужен кто-то, чтобы перенести все эти данные в эту другую среду, а также в такую-то», и это ваш первый день, не поднимайте руку. Устройтесь поудобнее и позвольте кому-то другому сделать это.

Твое время придет. Скоро ты сможешь доказать свою ценность. Но не сейчас.

С самого начала воздержитесь от попыток быть героем и потенциально напортачить.

Это сделал парень на моей работе. На третий день он случайно удалил всю группу ресурсов и ее содержимое в Azure.

С тех пор у него было забавное прозвище.

Смири себя.

4. Будьте уверены, что вам удобно использовать Git.

Почти все компании-разработчики программного обеспечения используют контроль версий, и чаще всего git.

Я гарантирую, что с самого начала будет считаться, что вы это знаете.

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

Что ж, с git этого не произойдет. Скорее всего, предполагается, что вы это знаете. (А если нет, то вы можете поразить их своими дополнительными способностями.)

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

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

С фрилансом у вас часто меньше бюджетов. Благодаря меньшему бюджету вы, естественно, чувствуете, что вам нужно работать быстрее. Вы чувствуете, как не хватает времени. (Я имею в виду, кто хочет работать бесплатно?)

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

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

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

Возьмите за привычку уделять себе больше расчетного времени, чем вы действительно думаете. Дайте себе подкладку. Если вы чувствуете, что к концу дня все готово, скажите им, что к концу недели все будет готово. А когда все будет готово раньше, мы все празднуем!

6. Заранее ознакомьтесь с методологией Agile / Scrum.

Scrum - это гибкий процесс для управления сложными задачами.

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

Вы, наверное, уже слышали об этом или, по крайней мере, о его терминологии: ежедневные стендапы, циклы спринтов, сеансы груминга, ретроспективы, PBI и т. Д.

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

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

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

7. Если кто-то еще знает, как сделать что-то лучше вас, это не значит, что вы должны пойти и спросить их, как это сделать.

Это похоже на # 2 выше.

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

Итак, представьте, что вам поставили задачу. Другой разработчик в компании действительно создал эту функцию, но теперь вас просят ее как-то изменить.

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

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

Возьмите на себя усилие. Рывок вперед. Добавьте новый навык в свой репертуар.

8. Всегда заранее задавайте вопросы о новых функциях или задачах

Я борюсь с этим.

Допустим, я на встрече, и кто-то говорит: «Привет, Трэвис, клиенту нужно внести это изменение в панель навигации его сайта. Он должен выглядеть таким-то и таким-то. Ты можешь сделать это?"

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

Это огромная проблема.

Хороший разработчик задает такие вопросы:

«Хорошо, зачем им эта функция?»
«Как они думают, что эта функция принесет пользу их бизнесу или сайту?»

Или, если это не очень хорошая идея, они могут сказать:

«Вы знаете, я думаю, что это запутает кнопку CTA. Возможно, его лучше разместить здесь.

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

Это восходит к пункту 1 выше, где кодирование - только часть работы.

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

9. Не отправляйте электронные письма и сообщения Slack в нерабочее время.

У людей есть Slack на телефонах и, скорее всего, будут включены уведомления.

Если у вас есть интересная идея, а сейчас 21:00, не рассылайте ее и не отвлекайте коллег, когда они читают детям, чтобы они уснули. Подождите до утра.

Люди живут вне работы.

Я знаю, что это не совсем популярное правило, и многим это наплевать, но я бы посоветовал вам поддерживать рассылку уведомлений Teams или Slack только в рабочее время. Люди это оценят.

10. Будьте подотчетны

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

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

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

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

Заключение

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

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