Перевод статьи Альфонсо Паредеса Сервантеса «The road to senior dev».
Прежде чем основать собственную компанию по разработке программного обеспечения, я сам был разработчиком и обучал молодых инженеров. Меня постоянно спрашивали, что нужно, чтобы стать разработчиком-сеньором. Это не простой вопрос, поскольку в каждой компании свое понимание должности старшего разработчика.
Однако, основываясь на своем опыте работы в разных компаниях (как по размеру, так и по серьезности), могу сказать, что позиция сеньора предполагает не только знание определенной технологии. Среди прочего вы должны уметь принимать верные решения, делать точную оценку, вовремя выдавать результат.
Следующие пункты предназначены для молодых разработчиков, начинающих свою карьеру.
Проект
1. Уметь определять приоритеты и строго их придерживаться
Эту мысль лучше всего объяснить с помощью простой аналогии. Представьте, что вы строите дом, и в вашем списке необходимых работ есть установка туалета и покраска оконных рам.
Конечно, сделать нужно все по списку. Но чтобы в доме можно было жить, туалет обязателен, а оконные рамы – нет. Сделать нужно и то, и другое, но если вы не покрасите рамы, дом будет пригоден для жилья, а если не установите туалет – вряд ли.
Может, это глупый пример, и вы можете возразить, что план проекта и бюджет уже утверждены, но в реальной жизни планы меняются, а бюджеты урезают. Идея в том, чтобы правильно определить самое важное и обеспечить его реализацию.
2. Избегайте предположений и задавайте важные вопросы
Предположения – корень многих проблем. Я хуже всего отношусь именно к ним потому что их можно прекрасно избежать. Вы должны отдавать себе отчет, что вы не знаете что-то наверняка, и задавать важные вопросы, не оставляющие места для двусмысленности.
Например, представьте, что кто-то пригласил вас встретиться в Starbucks в 8 часов. И вы задаете важные вопросы, как то: в каком именно Starbucks, в 8 утра или в 8 вечера. Без этих уточнений вы можете оказаться в неправильном месте в неправильное время, где будете ругать себя за свои предположения.
3. Анализируйте, прежде чем начать писать код
Когда мы молоды, иногда мы страстно желаем доказать свою ценность и начинаем писать код как можно быстрее. Но в итоге будет быстрее, если мы сначала подумаем, как мы собираемся строить эту вещь, нарисуем пару графиков, сделаем беглый набросок. Иногда это помогает составить в голове более понятную картину препятствий, с которыми придется иметь дело, а также вопросов, которые нужно задать. После этого вы можете приступить к программированию и быть в большей безопасности.
4. Принимайте хорошие решения
Звучит глупо, правда? Но это не что-то вроде лозунга не пить за рулем. Я имею в виду профессиональные сценарии. Как начать принимать правильные решения? Во-первых, составьте список всех переменных, на которые может повлиять ваше решение. Например, как оно скажется на легкости реализации, на производительности и т. п. Как только перечислите все эти переменные, сделайте то же самое со своими вариантами. Теперь вы можете проанализировать свои возможности, сравнив их. Таким образом у вас будет более солидное основание для принятия решения.
5. Узнайте своего клиента
Знавал я людей, работающих с базами данных, которые не только не знали, но даже и не интересовались, какие проблемы должно было решать это ПО. Как по мне, это именно то, что мы называем code monkeys; в недалеком будущем этих людей заменят роботы. Когда вам не все равно, это заметно, и люди начинают к вам прислушиваться, спрашивать ваше мнение и ценить его. С этого все и начинается. Шаг за шагом ваша ответственность растет, с ней – ваша значимость и возможности, а вместе с ними – зарплата.
Командная работа
6. Не бойтесь задавать вопросы
Я понимаю, что вы можете опасаться показаться безграмотным перед коллегами и техлидом. Но поверьте мне: хорошие команды любят поставлять ПО вовремя, а задержки (и то, что стало их причиной) – ненавидят. Так что скорее всего их больше огорчит, если вы не спросите что-то и впоследствии проект задержится, чем если вы спросите что-то обычное, но в результате преодолеете препятствие и усвоите урок.
7. Не бойтесь отправлять
Когда вы еще новичок, объявление чего-нибудь сделанным может быть травмирующим опытом. Помните, что нам платят за готовые продукты. Так что, вместо поиска поводов отложить свои задачи, – делайте отправку, разбирайтесь с последствиями, учитесь на своих ошибках и успехах, совершенствуйтесь и повторяйте весь цикл до тех пор, пока не перестанете бояться.
8. Уважайте своих более опытных товарищей по команде
Временами вы можете быть не согласны с решениями, принимаемыми вашим техлидом, и это нормально. Но прежде чем начать злиться из-за того, что он/она неправ(-а), предлагаю поступить следующим образом. Спросите о причинах такого решения, попытайтесь увидеть и понять целую картину: возможно, есть какие-то ограничения, о которых вы не знаете. В любом случае для вас будет полезнее понять процесс принятия решений, чем просто впадать в гнев из-за того, что кто-то не согласился с вами.
9. Балансируйте между слепым повиновением, безрассудным непослушанием и прикрытием своей задницы
Для иллюстрации этого пункта я расскажу одну историю.
Я работал над проектом в качестве бизнес-аналитика и в числе моих обязанностей было написание некоторых хранимых процедур, где применялись правила бизнеса. Тест приемки клиентом должен был проходить в Китае, и наш технический лидер должен был туда лететь.
Примерно за неделю до релиза тестового окружения пользователя технический лидер сказал мне, что бизнес-правило неверное, и рассказал, как исправить это. Сказанное им показалось мне бессмысленным. Чтобы сообщить ему об этом вежливо (он настаивал на изменении хранимой процедуры), я попросил его четко объяснить, что он хочет, чтобы я сделал, по email.
Он так и поступил, а я пометил это сообщение флажком, чтобы легко найти впоследствии. Также я сделал специальный бэкап кода этой хранимой процедуры, чтобы она была готова, если понадобится.
Неделю спустя во время тестов в Китае это самое бизнес-правило не прошло тест. Технический лидер позвонил мне и спросил, почему программа написана именно так и кто просил об этом. Я сказал ему, опять же, со всем уважением, что это был он и я могу перенаправить ему его собственное письмо. Через 30 секунд он спросил, сколько времени займет обратное изменение. Бэкап был у меня под рукой.
Мораль истории в том, что иногда вы правы, а ваш босс ошибается. Я считаю, что в подобных случаях лучше попросить разъяснений по электронной почте или в другом виде, позволяющем отследить предложенное вами решение. Таким образом, если возникнут проблемы, то и вы будете прикрыты, и правильное решение задокументированно. Вам может показаться, что в этом нет необходимости, но иногда боссы бросают подчиненных под автобус, так что я советую проявить осмотрительность.
10. Отвечайте на электронные письма
Пожалуйста, делайте это! Даже если нет особых причин, кроме обычной вежливости. Благодарите. Отправляйте подтверждения. Это производит лучшее впечатление, чем когда адресат просто не отвечает.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]