Как-то незаметно быстро пролетели два месяца с последнего (первого) поста. Сегодня, вместе с ветром и осенним обострением, хочется накинуть на вентилятор.
Давайте зададим вопрос ИИ:
Кто такой программист и кто такой разработчик? Чем эти понятия отличаются друг от друга?
И возьмем пока за аксиому ответ:
Программист сосредоточен на написании кода по заданию, в то время как разработчик отвечает за весь процесс работы над продуктом, от проектирования до реализации.
Года два-три назад в нашем коллективе родился термин "Доработчик". "Доработчик" - это не программист из определения выше, а что-то другое. Он выкручивается из ситуации, не задавая лишних вопросов: ему сказали - он сделал. Зачем, почему, для кого - это уже философия, а философия в его спринтах не предусмотрена.
Парадокс в том, что роль "доработчика" кажется удобной на первый взгляд. Нет амбиций - нет разочарований. Нет вопросов - нет конфликтов. Но именно эта позиция становится потолком для профессионального роста. Разработчик (в нашем определении) не просто исполняет поставленную задачу - он понимает архитектуру, видит подводные камни, предлагает альтернативы. Он становится не исполнителем, а советником для бизнеса.
Прост ли путь из доработчиков в разработчики? Нет. Это требует любопытства. Это требует смелости задавать вопросы, которые кажутся неудобными. Это требует готовности принять ответственность не только за код и программу, а за результат работы людей и компании.
Банально звучит, да? "Просто будь любознательным." Но дело в том, что любопытство - это не врожденное качество. Это выбор, который делается каждый день: потратить лишние пятнадцать минут на изучение чужого кода или идти дальше, потому что спешишь.
Любопытство - это готовность копать глубже, даже когда очевидного ответа хватило бы. Это означает делать код-ревью коллег не потому, что ты обязан, а потому, что хочешь понять, как они думают. Это значит разбираться в том, как работает решение, а не просто применять готовый рецепт. Это требует времени. Это требует энергии. И да, это противоречит спринту, где нужно сдать три задачи до пятницы.
Но вот вам еще один парадокс: специалист, который задает вопросы, в конечном итоге решает задачи быстрее и качественнее. Потому что не тратит время на переделывание неправильно понятой задачи и не упирается в непредвиденные проблемы на середине спринта - он понимает контекст.
Понимание контекста часто требует задавать неудобные вопросы. И вот здесь начинается самое интересное. "Неудобные вопросы" часто косвенно указывают на то, что кто-то накосячил. "А может быть, мы неправильно подошли к этой архитектуре?" - и вот вся архитектура вдруг выглядит как груда говна, которую нужно переделывать. Они могут означать, что спринт нужно пересчитать - а это значит, что кто-то будет объяснять на уровне выше, почему график сорвался.
Именно поэтому вторая составляющая профессионализма - это смелость. Смелость - это не отсутствие страха, это действие несмотря на страх. Это когда ты понимаешь, что молчание хуже. Что неправильное решение, которое ты тихо реализовал, обойдется компании дороже, чем десятиминутный конфликт с лидом, РП или ведущим.
Эта смелость неразрывно связана с третьей составляющей - готовностью принять ответственность. Не только за код, а за результат. Что произойдет, когда данных станет в сто раз больше? Как это повлияет на остальную систему? Это означает больше работы. Это означает, что ты не можешь просто уйти с работы, когда код залил. Это означает, что ты берешь на себя риск. Если что-то сломается, ты не сможешь сказать: "Так была поставлена задача". Потому что ты отвечаешь за реальный результат, а не за буквальное выполнение инструкции.
И ирония в том, что самый "ленивый" путь (просто делай, что сказали) на деле требует больше сил в долгосрочной перспективе - ты застреваешь на одном месте, твоя ценность падает, проекты становятся скучными, а рынок проходит мимо - чем путь к профессионализму, который кажется тяжелее. Потому что первый ведет в никуда, а второй - куда-то.
