"Идеальный" менеджер - срет где попало и орет.
16.06.2021, 08:53
Посмотрел рабочие чаты, от всех руководителей один вопрос "Как успехи?"
О, вот ты где. Как успехи?
Прилетает к тебе, когда ты в состоянии потока, в которое входил 3 часа и сейчас пишешь модуль, на котором будет держаться весь проект, из-за чего его структура содержит столько деталей, параметров, методов и подклассов с документациец, что, кроме как в состоянии потока, его больше писать никак нельзя, и начинает на тебя "Как дела? Как проект? Когда сдаём? Мне не нравится твой взгляд. На обед идёшь? Футбол вчера смотрел? Как же меня достали дети.", что моментально выводит тебя из себя, а про состояние потока можно забыть на весь остаток рабочего дня.
За такую архитектуру надо пиздить, если без наркотиков в ней не разобраться
Справедливо
Мне лично всегда казалось, что именно так делается всё самое сложное и крутое.
Я не программист, но ебашил по работе в excel как не в себя. Я почти полностью автоматизировал саму работу аналитики в таблице экселя с отчётами "каждую неделю", путём создания одного листа с ахуенно длинными формулами, которые на что-то там ссылаются и так далее. Каждая формула в длинну на 3-4 строки ввода формул. По 10 махинаций внутри неё. Со всеми возможными ошибками в данных и исключениями. И чтобы сделать свою работу мне было достаточно потом лишь скопировать новые данные, вставить их и в новой копии макета выставить другое число месяца и недели. Всё. Дальше он все графики и таблицы подтягивал автоматически. И если кто угодно посмотрит на эти ячейки вывода - он нихуя не поймёт. Зато вместо часа-двух работы моего предшественника, мне хватало 5 минут.
Я не программист, но ебашил по работе в excel как не в себя. Я почти полностью автоматизировал саму работу аналитики в таблице экселя с отчётами "каждую неделю", путём создания одного листа с ахуенно длинными формулами, которые на что-то там ссылаются и так далее. Каждая формула в длинну на 3-4 строки ввода формул. По 10 махинаций внутри неё. Со всеми возможными ошибками в данных и исключениями. И чтобы сделать свою работу мне было достаточно потом лишь скопировать новые данные, вставить их и в новой копии макета выставить другое число месяца и недели. Всё. Дальше он все графики и таблицы подтягивал автоматически. И если кто угодно посмотрит на эти ячейки вывода - он нихуя не поймёт. Зато вместо часа-двух работы моего предшественника, мне хватало 5 минут.
Ну, я не считаю, что сложность - это хорошо. Сложные вещи можно описать простыми словами, и это как раз непростая задача.
Касательно твоего примера: ты решил свою проблему с помощью автоматизации. Это прекрасно. Но вот представим, что твоя работа и есть автоматизация. Если добавлять в твои расчёты новые данные, новые ошибки и исключения? А потом расширить форматы отчётов: еженедельные, с нарастающим итогом, отчёты только по определённым категориям и т.д. Было бы лучше разбить длинные формулы на короткие блоки, которые бы использовались при необходимости.
Как сказали выше, так тебя не уволят. Зато есть большой риск запороть проект. Человек не будет разбирать модуль, а, скорее всего, прикрутит к нему ещё один модуль, который будет решать конкретно его задачу. Так программа будет охуенно расти в размерах и работать всё хуже. Мелкие изменения и отслеживание ошибок будут занимать всё больше времени. Кроме того, разработчики же увольняются. Вот и представь такую программу, которую уже лет 10 поддерживают и дорабатывают, только сначала не позаботились об архитектуре: людей нанимают на большие бабки, чтобы они разобрались во всём и переписали заново. Хотя чаще нанимают студентов, чтобы они плакали над говнокодом горючими слезами и крутили надстойки, пока фирма наконец не забьёт на этого монстра и не похоронит его.
Касательно твоего примера: ты решил свою проблему с помощью автоматизации. Это прекрасно. Но вот представим, что твоя работа и есть автоматизация. Если добавлять в твои расчёты новые данные, новые ошибки и исключения? А потом расширить форматы отчётов: еженедельные, с нарастающим итогом, отчёты только по определённым категориям и т.д. Было бы лучше разбить длинные формулы на короткие блоки, которые бы использовались при необходимости.
Как сказали выше, так тебя не уволят. Зато есть большой риск запороть проект. Человек не будет разбирать модуль, а, скорее всего, прикрутит к нему ещё один модуль, который будет решать конкретно его задачу. Так программа будет охуенно расти в размерах и работать всё хуже. Мелкие изменения и отслеживание ошибок будут занимать всё больше времени. Кроме того, разработчики же увольняются. Вот и представь такую программу, которую уже лет 10 поддерживают и дорабатывают, только сначала не позаботились об архитектуре: людей нанимают на большие бабки, чтобы они разобрались во всём и переписали заново. Хотя чаще нанимают студентов, чтобы они плакали над говнокодом горючими слезами и крутили надстойки, пока фирма наконец не забьёт на этого монстра и не похоронит его.
Сказка девопёсововская.
Жила-была богатая контора с арендованными стойками в ЦОДах и 3 средами разработки на все команды: дев, препрод и прод. Поскольку препрод от прода отличался только парой моков, то там особо не подебажить, а конфликты между командами разруливались тестировщиками в формате "не нажимать деплой до стольки-то или я убью твою собаку". Поскольку бюджет на инфраструктуру с сильным запасом, решают нанять девопёса разобраться.
Мессия курит полтора месяца как и что у них работает и выдаёт: поскольку никакой контейнерной магии вашим самописным системам не светит, то придётся пилить образы для виртуалок с их клонированием, тем более ваш гипервизор_name умеет это бесплатно и оптимальным способом. Вот вам ТЗ с планом работ для всех соучастников и требованиями к пилотному проекту, для переключения разработки туда достаточно просто выделить мощностей. Несмотря на все "это невозможно" от разработчиков, через месяц образовались базовые образы и процесс их обновления, ещё через 2 автоматизировали процесс наката ПО, ещё через 3 оно прошло end-to-end тесты и было отложено на квартал до перевода в бой дабы бизнес-фичи пропихнуть.
Параллельно пилилась новая система с таким же дедлайном, только там всем светил прямой выход на мороз. Несмотря на напоминания о том, что их ждёт такой же процесс и нужна документация всех действий по натягиванию совы на прод, как через месяц, так и через полгода разрабы не смогли запустить в новой среде своё чудо, и поэтому проект по переводу всех на изолированные среды разработки был отменём.
А разгадка одна - безблагодатность.
Жила-была богатая контора с арендованными стойками в ЦОДах и 3 средами разработки на все команды: дев, препрод и прод. Поскольку препрод от прода отличался только парой моков, то там особо не подебажить, а конфликты между командами разруливались тестировщиками в формате "не нажимать деплой до стольки-то или я убью твою собаку". Поскольку бюджет на инфраструктуру с сильным запасом, решают нанять девопёса разобраться.
Мессия курит полтора месяца как и что у них работает и выдаёт: поскольку никакой контейнерной магии вашим самописным системам не светит, то придётся пилить образы для виртуалок с их клонированием, тем более ваш гипервизор_name умеет это бесплатно и оптимальным способом. Вот вам ТЗ с планом работ для всех соучастников и требованиями к пилотному проекту, для переключения разработки туда достаточно просто выделить мощностей. Несмотря на все "это невозможно" от разработчиков, через месяц образовались базовые образы и процесс их обновления, ещё через 2 автоматизировали процесс наката ПО, ещё через 3 оно прошло end-to-end тесты и было отложено на квартал до перевода в бой дабы бизнес-фичи пропихнуть.
Параллельно пилилась новая система с таким же дедлайном, только там всем светил прямой выход на мороз. Несмотря на напоминания о том, что их ждёт такой же процесс и нужна документация всех действий по натягиванию совы на прод, как через месяц, так и через полгода разрабы не смогли запустить в новой среде своё чудо, и поэтому проект по переводу всех на изолированные среды разработки был отменём.
А разгадка одна - безблагодатность.
спасибо за перевод
