Ещё 5 советов сеньорам: чёткость, прошаренность, чуткость, контроль и железный кулак

CBernardes

---

Об авторе

Технический специалист, говорящий простыми словами об облачных и серверных технологиях, бэкенде, фронтенде и тестировании.

---

Источник

10 habits of Senior Software Developers (part 2)

---

Переводчик

Сергей Попов

В прошлой статье мы рассказали, как матёрым разработчикам повышать свою продуктивность и подниматься по карьерной лестнице. В этот раз поговорим о том, как браться за задачи (чтобы потом не было мучительно больно за бесцельно потраченное время), контролировать качество своего кода и общаться с коллегами.

Читайте также:

5 советов сеньорам: автоматизация, отмазки, потери времени, слово пацана и образование

Вникните в проблему, потом решайте задачу

Банально, согласен! Но именно об этом почему-то постоянно забывают. Причин тому — масса, но я бы выделил две: «срок выполнения — вчера» и «чего тут думать — трясти надо».

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

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

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

Вы спросите: при чём здесь разработчик, если задача поставлена неверно? А я считаю, что тот, кто отвечает за решение задачи, обязан удостовериться, что вник в проблему. Если что-то неясно — задавайте уточняющие вопросы. Только так можно:

• предложить более удачное, быстрое и эффективное решение;
• учесть интересы различных пользователей;
• показать руководству, что похожие проблемы уже кем-то решались — только другими способами.

Забудьте, что «здесь всегда так было»

Представьте: устраивается программист Паша на работу. Начальство делает всё, чтобы его предшественник передал ему свой опыт и Павлик вёл проект самостоятельно. Через неделю наставник полностью вводит Павла в курс дела, оставляет ему подробный распорядок дня (включая скрипт, который он вручную набивает ежемесячно) и благополучно увольняется. Теперь Паша за старшего.

Через полгода начальнику внезапно требуется кто-то на подхват, и он спрашивает: «Паш, а ты чем сейчас занят?» — «Ну как чем — скрипт набиваю!» — отвечает тот. «На хрена?» — удивляется начальник. «Так это… всегда так было, — рапортует Павлик. — Каждый месяц, как прописано!»

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

Не сидите в окопе

Может, кому-то кажется, что «отсутствие новостей — лучшая из новостей», но поверьте: ваши коллеги вполне могут за глаза перемывать вам кости за несвоевременное или недобросовестное выполнение задач. Точно так же, сдав очередное задание, вы можете по обыкновению полагать, что всё прекрасно работает, хотя сотрудник, который обнаружил у вас ошибку, будет пребывать в уверенности, что вы о ней знаете.

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

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

Чекните свой код

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

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

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

Такой подход даёт ещё несколько полезных эффектов:

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

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

Отвечайте за всё

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

• Программируйте так, словно за исправление любого косяка будете отвечать только вы, — даже если на самом деле не будете.
• Если ваша задача переходит к другому, убедитесь, что она останется под вашим контролем. Не бросайте её только потому, что её кому-то перепоручили.
• Выполняйте свою работу так, чтобы гордиться результатами.
• Следите за всем, что происходит в ходе работы над задачей или проектом. Кто, кроме вас, сможет понять все принятые решения и внесённые изменения?

Довольно простые советы, не так ли? А теперь давайте посмотрим, что происходит, когда им не следуют:

• Никто не видит, в какой стадии проект, в команде возникают «непонятки».
• Все работают спустя рукава, множатся баги и проблемы с архитектурой, возникают сбои в инфраструктуре.
• Работа стоит, пока вас не пнёт кто-нибудь из соседнего отдела. Возвращаемся к первому пункту и пытаемся понять, где мы находимся.
• Все отвечают за всё, но ничего не делается. Понятно, что в одиночку вы не «вывезете», но если взять процесс под контроль, вы найдёте тех, кто всё исправит.