Правильный разработчик

Илья Лебедев на своем сайте поделился своим представлением идеального разработчика. С его разрешения публикуем эту статью.

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

Итак.

Правильный разработчик понимает, зачем он нужен

Тут ничего сложного: разработчик нужен, чтобы решать проблемы бизнеса. Не поддерживать продукт, не добавлять функциональность, не оптимизировать или стабилизировать, не поддерживать качество и не консультировать.

На главной нужен баннер с новой услугой? Наблюдать за конкурентами? Снизить затраты на облако? Перенести диван? Проконсультировать клиента? Разработчик сделает. Подобные просьбы вызваны проблемами. Проблемы у бизнеса. Бизнес — король. Если он просит разработчика — разработчик делает. Разбирается в сложной админке, парсит нужные страницы, переезжает на другой хостинг, помогает с перестановкой.

В этом разница между разработчиком и правильным разработчиком — второй понимает, что он отвечает не за код, а за продукт.

Правильный разработчик проявляет инициативу

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

На главной поползла вёрстка? Контакты устарели? Медленно работает? Неочевидное поведение? Риск для данных пользователя? Команда не успевает в срок? Разработчик обратит на это внимание. Не потому что он злорадный выскочка, а потому что ему не всё равно.

То же касается и проблем, которые сам разработчик и создаёт. Он громко объявит о своей ошибке, починит, а потом — расскажет, почему такое произошло и сделает так, чтобы оно не повторялось.

Правильный разработчик умеет писать код

Не в смысле юнит-тестов, комментариев, принципа единственной обязанности и DRY, это умеет и обычный разработчик.

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

Поэтому правильный разработчик так ценен — он постоянно воюет с подобными проблемами. В результате получается [замечательный] продукт.

Правильный разработчик умеет общаться

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

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

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

Поэтому такой разработчик умеет общаться — он способен получить ответ, продать решение и объяснить проблему. Он понятно расскажет, подробно распросит, а вероятность непонимания сведёт к нулю.

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