AI Реальный смысл работы: почему одни программисты выгорают, а другие нет

[AI]

Осторожно: эта статья может заставить вас пересмотреть отношение к своей профессии, себе, людям вокруг. И она вам точно не понравится!

Идея статьи возникла у меня при попытке написать комментарий к этой статье в которой под конец я в очередной раз прочитал оскорбление в адрес программистов. Приведу цитату:
"Программист — часто просто исполнитель в чужом замысле".

Ох и выхвачу я сейчас минусов... Погнали!
Коллеги! А вы не пробовали посмотреть на свою работу иначе? Просто попробовать представить себе, что от того как именно вы реализуете написанное в задаче, будет что-то зависеть? Попробовать перед тем как начать бездумно фигачить код, сначала вникнуть "а что нужно человеку для которого я это пишу?". И человек этот - пользователь, а не ваш тимлид или менеджер (хотя может и они тоже).
В курсе, что почти всегда одну и ту же задачу в разработке (в администрировании и менеджменте тоже) можно решить более чем 1 способом?

Вот примеры из моей жизни (в разное время в разных компаниях было):

Проблема 1. "CRM тормозит. Надо чтоб при поднятии трубки на SIP-телефоне у того, кто трубку поднял карточка новая всплывала".
Причина: Оказалось, что почти на каждую задачу в CRM выполнялся запрос типа "select * from cards;"
И это как-то работало в тестах на 5 карточках, но через 2-3 месяца работы крупного агентства недвижимости этот запрос перестал работать быстро.
Решение: Закомментировал вызов этого запроса в той части кода которая вызывалась на событие "подняли трубку", передал отчёт (по сути ТЗ) разработчикам и они доделали так: при звонке ДО поднятия трубки делаем "select id from cards where phone=...;" и потом уже при поднятии трубки человеку отдаём карточку либо новую либо уже заполненную (id нашли до поднятия трубки).

Проблема 2. "Мы купили систему под глубокую кастомизацию, настроили карточки и отчёты и теперь у нас по всей стране работа стоит потому, что система зависает каждые 30 минут"
Причина: Выясняется, что при оформлении договора нужно собирать очень много подробностей в т.ч. про движимое и недвижимое имущество. Поля - freetext в лучшем случае с ограничением по длине. КЛАДР не используется, поля дублируются т.к. в нескольких местах договора надо подставлять одни и те же данные. Итого у человека 1 автомобиль который к концу оформления договора записывается в БД как "Mazda CX-5 госномер а123бв123" и как "Мазда Цеикс 5 госномер а123бв123". Просто потому, что пишут со слов клиента и между этими заполнениями прошло минут 10, а люди склонны ошибаться.
Но у custom developer-а была задача "сформировать карточку под договор формата ...." и он сформировал. Задача выполнена быстро, подобных выполнено много, PR пройден отлично!
Решение: долго и нудно рефакторили карточки, перепиливали отчёты, прикручивали справочники, меняли типы полей.

Проблема 3. "Мы тут отчёт выгружаем, а система зависает!"
Причина: Оказалось, что отчёт писали люди которые вообще не пытались вникнуть в предметную область. В результате из БД объемом около 2,5-3Тб пытались вывалить в 1 эксельную табличку более 1 Гб данных. План запроса километровый, включает сотни join-ов.
Решение: оказалось, что нужен не 1 мегаотчёт в эксель + автофильтры почти по всем столбцам, а около 70 довольно компактных отчётов для руководителей разных подразделений в разных регионах и темы у них разные и нужны они в разное время.
Но в задаче у разработчика не было "подумай о боссах и их ассистенточках которые будут в конце года отчёт страдать!". Вот разработчик посмотрел на кластер серверов и понял, что тот справится за пару часов и сделал "тасочку по быстренькому". А потом ещё одну. А потом отчитался какой молодец - успел десятку заказчиков отчёты за неделю склепать.

Проблема 4. "Мы уперлись в производительность кластера, купи нам новых серверов под БД"
Решение: ОК, ребята. А вы точно правильно кластер настроили? Давайте глянем. Ой! А чего вы кэш то не настроили? А почему из 68 ядер используете только 2? А почему MyISAM вместо InnoDB?

Проблема 5. "У нас в БД льются данные с GPS-трэкеров по более 1000 грузовиков. Теперь когда открываем страницу мониторинга всё тормозит и периодически падает"
Причина: А почему в 1 БД у вас живут данные со всех клиентов? Ну ок, так надо. Но почему не выделить хотя бы таблицу каждому клиенту? Ну хоть партиционирование то можно было настроить и не грузить каждый раз весь объем данных?!!

Проблема 6. "У нас таблица одна составляет 80% всего объема БД. В ней вся история действий и все события. Давайте её вытащим в какой нибудь более другой тип БД, чтоб побыстрее?"
Причина: Оказалось, что просто не подумали о том, что если каждое действие подробно писать в 1 таблицу, то таблица будет очень большая. А потом "выяснилось", что можно было писать действия в разные таблицы и с разными наборами полей в зависимости от контекста, а ленту событий формировать выбирая данные из некоторых таблиц (не всех) и это будет быстрее и не надо отдельную СУБД городить.

Проблема 7. "В желтой программе не сохраняется ..."
Причина: Желтая программа пытается не Update, а Delete с указанием ID редактируемой записи, а потом Insert с указанием того же ID. Вот только delete то ли не закомитился то ли ещё чего и insert не проходит ибо уже такой ID есть!

За более чем 20 лет опыта такого трэшака от сениоров насмотрелся! Вывод будет простой: Хватит ныть и выгорать! Найдите у себя тот орган который делает из "я_работяга_ничего_не_решаю" уничтожителя проблем! Вспомните, что зарплата в 1к баксов для многих недостижимая мечта (особенно в регионах)! Может за те деньги, что вам платят можно поразбираться в предметной области в которой работаете и начните создавать ценность не "для дядей", а для вон того замученного рутиной менеджера по продажам, юриста, бухгалтера? Подумайте, как сделать не "фичу из таски чтоб PR пройти и получить 500 баксов", а как сэкономить тому бедолаге хоть 5 минут, чтобы он не умирал с отчётом ночью в офисе, а валил домой к детям которые каждый квартал теряют своего папу или маму ИП-шника потому, что очередной регулятор придумал опять формат отчёта поменять и этот формат не достаточно точно реализован в "специальной программе" и теперь надо ручками поправить чуток.

Когда интересно и почему программисты (да и другие IT-специалисты) вдруг решили, что больше они не интеллектуальная элита, а "работяги"?..

А теперь добро пожаловать в комменты, приёмник для минусов и тухлых помидор открыт!
И чтоб желчь и ненависть были особенно концентрированы, я ещё накину, что в последние лет 10 работаю тимлидом и в моих командах ни один человек не выгорел! Может потому, что ни один не выполнял "просто задачу", а всегда понимал кому и почему очень важно чтобы эта задача была сделана?