Пиздеть - не мешки ворочать, или суровые проектные будни

Привет, тора гой дневничок. Если спросить человека например 80-х годов рождения - кем жеж ты хотел быть в децтве, то как правило там будут космонавты-летчикииспытатели и прочие полярники. Ну потому что пропаганда, кровавая гэбня и вот это все. Потом десятилетие боли и унижений расставили все по своим местам, кто-то пошел торговать трусами и шавермой, кто-то стал директором газпрома и ахметовым. Но речь вообще не об этом, а о том - какая же разница между детскими ожиданиями при начале разработки проекта, и суровой действительностью.

Нет ничего более постоянного, чем временное.

Как правило, когда программисту впадлу сделать хорошо, или нехватает времени, или паук не велит - программист тулит костыль. Менеджменту при этом поясняется - дачо, это временное явление, мы потом в светлом будущем все перепишем. Гойспода и таки дамы, это <h4>НЕ РАБОТАЕТ</b>. Вот так, жирным капсом. Если в код влез костыль - значит с вероятностью 99% он там и останется. Навечно. Причем, если программист планирует остаться в этой конторе надолго - то этот костыль же к нему и вернется. У меня есть пример кода, когда продвинутый девелопер прочитал про Enum и понял - в них жеж можно совать всякие данные. Ну и засунул. Части SQL запроса. Не шутка. Потом по этим наборам enum-ов запрос таки собирался и как-то там выполнялся.

После нас хоть потоп

Чрезвычайно распространено чуть менее чем везде на территории постсовка. Это когда у соседней конторы уводится заказчик Джон, путем выставления чуть меньшего рейта и ужимания сроков в два раза. Потом под это все дело пишется кое-как работающий прототип, который с гордостью показывается на трех (из заявленных) десяти юзерстори. Под это дело забирается бабло и контора ищет следующего заказчика. Про поддержку, документаривание и оптимизацию-рефакторинги там никто не думает, по двум причинам - во-первых, на это все равно нет ресурсов. Во вторых - не нужно по причинам идеологического характера, о чем ниже.

Откуда дровишки?

Существует определенный стереотип, что хорошо написанный софт в поддержке не нуждается. Многие кухарки менеджеры от сохи понимают это так, что на саппорте можно поднять дополнительно деньгов, если грамотно просрать процесс разработки. Схема простая - выкатывается нечто, что кое-как работает, а все доработки - за отдельную плату. Как это ни странно, но даже сейчас можно неплохо поймать контору на такие штуки. А если грамотно сделать привязку к себе путем “а мы тут нахуячим на хаскеле” - то в случае умеренной наглости длительная и приятная кормушка обеспечена, особенно в каком-нибудь сколково. Соответственно писать хорошо в таких конторах, по вполне понятным причинам - не принято.

Сила есть - ума не надо

Обычно случается в кровавом ынтерпрайзе, где никто не считает гигабайты. Ну то есть там по определению все ынтерпрайзно, фермы там серверов, облачные хранилища данных и прочие модные штуки на петабайты. Соответственно в подавляющем большинстве случаев проблемы с производительностью решаются путем “докупить мозгов”, но только не девелоперам - а бедной железяке. А бедная железяка применяет числодробилку на 99% для нагрева воздуха, и оставшимся процентом считает котировки акций. Все довольны. В здесь пригодились бы олимпиадники, но увы - там где действительно требуются их мозги - их как правило нет. Ну потому что ынтерпрайз. Не по хипстерски.

Читай код, сука

Любимый и вечный способ отмазывания от написания хоть какой-то проектной документации. Вообще же, по моим наблюдениям, люди, способные написать связный технический текст - как правило могут хорошо проектировать системы, делать архитектуру и писать код. Это конечно же не означает, что технические писатели все поголовно клевые программисты, но вот обратное верно - все годные программисты способны хорошо писать документацию. Другое дело, что это в большинстве случае неинтересно и “да я бы уже сто раз код написал чем эту спеку”. Но тут случается подмена понятий - проектная документация - это не написание кода. Это более высокоуровневая хрень, которая описывает как и что должно работать в принципе. Код в даноом случае вторичен. Если проводить аналогию - то писатель проектной документации это такой себе инженер, а вот программист - это токарь-фрезеровщик. Но увы, разделение труда на архитекторов и кодеров не работает, в частности потому что принцип работы токаря не меняется с каждым годом. Госты и прочие ЕСКД не меняются, все чертежи и спецификации оформляются согласно им. Надобность постоянно быть в курсе всех изменений предметной области, новых парадигм и прочего - отсутствует.

Менеджер один раз - менеджер навсегда

Как следует из предыдущего пункта, если вы внезапно оказались в менеджерах - вернуться назад к коду будет крайне сложно. Во-первых, понимание внутренностей процессов разработки скорее всего останется в прошлом. Во-вторых основная работа сведется к митингам, петтингам, писанию отчетов и ремарок на отчеты, составление графиков работ и прочей полезной фигне. И чем дольше вы менеджер - тем сложнее. Да и менеджерская позиция - это бОльшее бабло и бОльше вариантов свалить свои проебы на технарей. Так что если приходит предложение о повыситься до менеджера - надо к этому отнестись как к проводам программистской карьеры.