Можете быстро спроектировать архитектуру проекта и тут же взяться за разработку, но от тестирования продукта клонит в сон? Или наоборот — прёт от рефакторинга, а с представлением пользовательского интерфейса возникают трудности? CEO Corgibytes объясняет это существованием 2-х типов разработчиков. Читайте статью в нашем переводе.

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

Многие программисты любят начинать с чистого листа (создатели), но существуют те, кому нравится делать существующую версию продукта лучше (ремонтники). Кто из них лучше? Оба типа нужны в мире разработки. Важно понимать ценность каждого из них.

Создатели наслаждаются разработкой на начальных этапах

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

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

Ремонтники предпочитают работать над стабильными проектами, которые показывают рост

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

Но есть группа разработчиков, чьи таланты и интересы подходят для таких задач. Они не пугаются слова «рефакторинг». Исправлять ошибки, делать код чистым и ясным — вот от чего их прет. Качества не сильно полезные в начале, но когда проект растет, такие черты характера потребуются любой команде.

Мотивация для создателей и ремонтников

Компания должна иметь в команде и создателей, и ремонтников. Зная, как их мотивировать, можно добиться максимальной производительности.

Дайте создателям поле для экспериментов, но поставьте дедлайн

Ничто их так не бесит, как повторение. Оставьте монотонные задачи другим, а создателям предоставьте поле для экспериментов. Нужен прототип для проверки идеи? Зовите создателя. Они кайфуют, когда нужно что-то запустить быстро. Такие разработчики часто предпочитают жечь на хакатонах, чем сидеть в офисе. Ограничив сроком, вы еще больше мотивируете их на работу. Минуя очередной дедлайн, они преисполняются чувством выполненного долга, поэтому гибкие методологии разработки подходят им идеально. Создатели любят внедрять новые идеи, а улучшать код одного проекта долгое время их напрягает.

Предоставьте ремонтникам несколько небольших задач, которые они решат в течении дня

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

Перевод статьи: https://dev.to/corgibytes/developer-differences-makers-vs-menders

* Обязательные поля
Типы разработчиков: создатели vs ремонтники
Средняя оценка 5 Проголосовало 1