В программировании (как и в написании HDL кода и подобных профессиях) есть две школы мысли: чистолисты (строят свою архитектуру с чистого листа и пишут так чтобы поменьше отлаживать) и чистильщики (отлаживают что есть, дополняя мусором из интернета, чтобы поменьше писать). На это накладывается менеджмент, который пытается комбинировать чистолистов и чистильщиков, иногда неправильным образом, то есть ставит чистолистов править то, что налабали чистильщики. Это происходит потому, что чистильщики постоянно выглядят занятыми отладкой, а чистолист часто смотрит в потолок обдумывая дизайн, поэтому менеджмент думает что первые работают быстрее чем вторые, и пытаются соптимизировать “быстроту-качество” вот таким образом.
Такие посты после первого абзаца никто не читает, сразу бегут выражать свое мнение в комментариях, но для тех кто остался:
Программист-чистолист пишет весь продукт или крупный компонент с чистого листа, полностью контролирует его архитектуру и знает все побочные эффекты подкомпонент. При работе в команде чистолист является диктатором джунов - они должны вписаться в его структуры и следовать его стилю. При работе с равными чистолистами происходит явное обозначение территорий, формулируется четко изолирующий API, как с внешними библиотечными модулями. Если возникает баг, после триажа определяется чья это территория, после чего правка является обязанностью чистолиста-владельца. При таком подходе много времени уходит на обдумывания и переписывания, но не на отладку - ее чистолисты не любят и стараются избегать как можно.
У этой школы мысли есть большой плюс: если что-то сделано, то оно как правило работает. И три минуса:
И продукт, и подкомпоненты многократно переписываются прежде чем достигнута прочная и при этом гибкая структура. Это нервирует менеджмент.
Конфликты с джунами, которые не понимают придирок. Вплоть до обвинений в харазменте с наемом индустриального психолога для разруливания ситуации.
Вся структура может не выдержать новой крупной фичи. После чего у чистолиста встает дилемма: все переписывать или бежать. Менеджмент требует скрестить ежа с ужом, для юного чистолиста это предательство идеалов, и даже для опытного - некомфортная операция, от которой он будет пытаться отлынивать частичными решениями или обманом менеджмента.
В другой школе мысли, назовем ее “чистильщики”, проект начинается с того, что программист лихорадочно гуглит и сваливает у себя кучу кода со всяких свалок, из которого пытается что-то склеить, после чего это склееное отлаживает. Собственно именно отладка является у чистильщиков главной деятельностью - смотреть на чистый лист и на нем что-то писать они очень не любят и пытаются избегать любыми способами.
На одной из предыдущих работ был товарищ, назовем его Вася, который сначала работал как application engineer в маркетинге Raspberry Pi, а потом был поставлен делать образовательный проект с процессором на FPGA плате. Он очень боялся прикасаться к коду. Для него написать страницу кода для реализации valid-ready AXI каналов было страшнее, чем нагуглить на opencores два студенческих моста двадцатилетней давности и слепить кентавра из Wishbone и AHB-Lite, только чтобы не писать самому.
Продукт не был особо принят на рынке, потому что у всех кто это видел сразу вставал вопрос “на фига тут многослойное это, тем более что в индустрии все делается проще и работает эффективнее”. Предсказуемо, что этот человек потом стал основателем no-code стартапа, а теперь гоняет на AI. Теперь вы понимаете, откуда такие люди берутся.
Как я уже сказал, бывает некомпетентный менеджмент, который принимает лихорадочное гугление и слепление за быстроту и дает склейщику чистильщику карт-бланш что-то наваять, а потом ставит чистолиста это чистить. Это вызывает реакцию “тут надо все переписать”, что в свою очередь бесит менеджмент, который думает, что надо только внести пару правок перед отправкой заказчику.
У меня был ровно такой случай в середине 2000-х. Чтобы вы поняли масштаб проблемы, скажу что в налабанном коде товарищ использовал трехмерные массивы там где нужно было использовать дерево, и их в разных местах кода тройным циклом обходил. Когда этот товарищ уходил из компании, он спросил меня советов о будущем. Я открыл рот и начал намекать что ему нужно научиться программировать, но он меня перебил, и пояснил свою мысль: он решил что программирование для него слишком просто, поэтому он хочет стать основателем стартапа. И, так как я был основателем сфинансированного венчурными капиталистами стартапа в 1990-х, он хотел совет именно по этой линии.
Тут мне даже не нужно писать, что нынешняя ИИ-движуха - это именно тот триумф той части менеджмента, которая 70 лет ждала момента, когда они могут превратить всех в готовых отлаживать после ИИ чистильщиков, при этом с зорким глазом чистолистов. Ну что-ж, будем ждать первого падения какого-нибудь Боинга или Аирбаса, который поставит под сомнение этот подход.