Привет! Если по вашим венам уже во всю течет оливье, но полноценно работать работку пока не тянет, или просто хочется легкого полезного чтива с котиками, то данная статья с блеском подходит под это описание. В ней я постараюсь на реальных примерах рассказать об одном навыке, который считаю ключевым для работы в ИТ, и которому уделяется не так много внимания, как он того заслуживает. Технари любят устраивать холивары — про архитектуры, паттерны, языки программирования, но все это иногда совершенно не то.
Этот главный навык пригодится всем в индустрии — программистам, лидам, продуктологам, тестерам, менеджменту и всем остальным.
Имя ему этому навыку — здравый смысл.
Да, вот так просто, но на самом деле все совсем не просто, и я сейчас это объясню.
Как сделать сразу хорошо
Давайте сразу с места в карьер: за 16 лет в индустрии я повидал изнутри несколько сотен самых разных проектов и команд — успешных и не очень, больших и маленьких, с кучей интеграций и самыми разными архитектурами и подходами. И все эти проекты объединяло одно — что у них вообще ничего общего между собой не было.
К сожалению, люди очень сильно верят в различные стереотипы, и в ИТ часто случается большой стереотип о том, что есть один проверенный способ чтобы все сделать сразу как надо.
Но есть большая проблема в том, что как надо у каждого свое и единого рецепта здесь просто нет. И вот это целеполагание, причем на микро и макро уровнях, вместе с умением задавать правильные вопросы правильным людям — и есть самый важный навык. Потому что умение остановиться, оценить обстановку и несколько раз задать себе и другим вопрос «зачем?» — оно зачастую сильно видоизменяет наш план, которого мы будем придерживаться.
Я для себя называю это «технический менеджмент», то есть это такой человек, способный одинаково хорошо говорить на разных языках — дизайнерском, программистстком, маркетинговом, бизнесовом и так далее. Зачастую люди любят свой круг общения, но не понимают нюансов и специфики работы своих соседних коллег (я бы даже, с вашего позволения, сказал бы что часто все друг друга взаимно считают глупыми пи%орасами) и без «переводчика» одно и то же может трактоваться СИЛЬНО по разному разными людьми.
«Опять они там че-то придумали, а нам упарываться» — знакомо? Умение понимать чужую специфику, слушать людей и подниматься до самой сути проблемы, предлагать разные решения и находить баланс интересов — все это очень сильно помогает находить общий язык с людьми и избегать карьерных проблем.
Спецы в ИТ, как правило, фанатики точных наук, поэтому любая поставленная задача сразу воспринимается как есть, хотя на самом деле она такой может совершенно не быть, просто ее поставили как смогли. Вот как смогли так и поставили.
Если составить облаго тегов из первичных вопросов со здравым смыслом, то получится что-то такое: для кого мы это делаем? Должно работать быстро или точно? Какая цена ошибки? Зачем? Кто заказчик фичи? Кто пользователь? Какая нагрузка? Какие трудозатраты? Какой профит? Почему именно так?
Таких вопросов можно назадавать много, но давайте уже перейдем к примерам из заблуждений.
1. Идея, над которой придется упороться
Самое большое количество конфликтов возникает, когда люди говорят совсем на разных уровнях понимания и когда задача проходит через сломанный телефон других сотрудников. Допустим, кто-то большой спустил через других сотрудников задачу Х, дальше возможно много вариантов.
Под X подразумевалось именно X и надо делать строго так
Под Х подразумевалось именно Х, но в процессе кем-то трансформировалось в Y, где Y может быть как проще, так и сложнее
X это лишь примерное обозначение, решение за вами
Х обозначение, решением за вами, но кто-то хитрый по пути перефразировал до Y, который очень сложный
....
Вариантов может быть множество, но если к вам пришла задача сделать что-то большое (или критическое), что может затронуть ядро технологии или потребует больших переделок, здравый смысл — ровно то, с чего нужно начинать. Возможно, задача изначально звучала не так, масштабы бедствия преувеличены, срочность завышена, а вместо недели работы сгодится разовый компромисс за час.
Всегда важно здраво оценивать истинные потребности и сроки задач, которые к вам приходят. А иногда приходится подняться на несколько уровней «зачем», потому что только там вскрывается истинная проблема, а дальше сформулировали как смогли, исказив весь смысл.
Большинство людей все же готовы слушать, если вы готовы спокойно и аргументированно с ними говорить. Не все и не всегда, конечно, но прежде чем упарываться — попробовать стоит.
2. Нужно сделать срочно
«Срочно» — это очень емкое слово, в которое в корпоративном мире могут влезать самые разные интервалы. Для кого-то срочно это час, для другого — несколько дней, поэтому если к вам пришли со срочной задачей — стоит узнать что именно подразумевается под срочностью и кем именно.
Мой самый любимый случай — менеджером был обозначен срок в виде «бросай все, надо делать», но позвонив вместе напрямую заказчику выяснилось что их конференция через месяц, а первый результат нужен будет лишь через три недели.
3. Мы должны работать под высочайшей нагрузкой
Менеджмент — зачастую очень амбициозен, а программисты — очень увлеченные, поэтому всем вместе делать большие сложные проекты гораздо интереснее, чем простые. Программистам часто от менеджмента спускаются мифические ожидания о миллионах пользователей и миллиардах выручки уже вот-вот, поэтому нужно сразу заложить очень серьезную архитектуру под серьезную нагрузку. А через полгода бюджет на разработку проекта сгорает без единого живого пользователя.
Сколько хороших архитектур и программисточасов в проектах сгорело на том, что готовились к нагрузке, которой никогда не случилось? Здесь важно понять, что если за вами большая компания, готовая бесконечно вливать деньги — без проблем, но если такую архитектуру с кучей апстримов с гео-балансировщиками и шардированием пытается делать голозадый стартап (у которого такая архитектура это не самоцель), то здесь может быть что-то не так в здравом смысле и постановке задач.
4. Здесь надо все сжечь и переписать
С такой классной идеей как правило, на проект приходят новые сотрудники. Видя несовершенный код, с кучей костылей внутри, окрыленный сотрудник предлагает это все сжечь и переписать сразу по нормальному. В идеале — переписать сразу на другом языке, потому что в этом сезоне особо популярен dast/brainfuck/perl. К сожалению, такие порывы без должной страховки и опыта практически гарантировано приводят к большим проблемам, потому что сначала все красиво и хорошо, а потом начинаются жизненные «срочно добавьте», «закостыльте для презы», всплывают забытые исключения и все опять по новой.
Переписывать и облагораживать код нужно, но большие куски/модули переписывать нужно очень осторожно, взвешенно и с умом, потому что зачастую несовершенный работающий код написан чьей-то «кровью» и выглядит так убого не то чтобы просто так.
Живой случай в соседней команде: человек пришел, сказал что надо переделывать, под его харизмой переписывать на новом языке начали, а сотрудник ушел через 4 месяца, бросив все, directed by Robert B. Weide.
5. Неумение/нежелание разобраться в чужом коде
Разбираться в чужом коде нового проекта (особенно без документации и помощи от другого сотрудника) — очень муторная штука. Это то, что прям совсем не любят, поэтому зачастую мелкие проблемы решаются авианосной группой.
Например, вместо того, чтобы попытаться все же докопаться до решения и его исправить (например, в текущем скрипте/фреймворке), в проект втаскивается новый фреймворк/библиотека и все переделывается на нем. Причем, трудозатраты могут быть такими же и выше, но лишь бы не копаться, а творить! Все это ок, если это личный проект, но когда на проекте несколько людей или разработка на заказ, то стоит лишний раз об этом подумать.
Новое — часто приносит новые проблемы. Это не плохо, просто всегда нужно понимать стоит ли оно того, если можно все решить текущими средствами.
6. Локализация проблемы при медленной работе
Когда что-то медленно работает, зачастую командой сразу выдвигается рабочая версия почему — ну там же жирный запрос, или много соединений, или кривой модуль — все ж очевидно, давайте его переделаем.
Когда что-то медленно работает — бросаться переделывать без точного диагноза нельзя, нужно углубляться в раскладку ЧТО именно с каким таймингом работает внутри и, набрав некоторые данные, уже делать выводы. Потому что жирный запрос может оказаться большим на вид, но быстроработающим, кривонаписанный модуль может работать идеально, а проблема быть там, куда без микроскопа просто так не залезешь.
7. Покрыть весь проект тестами / документацией
Тесты — штука важная и хорошая, но маниакально тестировать все на свете нет смысла. Точнее, смысл у каждого свой. Для задач с высокой ценой ошибки, критичного функционала и всего, что касается живых денег — да, многоступенчатые тесты обязательны, но покрывать тестами каждую функцию в лендинге — излишне. Тесты требуют своей актуализации, поэтому здесь всегда важен баланс.
Все то же самое справедливо и для документации — открытое апи должно быть хорошо задокументировано, но текстовая (не автоматическая) дока для каждой функции в проекте, где код часто переписывается — о целесообразности такого лишний раз стоит подумать.
8. Технология для всех и каждого
Так как область моей текущей работы — ML и AI, то я часто сталкиваюсь с тем, что от них есть ожидание, что технология решит ВСЕ проблемы во ВСЕХ случаях. Например, прицепив к камере «систему распознавания» можно решить вообще все, что могут решать системы такого класса.
Простой датчик движения и система обнаружения девиантного поведения в кафе — совершенно разные (во всем) системы, первой достаточно просто смены картинки, вторая должна глубоко погрузиться в анализ происходящего. Поэтому нужно сразу понимать под какие задачи и для кого на каком оборудовании мы что-то собираемся делать. Если софт будет работать на не самой мощной черно-белой камере в реальном времени, то это требует совершенно другого подхода, поэтому и подходить к задаче нужно соответствующе.
Выводы про здравый смысл
Конечно же, примеры очень условны и их список можно продлять до бесконечности, но перечислить все возможные стыки интересов с проблемами не было самоцелью. Хотелось на примерах показать, что человеческое взаимодействие на сложных проектах в ИТ — всегда сложное и с кучей сломанных телефонов, поэтому здравый смысл во всех рабочих вопросов жизненно необходим.
Увы, на проектах редко бывает технический менеджмент, способный понимать все нюансы происходящего и правильно раскладывать задачи от всех частей бизнеса. Нам часто неправильно ставят задачи и ставят неправильные задачи по самым разным причинам и с этим просто нужно жить. В идеале — жить хорошо, счастливо и без новомодных выгораний.
Всегда нужно уточнять зачем мы собираемся что-то делать именно так и что мы хотим получить, потому что часто это приводит к более точному пониманию задачи на всех уровнях, а часто и к ее полному переформатированию с последующим снижением стоимости, уменьшением сроков и сохранению нервов всех участников обсуждения.
Хочу пожелать всем продуктивного года, поменьше офисных баталий и больше интересных задач, которые действительно делают мир чуточку лучше.
Спасибо!
Комментарии (60)
LeetCode_Monkey
06.01.2024 10:56+12А нужно ли это айти вот прям здесь?
Бабушка с тетрадкой куда дешевле, а "базу" не растащат хакеры. Пенсионер-вахтёр понимает любую жизненную ситуацию, чего не скажешь про типа самые умные камеры с распознованием лиц и поведения. Продавщица за прилавком и отвесит и пробьёт, и ещё потрындеть с ней можно в процессе, а со всеми этими самообслужками стой разбирайся сам. List goes on and on где айти уже ничего не улучшает, а наоборот ухудшает.
DarkTiger
06.01.2024 10:56+5Было уже здесь, в отличной статье от Крока про камеры на проходной. Бабушка-вахтер относительно неплохо распознает лишь лица своей национальности, а с другими нациями распознавание человеком проигрывает компьютеру фатально. Да и лицо мало просто распознать, надо еще очень быстро извлечь базу из своей памяти, и держать ее актуальной, а с этим огромные проблемы.
anonym0use
06.01.2024 10:56Еще важное отличие бабушки-вахтера в том что она не хранит идеально точную БД биометрических данных и соответствено невозможна утечка этих данных.
LeetCode_Monkey
06.01.2024 10:56, а с другими нациями распознавание человеком проигрывает компьютеру фатально.
У вас негры друг за другом на проходной ходят? О том и речь, не надо пихать айти туда где от него выигрыша особого нет, а вот цена и косяки никуда не деваются. А там где productivity/cost на высоте, там всегда welcome.
DarkTiger
06.01.2024 10:56У вас негры друг за другом на проходной ходят?
Вы где живете, если не секрет? Режимный город вроде Сарова?
Во всех остальных городах недостатка мигрантов не наблюдается.
antipov_dmitry Автор
06.01.2024 10:56Добавлю еще, что как только начинаются добавления к функциональности или усложнении системы, ну, например, не пускать определенных людей, то человеки начинают быстрее проигрывать автоматике.
antipov_dmitry Автор
06.01.2024 10:56Соглашусь со здравомыслием подхода! Все сильно зависит от нюансов и поставленной задачи. Если вы решаете задачу одной конкретной проходной - возможно, пенсионер-вахтер это выход, потому что люди впринципе сходу могут быстро решать целый класс задач и идеально справляться с кучей нештатных ситуаций. Люди это зачастую жирнющий плюс с точки зрения быстроты решения задачи, потому что обрабатывание внештатки в айти часто занимает астрономически много времени, денег и плюс все эти шишки набиваются только со временем.
Но у людей есть критичный недостаток, это плохая их тиражируемость. Как только проходных становится две, три, четыре, десять, сто - тиражировать человеков становится очень больно и сложно, и эта сложность сильно возрастает в зависимости от сложности решаемой функции.
Еще один недостаток - это обстоятельства, которые у человеков могут случаться чаще и менее прогнозируемо, нежели у бездушных железок. Продавщица может заболеть, быть в плохом настроении, list goes on and on, а у кремниевых список более короткий и более прогнозируемый.
Поэтому да, выбор человек или айти - это тоже выбор здравого смысла.
Vitalis83
06.01.2024 10:56Мы тоже прикидывали, что можно добавить какой нить терминал простейший вместо амбарной книги и этого достаточно с головой будет. Но нет консультанты требуют каких новомодных роботов и кучу дорогой работы.
Nurked
06.01.2024 10:56+4Мотильда, дайте этому человеку кружку эля и поставьте плюсов в карму, да побольше! И вызовите карету. Я хочу его видеть на Олимпе!
Я не раз говорил, что одно из определений слова сумашествие это "всё что угодно, доведённое до крайности". Любая вещь, применимая к любой ситуации, применённая без оценки ситуации будет разрушительна.
Здравый смысл - это обратное. Когда вы проводите честную и непредвзятую оценку. Когда вы анализируете текущую картину и внимательно выбирвете инструменты.
Иногда имеет смысл написать всё на чистом HTML без CSS. Иногда нужен реакт с плагинами. Иногда нужна сцепка Postgres + ElasticSearch, а иногда подойдёт дамп текстовых файлов на диск.
LeetCode_Monkey
06.01.2024 10:56+1Иногда имеет смысл написать всё на чистом HTML без CSS. Иногда нужен реакт с плагинами. Иногда нужна сцепка Postgres + ElasticSearch, а иногда подойдёт дамп текстовых файлов на диск.
Так-то оно так, но, к сожалению, нынче без модняцких технологий в резюме, новую работу можно и не найти вовсе. Если будешь всё делать правильно, со "здравым смыслом" - есть риск что делать это будешь в последний раз.
slonopotamus
06.01.2024 10:56+1Вы это рассказываете на базе практического опыта или просто фантазии?
LeetCode_Monkey
06.01.2024 10:56На базе коллективного опыта. По сравнению с 10ыми, поиск новой работы очень сильно изменился не в лучшую сторону.
iggr63
06.01.2024 10:56+1с умением задавать правильные вопросы правильным людям — и есть самый важный навык. Потому что умение остановиться, оценить обстановку и несколько раз задать себе и другим вопрос «зачем?»
Полностью согласен. Однако зачастую вопрос «зачем?» очень опасен. Обычно вызывает трения при разработке комлексных решений в многопрофильной команде. Технический продуктовый менеджмент часто присутствует даже на организационном уровне. Однако зачастую сводится к управлению портфелем продуктов.
antipov_dmitry Автор
06.01.2024 10:56Мне кажется, такие вопросы надо задавать максимально нейтрально, потому что это может неправильно восприниматься как атака на принятое решение. Но если человек не может защитить свою точку зрения двумя последовательными вопросами "зачем", то это не очень хорошо, конечно.
Конструктивные трения это в целом очень полезно, но только если команда умеет не выходить за рамки рабочих обсуждений, чтобы это не превратилось в ругань.
Thomas_Hanniball
06.01.2024 10:56+32Имя ему этому навыку — здравый смысл.Главный навык сотрудника — это лояльность, а не здравый смысл.
Если сказать руководству, что его новое решение не совсем оптимально или что оно лишено здравого смысла и его лучше отменить совсем, то это даёт минус 100 очков к лояльности и с большой вероятностью приведёт к поиску новой работы для смельчака.
К сожалению, здравый смысл не всегда помогает принимать нужные решения, так как вес и приоритет задачи зависит от высоты занимаемого поста человека, а не от пользы решения для компании или от здравого смысла.
Если не подвергать критике плохие решения руководства, а просто воплощать их в жизнь, то можно получить плюс 200 очков к лояльности, бонус за успешно выполненный проект и возможность повышения в должности и зарплате.
P.S. Да, я тот самый смельчак, который не боялся беседовать с директорами компаний и показывать, как их неоптимальные решения надо изменить, чтобы они начали приносить больше пользы компании, а не вред. После ухода из нескольких компаний я прокачал навыки: «перестать
насаждать добро», «перестать давать непрошенные советы», скрытность» и «лояльность». Теперь меня все любят, считают классным специалистом и хорошо оплачивают мой труд. А всё своё свободное время я теперь трачу на себя и свои интересы, а не на то, чтобы сделать компанию лучше.antipov_dmitry Автор
06.01.2024 10:56+6Спасибо, лайк поставил, дополнение шикарное! Но я с ним соглашусь частично. Частично, потому что лояльность - по мне лишь одна из веток здравого смысла. Люди все очень разные, в том числе те самые принимающие решение директора: кто-то из них залетный карьерист, кто-то радеет за дело, поэтому каждый отреагирует на критику (почему именно - критику?) совершенно по разному.
И слово "критика" само по себе подразумевает начинающийся конфликт. К сожалению, многие решения кажутся неоптимальными именно с высоты своего полета, а на другом уровне выше есть много дополнительных вводных, которые могут перевернуть понимание о принятом решении. Если эти вводные не знать, в них разобраться попыток не делать, а диалог начать с открытия двери ногой (на созвоне в 100 человек, например) и фразы "тут все г%вно", то все точно пойдет по тому пути, что вы описали. Возможно, люди воспринимают предложения "насаждения добра" именно потому, что оно подается не так или есть вводные, которые не нужно знать другим сотрудникам. Мир и люди - сложные.
Но точно могу сказать, что не все директора - говнюки, не все - принимают неудачные решения, и не все из них остро реагируют на предложения, если подать их правильно. Поэтому если случай клинический (они есть, не спорю), то лояльность это выход. Но если ваш грейд позволяет общаться с принимающими решения людьми, то зачастую все не так плохо и на все можно повлиять, понять, обсудить и что-то предложить. Адекватные боссы на адекватный диалог реагируют нормально, в конце концов, это и есть то самое искусство управления людьми, никого не хочу в этом убеждать, но у меня всю жизнь было именно так.
Плюс абсолютная лояльность это все же не для всех, быть лояльным к неудачным решениям - это тоже особенный навык, который есть далеко не у всех. Поэтому если лояльность это оптимальное решение в данной ситуации, и она не вызывает отторжения, то да, это выход и надо делать работку и получать удовольствие от всего процесса.
iggr63
06.01.2024 10:56+1Безусловно лояльность это вот наше все. Обычно она относится к компании, но каждый руководитель ассоциирует себя именно с компанией. Со всеми вытекающими.
conopus
06.01.2024 10:56+2Тот случай, когда комментарий дороже статьи. Я бы, правда, сузил с "сотрудника", до наемного работника.
sv91
06.01.2024 10:56Но не все так просто. Иногда бывает, что начальник - дурак, но в команде кроме тебя есть и другие коллеги, которые тоже не согласны с его мнением. Или твой непосредственный начальник - дурак, но выше него в иерархии есть вроде более вменяемый начальник. Или есть 2 начальника из двух смежных отделов, которые взаимодействуют друг с другом (например, в плане API), и подход смежного начальника тебе больше нравится. И вот так сидишь, и думаешь, примкнуть к злой стороне или всеже доброй.
antipov_dmitry Автор
06.01.2024 10:56В больших структурах такое сплошь и рядом, и когда в очередной раз будет пересмотр эффективности работы всей цепочки, то безудержная лояльность даже к неудачным решениям может закончиться не очень хорошо.
Поэтому да, все сложно, и нужно индивидуально понимать насколько договорибельно руководство в целом, и уже в конкретных обстоятельствах принимать какое-то решение.
sv91
06.01.2024 10:56Да не только в больших структурах. Во всех компаниях так.
И тут возникает вопрос, как обратить внимание на свои замечания, которые вполне могут оказаться похороненными под руководством
DimaIgrotech
06.01.2024 10:56+2Живой случай в соседней команде: человек пришел, сказал что надо переделывать, под его харизмой переписывать на новом языке начали, а сотрудник ушел через 4 месяца, бросив все, directed by Robert B. Weide.
Ух жиза. Даже на секунду подумал, что где-то рядом трудимся.
antipov_dmitry Автор
06.01.2024 10:56К сожалению да, ситуация не то чтобы прям сильно уникальная ????
LedIndicator
06.01.2024 10:56+3Давайте сразу с места в карьер: за 16 лет в индустрии я повидал изнутри несколько сотен самых разных проектов и команд
Считаем, что в шестнадцати годах 5844 дня. Несколько, ну пусть будет по минимуму — две сотни, хотя «несколько» обычно подразумевает больше. Делим дни на две сотни проектов команд, получаем 29 примерно дней на один проект. Без учёта отпусков, больничных, праздников, форс-мажоров и пр. А так меньше, конечно.
Для фрилансера, чёт подмандить по-бырому, вероятно, такой бэкграунд норм, но для более-менее сложного продукта — несерьёзно.
В общем, я сомневаюсь, что проскакав подобным образом всю карьеру по проектам вы можете давать такого рода философские советы.
То есть, советы давать, конечно, можно, но авторитет их автора, прямо скажем, сомнителен.
sovaz1997
06.01.2024 10:56Что-то очень легко вы оценили опыт автора. Я бы не стал делать какие-либо выводы, узнав о цифре в 16 лет и сотнях проектах. Да ещё и настолько упростив это - тупо поделив. Откуда вы знаете, может, один проект был на 8 лет к примеру, а остальные сотни - оставшиеся 8. Да и всё равно это всего лишь цифры.
Newbilius
06.01.2024 10:56+1Т.е. на остальные проекты вообще тратились единицы дней? Нет, у меня тоже есть опыт конвейерного производства сайтов-визиток за 2-3 дня, но опыт этот специфичный.
Captain_Jack
06.01.2024 10:56Бывает, что работаешь и смотришь не только в свою команду, но и в 5-10 соседних, и тоже получаешь с этого опыт - кто кого нанял и как, какие решения принимались и как, какой был менеджмент, как была организована работа и так далее. Тем более если быть кем-то типа деливери менеджера, там точно придётся погружаться в разные команды и помогать чинить процессы.
Конечно, будучи в роли мидла-разработчика так широко редко получается видеть, но у людей же разные роли. Допустим можно быть в архитектурном комитете, это тоже даёт много опыта от других команд: сначала видишь проблему и их идею, потом узнаешь как прошла реализация и что получилось, какие всплыли косяки.
О сотнях автор может быть преувеличивает (а может быть и нет), но кажется мысль статьи не в этом, и можно просто принять оценочное суждение автора.
sovaz1997
06.01.2024 10:56У меня претензия была к тому, что был сделан вывод об опыте автора на основании 2-х цифр (16 лет опыта и сотни проектов). А так не надо делать. Это упрощение и навешивание ярлыков чаще приводит к ошибочным выводам. Слишком мало данных для вывода. А Вы зачем-то продолжаете строить выводы на основании этих 2-х цифр.
antipov_dmitry Автор
06.01.2024 10:56Так мир ведь он вот какой простой, видишь две цифры - дели одну на другую и беги скорей делать выводы ????
Вот у человека -19 карма и 98 комментариев, значит он -0.19 получает за каждый комментарий. То есть, комментарии давать, конечно, можно, но авторитет их автора, прямо скажем, сомнителен.
antipov_dmitry Автор
06.01.2024 10:56Спасибо за провокационный комментарий. Статья - ровно об этом: математика - ок, но предпосылки к ней изначально были неверные, поэтому ее можно было не делать. Я нигде не писал, что это были МОИ проекты, или что я в них полноценно участвовал, более того, я на это никоим образом не претендую. Я имел ввиду только то, что и так было написано буквами - я повидал устройство изнутри множества команд.
Это дословно означает, что я знаю их состав, стек, инфру, подход к разработке и их проект на уровне продвинутого пользователя (где-то глубже, где-то поверхностнее). Когда ты большую часть рабочей жизни делаешь коробочный софт и встраиваемые сервисы для разработчиков, то частью работы становятся попытки разобраться кто, зачем, как и почему использует этот софт и как в итоге его потом затаскивать в контур заказчика.
Поэтому (как уже писали ниже) выдернуть две цифры и поделить одно на другое и сделать выводы - так себе история. Больших и очень сложных проектов с полноценным участием у меня было штук 10, а работку я менял всего 6 раз за все время, нигде не работая меньше года, поэтому ни о каких скаканиях речи быть не может.
"Garbage in, garbage out" - во всей его красе.
VitalyZaborov
06.01.2024 10:56Так хорошие же советы и рассуждения правильные. Тоже подпишусь под каждым абзацем.
А десятки проектов могут идти параллельно если автор ими руководит или менторит.
HEXFFFFFFFF
06.01.2024 10:56+5Я много лет руковожу разработкой. Так вот суть статьи, это мой главный лозунг в работе. Я постоянно всем это говорю: "Не надо откладывать на завтра то что можно не делать вообще". Именно этот подход дает возможность работать на порядок более эффективно!
Thomas_Hanniball
06.01.2024 10:56+1У меня принцип похожий, только он звучит: "Чем проще, тем лучше". Это позволяет делать минимальное количество действий, чтобы добиться нужного результата без лишних переусложнений.
Второй принцип - это "Правило 20 на 80". 20% усилий\задач приносят 80% результата, поэтому вначале выполняются именно такие задачи, а если остаётся время, то берутся другие задачи, чтобы закрыть оставшиеся 20% результата.
antipov_dmitry Автор
06.01.2024 10:56Подход "чем проще, тем лучше" - полностью справедливый. Единственное, у него часто есть сложность в определении до какого уровня "проще" можно опуститься, чтобы потом не найти проблем с архитектурой, кибербезами и не скатиться в откровенный говнокод ????
antipov_dmitry Автор
06.01.2024 10:56Спасибо. Как говорится, "если тикету уже больше года, и за ним никто не пришел, может быть он и не так нужен?" ????
appet1te
06.01.2024 10:56+2Думаю, что автор описывает мышление. Качественное, системное, структурное, открытое, критическое мышление. С широкой "мыслительной рамкой"(это как я это называю), мыслительная рамка вдаль это будущее, думать на несколько шагов вперед. Мыслительная рамка вширь это на несколько людей/отделов рядом собой. Не только на себя. Обыватель мыслит 1 на 0(только на себя и прямо сейчас). При разработке сложного абстрактного продукта, всем членам команды придется мыслить пошире и вдаль хотя бы на пару шагов.
Вспоминается Эдвард де Боно с его работами по мышлению.antipov_dmitry Автор
06.01.2024 10:56Спасибо за интересный термин (и ваши статьи)! Да, чем больше занимаюсь технологиями, тем сильнее понимаю, что мыслительная рамка вширь и вдаль, подумать и вперед и за других людей, это не менее важно, чем конкретное принятие решений исходя из просто технического опыта.
nronnie
06.01.2024 10:56+3часто случается большой стереотип о том, что есть один проверенный способ чтобы все сделать сразу как надо.
У меня есть другой стереотип, сложившийся из личного (тоже больше 15 лет) опыта - всякий раз, когда я слышу: "сделаем сейчас как не надо (потому что нет времени/денег/людей и т.п.), а потом, вот, придет время, и переделаем нормально", то я уже сразу знаю что это "время", на самом деле, никогда не придет.
antipov_dmitry Автор
06.01.2024 10:56Как правило, это правда. Но тут тоже часто нельзя давать советов по интернету, потому что все сильно зависит от конкретных условий, да и вопрос немного философский, потому что в ситуации нет времени/денег/людей, вариабельностей итоговых действий не сказать, что очень высока.
svartberg
06.01.2024 10:56А кем вы работали, что меняли проекты каждый месяц? (несколько сотен за 16 лет.. если принять несколько сотен за 200 то каждый месяц новый проект)
antipov_dmitry Автор
06.01.2024 10:56А я их не менял, об этом не писал и на это не претендую. Я делал несколько больших проектов, часть из которых имели специфику, требующих прямого погружения (где-то глубже, где-то проще) во внутрянку других сторонних проектов и их команд.
klaviature
06.01.2024 10:56Блин. На Хабре сижу всего ничего (около недельки, если не меньше) и поражаюсь - какие хорошие люди с интересными мыслями тут сидят. Спасибо вам и автору за то, что вы делаете. И создателям самого хабра тоже спасибо, что собрали всех этих людей вместе, в одном месте. P.S Извините за оффтоп
OlgaVivanova
06.01.2024 10:56Здравый смысл основан на жизненном опыте.
Если честность, вопросы о цели, инновации и признание ошибок приводили руководителя к потере работы и репутации успешного лидера, а обратное приносило хорошую зарплату и власть годами, то его здравый смысл подсказывает делать это обратное.
Фраза-маркер "у нас стабильность" и "делай что скажут" / "все мы делаем, что нам говорят" - хороший показатель, что руководство не ориентировано на нововведения и будет их блокировать.
Как правило, за этими фразами в "инновационном активно развивающемся бизнесе" скрыты очень некрасивые истории(
codingtruth
06.01.2024 10:56Главная проблема таких утверждений, что их можно поменять на противоположные 8 штук :) в зависимости от отсутствия той или иной компетенции - как то неумение ставить задачи, координировать, мотивировать, налаживать коммуникацию, проводить технические совещания... - и сформулировать противоположные 8 принципов так, что тоже будет про здравый смысл, но с переложенной на кого-то другого ответственностью ;)
Да, реальность такая, что в основном болото и стагнация, и правила поэтому те же - как не утонуть в болоте. Но главное, может быть, другое - активно искать себе "братьев по разуму:)" и формировать окружение с близкими по духу носителями здравого смысла, не пренебрегать поддержанием таких контактов.
musical_bee
06.01.2024 10:56Спасибо за статью, а в особенности, за подкрепление основных тезисов генеративными котиками :)
От себя хотел бы добавить, что, как уже кто-то выше заметил, ваш «здравый смысл» очень похож на soft-skill «Критическое мышление». И, я в этом с вами полностью согласен, это самый ключевой навык любого профессионала.
В своей практике управления разработчиками я всегда начинаю погружение в софт-скиллы с более простой формы, которую называю «Навык сомневаться»:
– Сомневаться в своих убеждениям (Правильно ли я понимаю, что...?)
– Сомневаться в корректности поставленной задачи (Какого результата требуется достичь, оптимальным ли путем мы пытаемся до него дойти?)
– ... в оценке трудозатрат (Хватит ли времени на выполнение задания, если твой подход не сработает? Стоит ли заложить небольшой буфер на исследование вначале и на багфикс в конце?)
и т.д.Обычно, уже этого оказывается достаточно, чтобы слегка расшевелить молодых и горячих разработчиков, немного затормозить темпераментных и прорывных визионеров от продукта и основательно приземлить клиентский отдел.
Но, в более широком смысле, этот навык – это лишь один из кусочков пазла, который плохо работает без поддержки навыков коммуникации, эмпатии, лидерства и креативного мышления.
Основной вопрос, который меня мучает уже продолжительное время – как повлиять на развитие гибких навыков в ИТ в широком смысле и как прокачать их у конкретного человека или небольшой группы людей?
Algrinn
Всё хотят переписать только джуны, которые раньше никогда не переписывали чудо-код с поддержкой всего старого функционала и всех странных фич. После того, как им разок скажут: "Окей, делай ветку и переписывай", через месяца два оказывается, что на самом деле они ничего не хотят переписывать. Отдельный вопрос перепроектирование всей системы, но это крайне сложный для согласования процесс. Особенно когда люди живут в мире своих иллюзий и фантазий и выводить их оттуда крайне небезопасно для команды. Потому что психушка начнётся. А так она всё равно начнётся, только позже.
iggr63
Правильно конечно. Однако такая штука как рефакторинг, особенно в контексте всей системы, все же полезна. И да, дается джунам чтобы заодно изучили что и как, и занимает до года, и несколько тысяч коммитов.
antipov_dmitry Автор
Ну рефакторинг тоже бывает разным, можно понемногу переписывать все, а можно рубануть с плеча и влезать в ядро надо прям сильно сознательно и джунов туда лучше не пускать. А вот что-то малокритичное дать джуну с последующим надзором - милое дело.
nronnie
К сожалению, чаще всего, "понемногу" совершенно невозможно (потому что настолько всё запущено + околонулевое покрытие тестами). И выход это только мириться с тем что есть. И молиться чтобы оно поскорее окончательно вагиной накрылось :)
Viacheslav01
Вроде не джун, а временами беру и переписываю, т.к. поддержать левиафана живым гораздо сложнее, а отрефакторить из за дефектов в самом ядре невозможно.
Все зависист от конкретных обстоятельст, а не от принципа, переписывают джуны, а все кто выше читают, разбираются, поддерживают и рефакторят.
antipov_dmitry Автор
Переписывать код - нужно. Поставлю лайк, потому главная идея "все зависит от конкретных обстоятельств" - это ровно то, что я и пытался донести написанным текстом.
astenix
Не только джуны.
Я сравнительно недавно зашел в новый проект и почти сразу заорал о том, что всё неправильно и надо начать делать правильно.
Позже задумался о том, почему всё так ужасно и всем больно, но народ продолжает делать одно и то же. Осмотрелся и понял, что да, таки надо всё перепродумывать, но при этом не надо ломать хрупкий баланс, потому что [дальше детали реализации].
Оказывается, никто не дурак и не злой, просто другие подходы оказались неработающими, и под ковром у проекта огромная история множества попыток сделать иначе…
Algrinn
Не надо переписывать. Скорей всего аналитик там провёл плохой анализ, архитектор сделал плохую архитектуру, а Софью Андреевну заставили 7 раз переписать 3 тома Война и Мир под диктовку Льва Толстого. Кто не знает, это выдающаяся женщина, которая всю жизнь всё переписывала под диктовку, родила 12 детей, а в конце жизни пошла неуспешно топиться. Вот такая вот атмосфера бреда скорей всего на проекте. Весь анализ там нужно проводить в письменном виде на форумном движке. И запретить проводить митинги.
nronnie
..., а просто всем похер.
antipov_dmitry Автор
Спасибо! Именно эту идею мне хотелось донести. Иногда у проекта бывает масса неочевидных нюансов, которые проявляются только со временем или в процессе обдумывания того самого идеального решения [о котором, скорее всего, уже думали и которое скорее всего вот так легко сразу не взлетит].
antipov_dmitry Автор
С джунами соглашусь, но по мне такое желание все же бывает не только у них. Иногда людям действительно удается переписать что-то сложное без больших последствий, что создает прецедент (на всю команду причем) того, что оно и дальше так прокатит. И оно, кстати, может и дальше прокатит и всем действительно станет лучше.
Моя идея была попытаться донести, что такие решения должны приниматься только с человеком, который знает предметную область, а в идеале и сильно участвовал в написании этого кода, человеком глубоко изнутри, а не кем-то снаружи, каким бы звездным он ни был.
А если попытаться перефразировать, то переписывать сложный код - нужно, но только в том случае, если это сознательный вариант, а альтернатива - еще хуже. А вот правильно оценить альтернативу - это уже наука, причем у каждого своя.