За мою 15+ лет профессиональную карьеру в ИТ я общался с разнообразными командами разработки как лидер, участник и сторонний эксперт. Замечаю повторяющиеся психологические особенности, по которым можно условно поделить технарей на зрелых и не очень. Это эдакие “кризисы взросления”, через которые я проходил и сам. Сегодня посмотрим на три особенно ярких признака, характеризующих майндсет зрелого технического специалиста.
Best code is no code
Арка развития разработчика зачастую приводит его к видению своего кода как безусловного блага. Код прекрасен и имеет ценность уже по факту существования. Этому фетишу способствуют красивые, но кривые переводы типа “Совершенный код” (хотя в оригинале у Макконнелла “Code complete”). Юный адепт понимает, что старшие товарищи носятся с кодом, но пока еще не совсем понимает почему.
Теория решения изобретательских задач aka ТРИЗ гениальна уже в том, что ставит вопрос ребром. Ребро простое – идеальная система это система, которой нет, но функция её выполняется. Несмотря на мощь ТРИЗ в разрешении противоречий это фундаментальное противоречие как правило все же разрешается в пользу появления системы в каком-то виде. Идеологически близкая мантра “the best code is no code” прекрасно иллюстрирует проблему.
Любой код требует а) создания и развития и б) эксплуатации и поддержки, с точки зрения разработки это всегда liability. Плюс код это все таки средство достижения цели и его “совершенство” имеет вполне прагматичные критерии: гибкость, поддерживаемость, портируемость – все как в НФТ конкретного проекта, описаны они явно или нет.
Качество кода несомненно важно и ценно, но не менее важно отдавать себе отчет в том, что это не самоцель.
Отлитые в камне требования
Разработчики как правило хотят делать свою работу хорошо. И в определенный момент они понимают, что залогом хорошего исполнения является как можно более полная фиксация ТЗ до начала разработки. Появляется даже аллергия на корректировку требований и стремление сделать все как надо с первого и единственного раза. И конечно же ни в коем случае не дай боже не переделывать нечто уже сделанное!
Не меньшее влияние оказала вероятно fixed price заказная разработка, где каждый чих заказчика мимо ТЗ непосредственно палит в доменной печи маржу подрядчика вплоть до отрицательных значений, что не такая уж и редкость к сожалению.
Agile ворвался в довольно вотерфольный по своей сути процесс разработки не потому что смузи аджайл-коучам так захотелось, а потому что ничтожно малая доля разработчиков занимается софтом для космических аппаратов, где детальная upfront-фиксация ТЗ стоит того. В большинстве случаев гораздо оправданнее быстрее итерироваться – получать обратную связь от реальности на свои усилия и адаптировать эти усилия соответственно.
В мире не видно трендов на замедление темпов развития бизнеса, скорее наоборот, а значит в большинстве случаев скрижали с требованиями будут только дальше отходить в прошлое. Именно поэтому ценность гибкости и адаптивности разработки будет только расти.
Lack of dogfooding aka прогер-UX
Коллега axsapronov как-то сформулировал регулярный паттерн бугурта как “да емае, просто сам потыкай” с типовым источником в виде волшебного кодер-стайл UX корпоративных систем.
Я уже рассказывал про технику dogfooding-а в мета-подходах, но как ни странно переоценить важность этого подхода практически невозможно.
Никакой расцвет аджайла не перебьет любимое забрасывание результата своей работы через забор для расхлебывания downstream рабочими центрами, особенно когда подобное поведение подкрепляется KPI / финансовой мотивацией.
Масла в огонь несомненно доливает и режим потогонки в стиле “делай, а не думай” с жесткими дедлайнами и бесконечными бэклогами задач со срочностью “вчера”.
Умение взглянуть на постановку задачи шире рамок своего кусочка “конвеера” и убедиться в том, что результат и правда получается – бесценно. Отлично дополняет майндсет зрелого технического специалиста.