Комментарии 68
Никого не повышают за простые решения
Хуже того - еще и начнут искать способ избавиться от такого разработчика. Не везде и не всегда, но случается. Со мной, к примеру, такое было. Даже обозвали "саботажником" ))). Расстался с легким сердцем
Аналогичный опыт, даже с "саботажником".
…когда меня завкафедрой порекомендовал на производство, я начал с того, что повыкидывал всё лишнее, после чего моя зарплата удвоилась. Те, кто пропихнули это лишнее в своё время, как я потом узнал, получили аванс и растворились в воздухе, так что моя критика очень ко двору пришлась — типа «о, а этот вчерашний студент тоже понимает, что те два осла были два осла» :) Как я ещё более потом узнал — они тупо скопипастили пример из ПДФки, в котором было, естественно, максимальное количество всего на все случаи жизни, а в разработку не умели :) Типа той недавней статьи про «передавал мои запросы в чатгопоту» %)
Всякое бывает.
Вы хоть думали над чем работали или вам дали задачку написать?
В статье правильный посыл: нужно уметь показывать различные опции и обосновывать свой выбор, в противном случае может сложиться впечатление, что разработчик может только в просты решения.
…и яду побольше, чтобы было сразу понятно, где эти «решения взрослых дядек» уже сидят :-D
Обоснования не всегда работают. Чаще покивают головами, но в итоге продавят своё решение потому что оно им ближе и "понятнее"
В статье также правильный посыл для рукой водителей, а именно: уметь понимать, что простые решения не нужно доказывать и обосновывать сложым образом.
И да, все мы можем только в простые решения. Сложные решения пишет уже не один разработчик, а команда.
Очень точное наблюдение. На практике проблема ещё глубже : сложность легче демонстрировать, чем простоту. Сложную архитектуру можно показать диаграммами, новыми сервисами, очередями, слоями абстракций. Она создаёт видимый объём работы. Простое решение часто выглядит так, будто «ничего особенного не произошло».
Но в зрелой инженерии ценность обычно определяется не тем, что было добавлено, а тем, какой сложности удалось избежать.
Хороший инженер способен построить сложную систему.
Опытный инженер способен понять, почему она пока не нужна.
Самая дорогая часть любой архитектуры — это не её создание, а её долгосрочная стоимость: поддержка, когнитивная нагрузка, время онбординга новых разработчиков, риск скрытых взаимодействий между компонентами. Поэтому каждый дополнительный уровень абстракции должен платить «арендную плату» — приносить реальную ценность уже сейчас, а не гипотетически в будущем.
Интересно, что во многих сильных инженерных культурах архитектурная зрелость измеряется не количеством паттернов, а наоборот — способностью удерживать систему простой настолько долго, насколько это возможно.
Потому что сложность всегда можно добавить позже. А вот удалить её из живой системы значительно труднее. Именно поэтому один из самых недооценённых инженерных навыков — это способность сказать:
«Мы понимаем, как это можно усложнить. Но сейчас это не нужно».
Как то так. ИХМО
Редкий случай, когда за комментарий + в карму :)
Золотые слова! У нас в России, вот уже лет 15 по моим наблюдениям, кол-во архитектурной астронавтики выросло в разы и удержать архитекторов/лидов от внесения необоснованой сложности - дорогого стоит. Проблема в том, что последствия этой сложности проявляются спустя годы разработки и цена таких ошибок очень велика.
Я побывал с двух сторон крайностей и могу сказать что выбор всегда идёт к тому что понятно и привычно решающей стороне. Все остальные доводы не имеют значения, только заработав репутацию и кредит доверия можно внедрять свои решения
Да, так в любом деле, никакой логикой и аргументами не объяснишь, большинство смотрит только на авторитет, но хорошо, что в моем ИТ мире такое не часто встречается и гениальные люди чаще находят себя, чем например на заводах и политеке.
Вспоминается фильм Идеократия, где после попыток логически объеснить, герой сказал, что он умеет разговаривать с растениями и они сказали, что хотят воды.
У кого оценка у того и власть. И если держатель оценки не понимает, то он оценивает как низкую ценность. Не важно, что он не понял. По своей или не по своей компетентности, или некомпетентности
Сложную архитектуру можно показать диаграммами, новыми сервисами, очередями, слоями абстракций. Она создаёт видимый объём работы. Простое решение часто выглядит так, будто «ничего особенного не произошло»
Показать простую архитектуру, а графиками и диаграммами показать, сколько проблем и затрат избежит босс
Всегда в своей работа предлагаю все возможные варианты решения от простых до сложных и стараюсь по возможности использовать более простые решения. Везде есть свои плюсы и минусы, но в простых решениях есть существенный плюс - оно более надежное само по себе, так как, как правило, в нем будет меньше составных частей, поэтому его легко и дешевле поддерживать, оно очевидно как работает и дорабатывать его проще. Но не всем и не всегда подходит простое решение.
За статью - спасибо! Простота спасёт мир!
Хз, как я заметил повышают не за технические решения, а за то что ты решаешь бизнесовые проблемы быстро и чётко (по крайней мере начиная с мидловой позиции) - как именно не особо интересно никому. Это не есть плохо, просто в принципе пофигу что ты там нарешал, главное чтобы успел по сроку, выполнил требования и уложился в ограничения. Хоть доску положи, хоть лифт построй, хоть тушкой, хоть чучелком )
Так о том то и речь. Выше, в комментариях , уже упомянули тех кто быстрых решений бизнесу дал и свалил в туман, с авансом. А в итоге все убрали. Ценность простых решений очень хорошо проявляется на длинной дистанции. И для бизнеса и для психологического здоровья все команды. А здоровье команды хорошо сказывается на бизнесе :) Да и простые решения не всегда быстые, как требуют проработки путей. А если результат 10 строк, а потрачена неделя ... То вероятность возникновения вопросов, к эффективности исполнителя, резко возрастает.
А как потом разгребать этот говнокод через 2 года? Или вы там уже не будете работать?
"Чистая архитектура" для эффективных менеджеров.
YAGNI; KISS для своего софта который решает реальные проблемы
А вот про реализацию девушки сказать особо нечего. «Реализовала фичу X». Всего три слова. Хотя её работа была лучше
потому что так нужно было для истории?) я не увидел никаких критериев оценки задачи персонажей, чтобы можно было сделать вывод, чья работа лучше. быстрее, проще - да, это прямым текстом написано. лучше? кто сказал, кто оценил?
Простота всегда в почете только для того, чьи цели она преследует. Все различие будет в мотивации, если мотивация "повышение", то "простота" теряет свои плюсы. "Адекватность" в подавляющем большинстве компаний не является мотивацией.
Не знаю, может так где то и есть, но обычно повышают, за то, что твоё решение денег конторе приноси , а какое оно менеджеру грубо говоря наплевать, ну и ещё расходы на поддержку минимальны.
По моему опыту, делал долго но качественно, никто не вспомнит, что долго делала. Сделал быстро и с багами, все будут помнить только про баги.
А про способ решения вообще никто не спрашивает из тех кто принимает решения по повышению. Смотрят только на результат в деньгах.
но обычно повышают, за то, что твоё решение денег конторе приноси
Нет. Это может работать в шарашках на 5 человек, где фаундер знает каждую задачу.
Человек от 100 уже никто не знает, какое решение принесло сколько денег, и, принесло ли, или отняло. И, об этом и статья, что сложное решение создаёт видимость, что принесло ценность
А потом простое решение просто работает и его никто не замечает. А потом что-то сложное ломается в проде, от чего подгорает у всей конторы, общими усилиями сутки напролёт что-то усиленно «чинят, фиксят», в том числе эта девушка тоже помогает. В итоге сильный программист наконец находит слабое место в своей «сильной» архитектуре (кому как не ему, знать, где там и чего искать), торжественно фиксит его на радость руководства, что наконец избавил всех от проблем, за что еще и лычек и ништяков получает. А девушка - нет.
Сложное решение можно распространить (ровно так оно и происходит) наверх в очень больших масштабах, записать в заслуги по координации и внедрению многим начальникам в свои достижения с последующими плющками (финансирование, расширение штата. А чем больше штат подчинённых, тем зачастую выше аппаратный вес начальника). Плюс за рацуху давно не премируют, ибо лучше промолчать, пусть буржуй и дальше прыгает со своей сложной системой/производством, а я, за свои условные 45 тыщ, посиду на стуле ровно.
//Выше ИМХО, не более..
А вот «Проанализировал три решения, включая событийно-ориентированную архитектуру и собственный уровень абстракции. Решил, что простая реализация отвечает всем текущим и прогнозируемым требованиям. В итоге за два дня реализовал решение, в котором за шесть месяцев не возникло ни одной проблемы». Это описание всё той же простой работы, но уже с выражением стоящих за ней рассуждений.
А если в силу опыта, рассуждения как такового не было. И разработчик интуитивно понимает что надо сделать просто, потому что так проще и быстрее. И в целом простой код потом не сложно доработать.
И теперь выходит, прежде чем писать отчёт сначала нужно найти более сложные пути?)
Я когда-то так диплом писал. Я сразу знал что на ПЛИС арктанген считается через CORDIC, но для объема диплома я нашёл ещё пару методов которые ни в какие ворота на Плис не укладывались, перечислил и описал их, а потом "только один метод нам подходит, это кордик")))
Я сразу знал что на ПЛИС арктанген считается через CORDIC, но для объема диплома я нашёл ещё пару методов которые ни в какие ворота на Плис не укладывались, перечислил и описал их, а потом "только один метод нам подходит, это кордик")))
Ну в целом-то так и надо. Как иначе формально показать, что вы не с потолка взяли метод расчёта, а проанализировали разные способы?
Давно сам хотел написать статью на эту тему, но Вы меня определили. Спасибо за отличный материал, который стоит положить к себе в заметки как руководителям, так и разработчикам.
Сам на текущем проекте постоянно сталкиваюсь с наследием прошлых команд, которые любили оборачивать всё в сложные, многослойные системы везде, где могли дотянуться. Что мы получили в итоге при поддержке старых фичей - чтобы понять, что происходит при нажатии на кнопку, нужно пробраться через несколько уровней абстракции, порой через несколько модулей, в итоге увидеть примитивный запрос на бек или поход в базу в одну строчку. Зато со стороны такое решение кажется максимально гибким и масштабируем. По факту же, порой трудозатраты на добавление функционала, почти равны написанию с нуля. А "идеальная" архитектура прошлой команды, в прямом смысле превратилась в техдолг нынешней.
Более того. На уровне выше это работает ещё лучше. Серьёзный менеджер имеет большой хедкаунт и большие бюджеты. Не может лох с 3мя подчиненными так же зарабатывать и ездить на такой же машине, как серьёзный победитель по жизни с 3000, даже, если он смог силами 3х все автоматизировать и делать тот же объем ценности. Соответственно, усложняторы-инженеры часто образуют симбиоз с усложняторами менеджерами.
Давайте, я кое-какую фразу приведу: «Ребят! Очнитесь! Нам платят не за это! Нам сейчас нужно реализовать X, а не сделать задел на будущее. Если нам в будущем понадобится расширить, то мы расширим, за что нам ещё заплатят. Не берите лишнюю работу! Пишите чистый и хороший код, чтобы потом, в этом самом будущем, не пришлось копаться в дерьме!»
да временами складывается ощущение, что эти "ребята" сами себя уважать не будут, если дважды два без десяти уровней абстракции посчитают.. и даже если ты их авторитетом сподвигаешь (или административно заставляешь) делать проще - эти "ребята" грустнеют, считают тебя ретроградом, старпёром и всяческим врагом прогресса, в отличии от них ))
и это беда, с которой я в принципе не понимаю как быть((
Идеал это самое простое для текущей задачи и требований решение. Пытаться поиграть в Кассандру и предсказать что там потом понадобится, практически всегда это предсказание будет мимо, зато переусложненный код будет годами висеть в кодовой базе и отжирать время жизни и нервы у твоих коллег и тебя самого. Хуже всего что и выкинуть его потом может оказаться слишком сложным.
Как по мне - простое и понятное решение всегда можно переписать и усложнить, когда это реально потребуется, а вот наоборот работает крайне редко, переусложненный лабиринт абстракций и нагромождение паттернов добавленных по принципу "что-бы было", не так то просто упростить, потому что истинный функционал часто маскируется всей этой сложностью.
Бедный хомячек
Я строитель -проектировщик.
Поддерживаю.
Сложный проект-франкенштейн, сшитый из кусков прошлых проектов, со множеством коллизий, много сложных листов. Вызывает уважение, хорошо оплачивается и во время создания, и во время сопровождения. Делается быстро.
Осознание и оптимизация задачи, когда на выходе - простое эффективное решение: заказчик такой: "а за что здесь платить? Все просто". Подрядчик: "блин, никаких допов". Авторский надзор и сопровождение не нужно. В итоге - все недовольны, проектная организация работает в минус.
Представьте, что находитесь на этапе проектирования системы и предлагаете простое решение. Одна база данных, простой API и, быть может, дополнительный уровень кэширования. Рекрутёр задаёт вопрос: «А как же масштабируемость? Что, если у вас будет десять миллионов пользователей?»
— Вы умеете водить карьерный самосвал?
— ???
— В один прекрасный день у нас будет десять миллионов пользователей.
— Простите, это точно вакансия доставщика пиццы?
На правой картинке подводный баг?
Нам нужна новая вакансия: профессиональный словоблуд - чтобы было кому перевести ваше "решила эту фирму" в 400 слайдов презентации с графиками, картинками и исследованиями темы.
Во-первых, к чему эти изначально предвзятые "девушка" и "парень"? Чтобы ещё раз ненавязчиво намекнуть, что бедную девочку угнетают?
Девушке поручили реализовать некую функциональность.
Парню досталась похожая задача.
Похожая - не та же самая. Эти задачи, скорее всего, были вообще в разных проектах. Иначе за каким чёртом заново всё анализировать и придумывать: бери решение девушки и используй?
Опять же ничего не сказано каким образом у девушки получилось 50 строк, а парень пилил "более надёжное решение". На ровном месте такого не бывает. Скорее всего, то, что сделал парень, было реализовано сторонней библиотекой, которую девушка притянула в проект. А вот целесоообразность этого под вопросом, т.к. сторонняя зависимость - это всегда техдолг, потому что её надо обновлять, в ней могут быть неочевидные баги, которые как-то придётся исправлять/обходить/etc.
С другой стороны, куда смотрели ревьюверы, проверявшие решение парня? Они не видели ненужного переусложнения?
Упрощать - сложно, усложнять - просто... упростить = что-то отрезать, это требует понимания работы всего механизма целиком, и принимающий такое решение берет на себя весомый риск... усложнить = добавить, часто нашлепка, где ответственность только за нее, нашлепку...
В итоге имеем кругом бесконечное усложнение... и даже когда все кругом запутаются - решение останется тем же самым - очередная нашлепка которая временно разошьет узкое место и просто отсрочит неизбежное... кризис, когда нет ответственного и/или это уже неважно - дает возможности упрощения, это важно...
Как по мне всё как раз наоборот: обычно задачу надо сделать "ещё вчера". Поэтому на архитектуру кладётся большой болт и делают всё макисмально топорно, чтобы хоть как-то к сроку реализовать хоть какое-то подобие требований заказчика.
PS "- Вон sql-щик у вас свободный, вон пусть и рендерит HTML странички админки в хранимках вместе с бизнес-логикой, которую там же и напишет".
Краткое содержание статьи: YAGNI.
Развёрнутое содержание статьи: You Aren't Gonna Need It.
Статья написана как анти пример к её основному тезису, я правильно понял?
И каждый согласен, и знает, что он не такой
Как-то притянуто за уши. Как будто в команде больше нет разработчиков выше уровнем, чтобы парню сказать "нафига", а из девушки вытянуть "почему так" для тех, кому не очевидно. И совет в конце как раз об этом: мало выбрать простое решение, надо ещё обосновать, ровно как и сложное.
Не повышают скорее из-за плохой коммуникации ака продажи себя, об этом уже столько сказано. И если девушка стабильно делает просто и хорошо, разработчик(и) уровнем выше обязательно об этом начнут "намекать" менеджменту (в нормальной среде). И наоборот.
Работал с таким руководителем, из всех вариантов решения задачи выбрать максимально всратое и кривое, угробить на него кучу человекочасов, расширить под него команду, обложить костылями, не успеть к дедлайну, перетащить инженеров с других задач, наплодить еще больше костылей и абстакций, наконец запустить этого монстра в прод, еще пол года подпирать костылями, провести пару рефакторингов, написать миллион красивых отчетов, перейти к следующей задаче по тому же принципу. Через год узнать, что старое решение невозможно поддерживать и торжественно похоронить его, взяв под решение задачи следующий по всратости подход и повторить цикл, зато все при деле и можно много красивых диаграмм на верх владельцам бизнеса слать и бюджеты выбивать под поддержание на плаву этих решений. Всеx, кто предлагают взять работающий простой инструмент и закрыть задачу быстро - перевести в саботажники.
можно много красивых диаграмм на верх владельцам бизнеса слать и бюджеты выбивать
Хееее, так ему было кого найопывать…
Если можно из политических соображений шепнуть разрабам, что мы сегодня найопываем, а не работаем (а ой как не всегда такой уровень доверия между руководством и работниками в принципе возможен! Мне как-то даже и не сказать, чтобы вообще попадалось) — ну тут другое дело. Тут даже мысли не будет возникать сделать просто и хорошо. С душой, огоньком и злорадным смехом будут придумывать самый задорный вариант!
На самом деле это чисто советское¹ жульство, заточенное под плановую экономику. Но если владельцы бизнеса «из партийных пиджаков в малиновые» — то у них как раз иммунитета к этому нет! И если руководитель это смог прощупать, то в своём выборе решения он проявил себя совсем не как дурак, о неееет. Он проявил себя как достойный персонаж О. Генри, который сумел одержать «победу разума над сарсапариллой» в отношении очень труднообжуливаемого фермера.
Моральную сторону того, что вместо решения на свет произведено «мошение» — оставим за кадром. Но в качестве жулика этот руководитель явно проявил себя не хуже, чем ткачи, огромными усилиями и превозмоганиями (за соответствующую цену) одевшие Голого Короля.
¹ Можно оспорить, конечно. Я и сам неоднократно разбирал аналогичные явления у буржуев. Но там немного другие корни.
Самое сложное в таких проектах научиться отключать голову и делать тупо то, что в задаче, не пытаясь сделать лучше и не проявлять инициативу, платили хорошо, а от полного отупения спасали пет проекты. Лично меня всегда удивляло, что при всех аудитах и прочих инструментах анализа и бигдаты эти решения всегда получали апрув от верховного руководства.
По опыту работы в нескольких компаниях, могу сказать точно. повышение получит тот, кто с начальством на короткой ноге.
Как РПшник скажу, что бизнес - это всегда про риски сроков и денег.
Большое и сложное решение которое якобы решает проблему бизнеса. Но на деле риск просрать много сроков и денег.
Своим заказчикам я зачастую при релизы спрашиваю: вы хотите фичу для теста гипотезы? Или вы точно знаете что это вам нужно? Что вы от этого выиграете?
Если вам точно нужно именно это - то устроит ли вас быстрое решение для теста прямо сейчас "На троечку", или нужно всеобъемлющее и огромное вылизанное решение, но через 3-6 месяцев "на твердую пятерку"?
Как правило если речь идет не о ключевых фичах, о деньгах или потере данных - то соглашаются все на "Троечку" сейчас.
Оговорюсь - решение на "троечку" хороши только если, потом переделка этого не приведет к 2-ой, а то и тройной-четверной цене на переделку.
Например, если в будущем через год, два-три с решением "на троечку" потребуется изменить ядро системы или основной бизнес-процесс, то мы его перепишем под ключ, накатим кучу миграций, сформируем огромный теходолг переноса фич с момента релиза "фичи на троечку", да ещё и упоремся в тестирование на пофичное, регрессионное и нагрузочное.
Если уж совсем на пальцах: то решение на троечку - "это форма авторизации с емэйлом и паролем", которая умеет пускать пользователей по точному совпадению пары емэйл - пароль с тем что есть в СУБД с отсеканием SQL-инъекций. Ничего больше она не умеет.
Решение на 5+ - это форма с валидацией по маске почты, с подтверждением ящика на лету, возможностью перехода на регистрацию, если такого пароля нет в СУБД, с хранением данных в сессии браузера в шифрованном виде, и требованием по сложностью ввода пароля, который меряется с каждым новым введенным символом. ПРи этом еще и адаптивно и нативно для моб. устройств. Ну и пусть ещё все это вылизано на PixelPerfect задротство.
Иные заказчики порой сразу упарываются в такую вот форму авторизации, забывая - что это чисто утилитарная функция - дать или не дать доступ человеку в систему. Все основное и вкусное за этими воротами. Но решение "3" делается за полдня-день, а на "5+" можно недели или даже месяцы потратить. Хотя всего лишь форма в 2 поля и 3 кнопки, 1 BE-ручку.
KISS должен быть с языком :Р
«Проанализировал три решения, включая событийно-ориентированную архитектуру и собственный уровень абстракции. Решил, что простая реализация отвечает всем текущим и прогнозируемым требованиям. В итоге за два дня реализовал решение, в котором за шесть месяцев не возникло ни одной проблемы»
Никого не повышают за простые решения