Это старый пост из telegram. Хочу упорядочить контент, чтобы не вываливать longread в инструмент, который для этого не предназначен.

У меня в профиле в LinkedIn написано Trouble Shooter. Думаю, тут понятно. Это значит, что я нахожу и устраняю проблемы, пытаясь не завалить всё что на них завязано. А это, чаще всего, – чертов карточный домик.
Хочу поднять тему наоборот. Есть люди и процессы, которых можно описать как Trouble Maker. Мне ближе IT, но экстраполировать можно почти в любой домен. Разжевывать сильно не хочу. Приведу примеры:

• Говнокод. Важно понимать, что говнокодом может быть и код по стандартам DRY/KISS/SOLID. Просто он не впился сейчас в проекте. Если принципы и практики не поддерживаются всем IT в виде coding style – какой смысл в красивом коде там, где это не надо? Приходит хороший инженер и требует переписать всё на Go. Ну или С++. Не-не. Ты сначала напиши так, чтобы старое говно работало, ок? За ЭТО деньги платят.
• Незаменимый сотрудник. Всё знает. Всё умеет. Потому что сто лет уже тут работает. Ценный кадр. Умрёт – всем пизда. Проект и команда, в лучшем случае, будут хромать на обе ноги какое-то время. Пока вынужденный knowledge sharing не произойдёт. Классическая болячка. Лечится туго.
• Сесурити. Люблю эту тему. Все всё знают, но никто ни черта не делает. А если делают, то настолько через жопу, что все воют. И в следствие, – забивают. До следующего data leak. Либо мы раздаём админские права даже офис-менеджерам. Либо чихаем по свистку.
• И давай ещё про человеческое. Финансы. Кто-то проебал оплатить сервер/сервис/обеды в офис. Ой, insufficient funds! Если с обедами проще справиться, то найти железку, которая не используется, но ежемесячно на неё выделяется бюджет – квест со звёздочкой и красными глазами в подарок.

Сам приведи ещё десяток примеров про неточные требования, хреновый дизайн и прочее. Просто кто-то плохо выполнил работу или наоборот пошёл ответственно, но в тупую, по процессу, который устарел. Просто надоело документацию поддерживать. Или просто “а давайте на Ruby ебанём!”. Вот из таких “очевидно-неочевидных” мелочей и собираются достаточно тяжелые проёбы. А реакция на решение таких проблем – “ой, ну мы давно об этом думали”, “так исторически сложилось”, “а чо, так можно было?”

В общем. Я регулярно сталкиваюсь с очень простыми, но дибильными траблами. Иногда это настолько stunning, что не верю, что оно действительно так.

Вопрос: Что делать?

Ответ: Говорить и поднимать тему. На англ есть ёмкие слова – highlight, escalate и delegate. Возможно, тогда тебе не придётся нанимать и слушать консультантов со стороны. Но, учитывая их опытность и практику, – лучше DIY с расстановкой.

Ебись-веселись. Есть вопросы – ты знаешь где меня найти после смерти твоего проекта.