Осторожно: эта статья может заставить вас пересмотреть отношение к своей профессии, себе, людям вокруг. И она вам точно не понравится!
Идея статьи возникла у меня при попытке написать комментарий к этой статье в которой под конец я в очередной раз прочитал оскорбление в адрес программистов. Приведу цитату:
"Программист — часто просто исполнитель в чужом замысле".
Ох и выхвачу я сейчас минусов... Погнали!
Коллеги! А вы не пробовали посмотреть на свою работу иначе? Просто попробовать представить себе, что от того как именно вы реализуете написанное в задаче, будет что-то зависеть? Попробовать перед тем как начать бездумно фигачить код, сначала вникнуть "а что нужно человеку для которого я это пишу?". И человек этот - пользователь, а не ваш тимлид или менеджер (хотя может и они тоже).
В курсе, что почти всегда одну и ту же задачу в разработке (в администрировании и менеджменте тоже) можно решить более чем 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 работаю тимлидом и в моих командах ни один человек не выгорел! Может потому, что ни один не выполнял "просто задачу", а всегда понимал кому и почему очень важно чтобы эта задача была сделана?
Комментарии (19)
ester132
28.01.2026 22:23А если мы чисто гипотетически представим, что не весь айти продуктовый и тем более не фрилансовый(как я понял из примеров) и чисто гипотетически предположим, что есть например бигтех, где до программиста породакт, аналитик, маркетолог, дизайнер (ещё 100500 людей) и требования приходят после этих 100 фильтров и чисто теоретически бигтеху нужно что бы программист просто написал быстро код потому что подумали за него уже кучу других людей?
А если отбросить сарказм то примеры из твоей карьеры выглядят как фриланс по исправлению ошибок за другими и нельзя такое экстраполировать на всех и тем более я почему то уверен, что задачу первому исполнителю ставили: "сделай что бы красиво было", а когда оказалось, что тормозит то почему то сразу задумались о: "наверное всё таки надо нормально объяснить что надо сделать"
reve
28.01.2026 22:23Работаю в бигтехе (который ФААНГ в кремниевой долине) и проблема та же самая среди всех тех же самых слоёв. Когда к тебе приходят люди с какими-то задачами, то ты сначала тратишь приличное время на то, чтобы понять, что на самом деле хочет конечный пользователь (внешний или внутренний). После этого начинаешь работать.
Можно работать и просто делать, что принесли, но это не приведёт ни к карьерному росту, ни к удовлетворению работой, потому что постоянно будешь доделывать доделки.
mSnus
28.01.2026 22:23Прекрасная идея! Давайте уберем всех ПМов и программисты будут сами бегать за пользователями и выспрашивать, а что бы ещё такого добавить в ТЗ, какие юзкейсы не охвачены? И засечём, когда кто выгорит.
Заменить Проектных Менеджеров на Пистолеты Макарова
Дерьмовое ТЗ - > дерьмовый результат
dyadyaSerezha
28.01.2026 22:23Полностью соглашаясь с предыдущим ораторами, добавлю. Автор путает неверно/плохо построенные процессы в фирме/команде/проекте и отношение к работе программистов. Это связанные, но две большие разницы.
Все приведенные примеры - грубейшие ошибки на этапах сбора и анализа требований и проектирования решения или даже системы в целом.
MrRitm Автор
28.01.2026 22:23Автор ничего не путает. Автор регулярно видит и слышит фразы разработчиков\админов\devops-инженеров "я работяга, мне что сказали я то и делаю".
Автору крайне неприятно быть представителем класса "работяга-ничего-не-знающий".
Автор привык смотреть на программистов (тогда в 90-х) как на полубогов, а позже как на интеллектуальную элиту общества.
Автор рос среди людей разбирающихся во всём и глубоко и имевших привычкой постоянно что-то читать и изучать.
Автор стремился стать частью этой интеллектуальной элиты и надеется, что в какой-то степени к своим 40 годам приблизился к этому состоянию.Автору отвратительны люди низвергающие программистов и других представителей профессий на стыках высоких технологий и творчества до "работяга-ничего-не-решающий".
dyadyaSerezha
28.01.2026 22:23Автор может успокоиться, так как неавтор, на 20+ лет старше автора и с на 20+ лет большим опытом программирования, почти не видит таких отвратительных людей, которых так не любит автор. Неавтор также советует автору или перейти в другую фирму, или взять неавтора на работу, где тот покажет пример вдумчивости, критического мышления, профессионализма и прочее, прочее, прочее. От так ота.
MrRitm Автор
28.01.2026 22:23Не, фирму я менять не буду точно. Мне тут очень нравится. И тут как раз редкость встретить "работяг-ничего-не-решающих".
Вообще вакансии у нас есть (в т.ч. в моих командах) и интересные. Подробности готов сообщить в личке.
Markscheider
28.01.2026 22:23Поверхностное отношение к вопросу и выгорание - это не одно и то же, но часто первое тянет за собой второе.
Причина выгорания - это не только нудные задачи, но и чувство собственной никчемности. А оно прекрасно разовьется, если ты сам или с помощью других людей поймёшь, что полгода назад написанный тобой код кривой-косой и плохо выполняет свои задачи. Bот и получается: один раз сделал тяп-ляп, потом сам же на это наткнулся, и огорчился от своей криворукости.
Хотя, возможно, такое только у перфекционистов работает. Интересно, а адепты концепции "х&%к и в продакшн" выгорают или нет?
un7ikc
28.01.2026 22:23адепты концепции "х&%к и в продакшн" выгорают или нет?
как мне кажется - абсолютно нет, эта концепция предполагает и такое же отношение к жизни.
Выгорание коррелирует с профессиональными навыками, например Синдром самозванца присущ только тем, что умеет что то хорошо.наглядно
Cordekk
28.01.2026 22:23Вспомните, что зарплата в 1к баксов для многих недостижимая мечта (особенно в регионах)! Может за те деньги, что вам платят можно поразбираться в предметной области в которой работаете и начните создавать ценность не "для дядей", а для вон того замученного рутиной менеджера по продажам, юриста, бухгалтера?
у вас данные устарели
MrRitm Автор
28.01.2026 22:23Как тут справедливо заметили в комментариях "Поверхностное отношение к вопросу и выгорание - это не одно и то же, но часто первое тянет за собой второе."
100500 слоёв ПМов, продактов и тимлидов призваны собрать требования, структурировать требования, обеспечить планирование и ресурсы. Но как именно будет реализовано что-то в коде - это вопрос к программисту. Никто же не будет спорить с тем, что есть спагетти-код и он работает. Есть индусский код и он работает. Прям совсем тупо: можно напихать if-else конструкций, а можно case использовать.
Так вот мне видится, что когда ты просто в лоб пишешь какой-то код не понимая как он повлияет на работу конечного потребителя - ты делаешь какую-то бессмысленную работу, просто за деньги. Когда ты реализуешь функцию осознавая, что она сократит количество времени на сведение бух.отчёта (например автоматизируешь получение данных из касс в бух.систему) и сначала разобрался в типих кассовых операций - ты делаешь мир бухгалетров чуточку проще и приятнее, а ещё тебя за это благодарят деньгами.
Про мой опыт: помимо прочего - да, условного фриланса по поиску и устранению ошибок было великое множество. Но грусть в том, что это не исправление ошибок которые допустил другой фрилансер. В процессе разбора каждого описанного случая я сначала спрашивал у автора решения "ты чего сделать то хотел? Почему именно такая реализация?" и каждый раз виден пожимание плечами и полное не понимание контекста. Тогда уже шёл к потребителю и спрашивал "какой бизнес-процесс тут осуществляется? Какой алгоритм действий пользователя? Какие вариации алгоритма". А когда это собрано и описано в виде хотя бы примитивной блок-схемы, тогда уже возвращаемся к коду\запросу\задаче и понимаем что было сделано не так.
Коллеги, вы когда последний раз видели блок-схемы процессов или будущего приложения\библиотеки у программистов? Не свидетельствует ли их отсутствие о поверхностном подходе который выше уже упомянули как "х&%к и в продакшн" ?
Markscheider
28.01.2026 22:23Коллеги, вы когда последний раз видели блок-схемы процессов или будущего приложения\библиотеки у программистов?
Заплакал и пошел за ведерком мороженого...
lrmpsm53
28.01.2026 22:23Почти вся работа не имеет смысла, так как работник отчужден от результатов своего труда. Чем ты больше работаешь, тем более крутую машину купит твой начальник
Подумать чём-то можно самому, можно разобраться в чем-то дополнительно. Можно, а зачем? Это влияет на зарплату? Нет - ипитесь сами с этим
MrRitm Автор
28.01.2026 22:23Ну ХЗ. У меня вот всегда рост компетенций довольно быстро влиял на доход.
Конечно начальник купит машину круче! Да и удачи ему с новым приобретением, дешевых ТО и счастливых километров! Он же на себя взял риски предпринимателя (если владелец бизнеса) или организовал мне комфортные условия труда (если нанятый менеджер), похлопотал о повышении и бонусах.
Поправьте если не так понял, но для меня Ваш коммент выглядит как "не буду разбираться глубоко, чтобы не сделать слишком хорошо, чтобы начальник машину не обновил!".
shornikov
28.01.2026 22:23В текущей реальности - программист это маленький винтик в большом механизме. То что ему пока платят больше, чем остальным - не делает его особенным и не возлагает на него дополнительной ответственности. Переживать программисту за итоговый результат - это как монтажникам натяжных потолков переживать за всю многоэтажку.
ЗЫ. Автор комментария не согласен с текущим раскладом, но что делать...MrRitm Автор
28.01.2026 22:23ИМХО это вопрос самовосприятия. Есть люди ощущение себя винтиками, а есть те, кто считает, что от него зависит многое если не всё. Как результат один стремится к совершенству, а для другого "и так сойдёт". К тому же всегда можно найти место где от тебя будет что-то зависеть. Но это вопрос желания.
Есть авторы, есть зрители.
dimskiy
Автору стоит начать с разницы между выгоранием и поверхностным отношением