3 качества сильного программиста

Где-то пол года назад я уже запланировал сделать пост, так как планировал выступить на соревнования по пауэрлифтингу и взять кандидата в масте спорта. Спойлер: Я взял КМС!

Итак какие же это качества:
1. Становая за 200
2. Жим за 100
3. Присед за 200

Ну а если вы далеки от силовых видов спорта, тогда есть запасной вариант 😀

Я бы хотел в этом посте подсветить именно софт скиллы разработчика, основываясь на своем опыте

1. Умение разобраться в новом подходе или технологии быстро

Я сейчас активно внедряю TDD поход в своих проектах. В играх такой подход очень редко используется, а автотесты остаются где-то на уровне пет проектов. Однако один из моих разработчиков не стал пытаться отговорить меня от этого подхода, а воспринял этот подход как вызов. Он самостоятельно изучил какие фреимворки можно добавить, что бы улучшить тестирование (NSubstitute, Fluent Assertions), самостоятельно добавил их и использует AI для более эффективного и быстрого написания тестов. Через несколько спринтов этот разработчик научился этому подходу и делает тесты лучше меня, и я полностью ему доверяю и знаю, что он сделает все хорошо.

2. Четко излагать идеи, задавать вопросы или отчитываться о результате

На одном из проектов у нас была довольно размытая задача. Нужно перенести проект из репозитория одной студии в репозиторий другой студии и настроить сборки. Это задачу невозможно оценить и она содержит много сложностей, которые узнаются в моменте и многие разработчики могли бы просто «ковыряться» неделями. Но один мой коллега сразу начал формулировать цели, разбивать их на задачи, подсвечивать риски и раз в день формировать отчет от проделанной работе и о планах на следующий день. Благодаря этому его работа была максимально прозрачна для всех и достаточно было 1 раз в день посмотреть на его отчет, что бы понять статус проекта

3. Структурировать и систематизировать хаотичную информацию

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