Как перестать думать как младший дев

Когда ты младший dev все дело в технологиях. Какие фреймворки вы знаете, сколько языков вы можете использовать, сколько анимаций вы можете разместить на своем сайте-портфолио и так далее. Но по мере того, как вы продвигаетесь в своей карьере программиста, все начинает меняться. Все становится меньше о технологиях и больше о ваших отделочных проектах. Ваша способность работать с заинтересованными сторонами и командой разработчиков станет одним из ваших самых ценных навыков. Ниже приведены несколько советов, которые мне помогли в моей, хотя и ограниченной, карьере.

Сосредоточьтесь на проблеме, а не на решении

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

Оказалось, что загрузка недавно начала сбоить. Мы спросили, сколько типов файлов не работает. Только один. Мы спросили, случалось ли такое раньше. Они сказали нет, это началось только на прошлой неделе. Это было в тот момент, когда мы сказали: «Итак, если мы просто исправим ошибку с этим одним типом файлов, вам понадобится вся панель инструментов?» На что они ответили: «Не совсем». Задав вопрос, в чем на самом деле была проблема, мы смогли найти правильное решение, а не просто любое решение. Проект, на который могли уйти недели, внезапно исчез, уступив место другой работе.

Распараллеливание сложно

О менеджерах говорят: Менеджеры - это люди, которые думают, что можно ускорить концерт, добавив больше скрипок. Дело в том, что иногда задачи просто невозможно решить быстрее, добавляя больше людей, но это не мешает руководству пытаться. Такой перекресток возникает, когда на доске Jira начинает скапливаться количество билетов. Тот факт, что в команде 3 человека и 9 билетов, не означает, что у вас может быть 3 человека, каждый из которых начнет работать немедленно. Вам необходимо работать с командой разработчиков, чтобы убедиться, что ваш проект специально организован для параллельной работы. Параллельная работа может быть сложной для настройки, но когда все сделано правильно, это того стоит.

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

Не считается, если он не развернут

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

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

Спросите о приоритетах

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

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

Время король

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

Хорошая стратегия для этого - не тратить свое время. Когда вы берете билет, разбейте его на части, желательно как можно больше мелких частей. Завершите каждую часть до уровня «это имеет смысл» и двигайтесь дальше. Не тратьте время на доведение до совершенства, пока вся работа не будет сделана. И не собирайте вещи просто так, у вас может не хватить времени, чтобы вернуться и почистить это. Этот способ обычно самый быстрый в большинстве случаев. Это позволит избежать дорогостоящих переделок, но также не позволит вам застрять в попытках достичь совершенства.

Настоящая работа - это не кодирование, а решение проблем.

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

счастливого кодирования всех,

Майк