Сегодня обсуждаем вещи, которые должен знать и уметь каждый разработчик.
- Базовые технические знания
Вы ожидали, что я начну с чего-то другого? Нет. Каждому программисту надо иметь базовые технические знания в своей профессии, а желательно — еще и в смежных. Потому что это необходимо, без этого вы вообще не разработчик.
- Способность и желание быстро учиться
Сейчас без этого никуда, не только в разработке. Все слишком быстро меняется. Даже если вы работаете в какой-то консервативной области типа Java или SAP, там тоже происходит много интересного. На каждом новом проекте вы обнаружите массу вещей, которых вы не знали и которые надо доучивать. Это часть нашей профессии. Мы доучиваем.
Это тоже базовый технический навык. Умение найти баг, место, где в коде накосячили, где программа сбоит и почему.
Программисты получают такую зарплату во многом потому, что они не говорят: «Я не знаю, как это исправить. Это нерешаемо». Хороший программист говорит: «Да, я буду работать и придумаю, как это решить».
Иногда заказчик отказывается от отладки кода, это слишком долго и дорого. Но это уже не ваша ответственность. А в большинстве случаев заказчику выгодно, чтобы хоть год исправляли баг в программе, но исправили. Умение упереться рогом, долбиться в одну точку, чтобы исправить код – необходимо. Сюда же умение пользоваться инструментарием, который поддерживает трассировку и дебаггинг. Это можно и не упоминать, но новичкам это полезно помнить.
- Умение правильно строить work-life balance
Для хорошей работы надо научиться расслабляться. Многие говорят: «Надо быть готовым к переработкам». Но к переработкам готов любой человек. Если вы пошли в программирование по любви, вас придется за уши оттаскивать от консоли и просить сделать паузу.
На карьерных консультациях я часто встречаюсь с людьми, у которых работа — это работа, и хобби – это работа, и отдых — это тоже работа, в результате чего они жестко выгорели. Так быть не должно. Нужен источник получения радости, чтобы получать радость не только от работы.
Если у вас не так, вы на первом этапе выгорания. Не подходите к нему, а уже на первом этапе. Вы непременно выгорите, если ваш единственный источник радости — это работа. Надо иметь хобби и увлечения, чем вы занимаетесь постоянно и что приносит вам радость, чтобы вы могли переключаться с работы. В идеале это должна быть деятельность, не связанная с компьютером. Если для вас отдых — это переключиться в соседнее окно, это не дело.
Поищите другое занятие. Попробуйте любой спорт, моделирование, походы… Для программиста очень полезно иметь хобби, связанное с физической нагрузкой, потому что работа физической нагрузки не дает. А человеческому телу она необходима. Хотя бы фитнес-тренировки, какой-то спорт. Кстати, подойдет игра на музыкальных инструментах.
Что происходит в проекте, с которым вы работаете. Я называю это умение business value, хотя правильнее было бы его назвать big picture – понимание того, что происходит. Это важно, чтобы не начать заниматься фигней. Чтобы, когда вы что-то пишете, вы понимали, для чего вы это пишете, какую роль этот код исполняет в общем проекте.
Часто оказывается: то, чем заморачивается программист, для проекта не надо. Важнее простая и примитивная вещь, которой никто не занимается, но которая критично необходима для проекта. При этом все заняты какой-то сложной заморочкой, которая для успеха проекта не играет роли.
Для программиста умение видеть всю картину очень важно. У многих ПМ-ов нет технического образования, и они не могут понять, насколько нужно то, что вы делаете. А тимлид может просто за вами не уследить, особенно если вы сам тимлид. Вы можете направить своих разработчиков на задачу, которая интересна, вместо той, которая нужна для проекта. Не надо так.
- Взять максимум от минимума
Довольно часто в разработке случается ситуация, когда вы работали-работали, и вдруг поняли, что пошли не туда. Нужно набраться смелости и удалить результат нескольких дней вашей работы, чтобы пойти правильным путем. Это часто очень больно, вы думаете о том, сколько же времени было потрачено, но так работать не будет.
Профессионализм состоит в том, чтобы сказать – окей, удаляем, это не работает. Откатились к предыдущей версии и забыли. Это больно, это плохо, но вкладывать кучу времени и сил в неработающее решение еще хуже.
Оставлять закомментированным нерабочий код, который захламляет проект – тоже не вариант. Проще признать, что не получилось, зафиксировать убытки и пойти другой дорогой. Но к этому нужно себя готовить.
Многие программисты с трудом признают, что пошли не туда. Хотя с другой стороны, столько же программистов бросают работу при первой же сложности, и мечутся между ста пятьюдесятью вариантами решения. Это другая сторона той же проблемы, но не менее идиотская. Накидано несколько решений, но они не продвинуты, и непонятно, которое из них работает. Надо пройти по каждому из них, проверить и убедиться – нет, это не работает. Лошадь сдохла, значит, слезь с нее. Но и бросать решение при первой же сложности тоже не вариант. Не надо так.
- Способность работать в команде
Прошло то время, когда можно было сидеть в гараже, что-то делать самому и быть гиперспециалистом, нужным всему миру. Если вас зовут не Линус Торвальдс, хрена вам лысого. В любом случае вы должны работать в команде. Даже если вы мобильный разработчик, у вас есть команда из дизайнера, тестировщика, может быть, ПМ-а – короче, есть люди, с которыми вы работаете.
От вашего умения работать с людьми, правильно построить коммуникацию, донести свою мысль, декомпозировать задачу зависит много больше, чем от умения быстро печатать. От этого, кстати, вообще ничего не зависит. Вы можете декомпозировать не ту задачу. Или объяснить задачу не так. ПМ вас не поймет, неверно перескажет проблему заказчику, обратный ответ тоже будет неправильным, и проект просто развалится из-за неправильной коммуникации. Прокачивайте софт скиллы это тоже важно.
Всегда ваш Сергей Немчинский.
