Комментарии 79
Слушайте, ну это же очевидно. Чем меньше разработчика дергают на всякие встречи, созвоны, совещания и бог знает на что еще, тем разработчик продуктивней, качество кода однозначно растет, решения, принимаемые в процессе разработки, взвешеннее и логичнее. Сколько можно мусолить одно и то же. Главная задача менеджера не пальцы растопыривать, а обеспечивать спокойную рабочую обстановку. С техническими проблемами разработчики сами прекрасно разберутся.
Всё бесполезно. Порою им просто хочется поболтать или что-то рассказать, когда у них, казалось бы, появляется минутка, и тут начинается вот это самое, типа: ой, а можно я тебе расскажу о... , или как на картинке: найдётся пару секунд для... Ну или у них внезапно возникла идея, и им нужно экспертное мнение, или иная информация.
с одной стороны да... но если посмотреть на митинги как на отдых? Поработал пару часов - митинг, пицца, кофе, отдыхаешь, набираешься сил... Главное научиться отдыхать на митингах. На митинге на удаленке я иногда рюмку коньяка мог пропустить (доклад CEO на тему "все хорошо, прекрасная Маркиза!" - все равно от разработчиков требовалось только присутствие послушать высокородных с трибуны).
А вот работа над тикетами в разных проектах меня вымораживала больше - нужно хорошо обдумать изменения и тебя раз и дергают на что то в другой проект. Три разных проекта глянуть в течении дня раздражает неимоверно.
Не знаю, я для отдыха лучше посижу в тишине (или в телефоне), чем это. Митинги – это иллюзия отдыха. Казалось бы, присутствовал на встрече = работал, а нет. Это как в школе во время контрольной зашел директор сообщить новости и все обрадовались, что контрольной не будет, а на самом деле она будет, только теперь на 15 минут меньше времени на решение.
Понимаю, что надо себя перенастраивать, чтобы относиться как вы, но как-будто это костыль, а не решение)
Это работает если на удаленке. Вживую на митинге конечно не расслабишься
Ну если от тебя требуется участие в дискуссии или использование сказанного в дальнейшей работе, то сильно больше и не расслабишься тоже, а таких митингов все же большинство у разработчиков по крайней мере, ну если процесс правильно выстроен (ну и их в принципе не очень много).
Тогда это рабочий, а не пустой митинг. Можно их делать по расписанию либо уходить в проект с меньшим количеством людей.
У меня был проект, к примеру, на 90 модулей примерно - пилил его в одиночку, иногда выделяли помощников, кто свободный. Хватало нормальное покрытие тестами делать.
Соседний базовый проект примерно 12 человек превратили в спагетти свалку.
Когда прибегали тестеры с криками "у тебя ошибка" - как правило ошибка была в базовом проекте.
Причина?
Ни одного рефакторинга в течении 10 лет (до смерти проекта).
Плохое управление кодом (ревью не успевали).
Нет покрытия тестами потому что 1 в том числе. - сразу не сделали а потом поздно, слишком дорого.
И ничего, начальство вваливало ресурсы именно в гавнямбу. Более того меня сократили (с кодом легко разобраться) а владельца гавнямбы оставили (кроме него в этом лабиринте никто не мог и не хотел разбираться).
Вот и думай, хорошо ли писать код понятным для других или лучше понятным только для себя
Тогда это рабочий, а не пустой митинг. Можно их делать по расписанию либо уходить в проект с меньшим количеством людей.
Не очень понимаю зачем делать нерабочие митинги тогда для разрабов, ну помимо общекорпоративных каких то собраний пару раз в год, или обучения точечного (что является все же частью работы).
А про код да, тоже знал человека который один над кодом сидел и разбирался строго только он один. В итоге начал шантажировать увольнением ИЧСХ выбил себе повышение через это.
но если посмотреть на митинги как на отдых
Обычно митинг никто не учитывает как работу. Это так, на обсудить вопрос, а сроки двигать никто не хочет, так что не сильно отдыхается на разговоре когда работы много а от говорения толку 0.
Это не отдых, а смена типа нагрузки - вместо глубокой концентрации поверхностное внимание и социальное взаимодействие - это тоже утомляет просто по другому. После 3-4 часов совещаний чувствуешь себя выжатым как лимон, хотя ничего не делал
Если нужность разработчика достаточно очевидна, то свою нужность менеджерам приходится доказывать. Проще всего организуя совещания. Чем больше сотрудников удастся на них затащить, тем больше их будет осведомлено о важности работы этого менеджера. У самых бесполезных вообще нет другого способа.
Команда посредственных разработчиков с хорошим менеджером сделает продукт, хотя он и будет далеко не идеален.
Команда хороших разработчиков с плохим менеджером скорее всего не сделает ничего, только сожжет время и бюджет (если только менеджерские функции не возьмёт на себя неформально кто-то другой).
Как менеджер выросший из разработчика хочу сказать, что тут есть одно заблуждение.
Вы предположили, что задача разработчика только писать код и ничего больше. Это не всегда так.
В компаниях с большой кодовой базой зачастую надо еще понимать, когда код писать надо, а когда вообще не надо.
Например, опытный разработчик на совещании зачастую может сэкономить сотни часов на разработку, объяснив почему это вообще делать не надо или как адаптировать прошлое решение. А без этих знаний разработку нормально даже не запланировать.
Или надо продумать решение с учетом различной архитектуры. И это тоже важная и сложная глубокая работа, в которой будет несколько участников. То есть это тоже совещание.
PS
Я в целом то согласен, что после того, задача проработана надо не мешать ее решать. Но зачастую, чтобы ее проработать и запланировать, без созвонов никак.
Проблема в том, что у многих менеджеров KPI завязаны на активности: количество совещаний, отчетов, синхронизаций. Их система поощряет за создание шума, а не за обеспечение тишины
Проблема заключается в том, что есть огромный разрыв между тем, как совещания воспринимают менеджеры и разработчики.
На самом деле, должно быть так: «есть огромный разрыв между тем, как совещания воспринимают те, кто только создаёт видимость работы, и те, кто действительно работает.» Менеджер, который работает, а не просто выполняет идиотский KPI, не будет почём зря дёргать всех вокруг каждые два часа.
в общем верно, имитация бурной деятельности только мешает.
Менеджер, который работает, а не просто выполняет идиотский KPI
Таковые наверняка занесены в Красную Книгу, ибо вживую я их не встречал.
Их, конечно, мало, из-за обязательного отрицательного отбора среди менеджеров в крупных компаниях, но вообще такие бывают.
Вспомнился один технический директор... В целом, мне на руководство везло (наверное потому что компании были маленькие). Но тут раскрутился наконец то стартап, пошли нормальные деньги и началось дерьмо. Владельцы улетели на Багамы (лет на 5), те кто пахали, остались пахать (зарплату накинули), зато пришел целый косяк начальства, включая техдира. Он был абсолютно дубовый. Если CEO и выше тихо пилили свои зарплаты и рисовали графики как все хорошо идет, то этот просто заморозил любые улучшения и вообще изменения в техпроцессах. Это можно себе позволить только если сидишь на гарантированных заказах (госах) или слишком большой чтобы падать.
Заморозка сказалась позже, когда компания в итоге крякнулась, потеряв активное ядро сотрудников.
Выросшие из разработчиков бывают адекватные вполне, понимающие (особенно выросшие не совсем по своей воле) :)
как говорится, прусская школа - чтобы стать офицером, нужно побыть рядовым. Когда то в 90е, присматривал себе небольшой ресторанчик плюс пивная в Чехии, и на полном серьезе собирался пройти путь от посудомойки. Ресторан не получился (увы), но как наливать пиво и делать кофе, освоил. По крайней мере знаю как налить с пеной и без пены и сделать лате в стеклянном бокале чтобы слой молока был отделен от кофе. Самое главное, понял как работает кухня, куда прячут деликатесы чтобы сожрать после закрытия и тд, мотивация и контр мотивация тоже хорошо усваивается на своей шкуре.
И не сложно после такого в IT? :) Или наоборот, мотивирует?
Полгода пил пиво и попутно сортировал компьютеры (разборка) - нет, не сложно когда еще в школе в радиокружке радио86рк собирали и программы набивали в машинном коде из журнала Радио :-),. Перед этим был стартап типография (пока учился) - вот это было сложно - из 4х нас осталось двое (целых). Наезды, попытки отжать бизнес, посадка конкурентов, они тебя тоже или посадить или укантропопить не прочь - это сложно. А IT это развлечение - сиди себе, пили код, платят достаточно чтоб не голодать... Спокойная работа. Легче чем наукой заниматься и опасности ноль. У меня как то на заводе коротнула точечная сварка и выбило предохранитель на 30КА - на память остались очки нашпигованные медью... А в IT сервера не взрываются.
Замеры заново открывают то, что у Брукса написано "Мифическим человеке-месяце" в 1975 году?
Эта проблема не решилась с появлением ИИ-помощников в кодинге; напротив, она усугубилась, потому что менеджеры теперь считают, что разработчики могут быть продуктивными в меньших временных интервалах.
Как будто бы ИИ делает нас продуктивнее...
А проверять за ним кто будет?
Код который я мог написать за час, нейросетка пишет за пару минут. Вот только потом ещё пару часов это всё допиливать чтоб хотя бы заработало... Я уж не говорю о том как это всё поддерживать))
Про "потом поддерживать" - в точку! Мне как-то надо был скриптик написать, но переключаться и вспоминать как там что в powershell делается, мне не хотелось. Решил чере ИИ. Написал подробно и точно что хочу, и через десяток доработок получил рабочий вариант, учитывающий все хотелки. Код я мельком глянул, криминала не увидел. А вот потом понадобилось добавить функционал - и я понимаю, что если бы я сам это писал, то такая доработка заняла бы ну минут 5. Но я код не знал и не вникал как там что реализовано, пришлось в том же чате продолжить и попросить добавить новую фичу. Естественно, понадобилось опять несколько итераций, чтобы получить что надо и баги устранить. Заняло это не менее полчаса. К тому времени я уже и сам к коду присмотрелся, и дальше решил что мне проще и быстрее сразу как надо самому поправить, чем описывать задачу для ИИ.
Промпт не промпт, но в "человеческом" мире меня с некоторых пор начала забавлять ситуация, когда ТЗ по объёму превосходит сделанный на основе него код. Поэтому, мне кажется, в реальной жизни "качественные ТЗ" и встречаются настолько редко, что все о них слышали, но мало кто видел.
А что такое "качественное ТЗ"? То, которое можно отдать разработчику, оставить его в тихом теплом месте, и через месяц прийти за результатом?
Если так, то проблема в том, что на разработку такого ТЗ нужно затратить больше времени, чем на кодирование. Плюс только при кодировании неизбежно вылезет что-то, из-за чего становится очевидно, что ТЗ хорошо бы подправить, а если пойти на принцип "кодю как написали" - получатся дикие костыли.
Поэтому на практике все же применяют некий итеративный процесс, а отсюда и необходимость периодической коммуникации с девелопером. И это, как верно подмечено, очень дорого стоит. Но иначе создавать ПО пока не научились.
У меня размер промпта, который приводил к результату, был сравним с размером полученного скрипта
Гы, показательно
И что быстрее по-вашему написать?
То была программа на языке который я тогда не знал, в предметной области в которой у меня были обрывочные знания. Так что на пару месяцев быстрее.
Ну в таком случае - возможно но для рабочих задач лучше понимать область и язык, как правило
Сейчас очень быстро всё меняется. Появился микроконтроллер с микропитоном - надо на нём писать. Потом переписать на С, как только производительности недостаточно. А по образованию ты совсем другой программист. ИИ это всё делает.
На хабре тусуются несколько оторванные от реальности граждане, а всё потому, что у нас есть огромный сектор реального программирования с одной стороны всякие заводы с крошечными зарплатами и соответствующими последствиями для их специалистов, а с другой стороны реальное производство почти отсутствует и не может кормить квалифицированных программистов. И там ИИ должен сильно помогать. Как результат, у определённой группы программистов складывается впечатление что программы пишут для банков, Газпрома и немного игродизайнеры. И именно эта группа основные посетители хабра.
Де жа вю! На выходных для личных нужд с помощью ИИ делал два скрипта (PowerShell, и Bash). Вот прямо то же самое.. Почти до ночи с ИИ сидел..)))
Думаешь, свой код бы понял через месяц?
Надо структурировать и документировать.
Так ИИ сделал в целом норм, и с комментариями, как надо. Свой тоже бы понял, но всë равно это надо вчитываться и вникать.
ИИ мастер структурировать и документировать. Вот что он мне выдал когда я попросил улучшить код "gzip *.log", который все так и используют, не зная что правильней так:
Скрытый текст
#!/usr/bin/env bash
Сжимает все *.log файлы в указанной или текущей директории.
Пропускает уже сжатые (*.log.gz) и пустые файлы.
В конце выводит статистику по количеству, размеру и экономии.
set -euo pipefail shopt -s nullglob
Цвета
RED="\033[31m" GREEN="\033[32m" YELLOW="\033[33m" BLUE="\033[34m" RESET="\033[0m"
Очистка при выходе
trap 'printf "%b\n" "${RESET}"' EXIT
Проверка зависимостей
for cmd in gzip du stat find; do if ! command -v "RED" "
cmd" >&2 exit 1 fi done
Опции
recursive=false quiet=false
while [[ 1" in -r|--recursive) recursive=true ;; -q|--quiet) quiet=true ;; -h|--help) cat <&2 exit 1 fi
Поиск файлов
if dir" -type f -name ".log") else mapfile -t log_files < <(find "$dir" -maxdepth 1 -type f -name ".log") fi
if [[ YELLOW" "
RESET" exit 0 fi
count=0 skipped=0 size_before=0 size_after=0
for file in "file" ]]; then
YELLOW" "
file" ((skipped++)) continue fi
# Пропуск уже сжатых
if [[ -f "$file.gz" ]]; then
$quiet || printf "%bПропускаю (уже сжат):%b %s\n" "$BLUE" "$RESET" "$file"
((skipped++))
continue
fi
# Проверка прав
if [[ ! -w "$(dirname "$file")" ]]; then
$quiet || printf "%bПропускаю (нет прав на запись):%b %s\n" "$RED" "$RESET" "$file"
((skipped++))
continue
fi
$quiet || printf "%bСжимаю:%b %s\n" "$GREEN" "$RESET" "$file"
before=$(stat -c%s -- "$file")
size_before=$(( size_before + before ))
if gzip -9n -- "$file"; then
after=$(stat -c%s -- "$file.gz")
size_after=$(( size_after + after ))
((count++))
else
printf "%bОшибка при сжатии:%b %s\n" "$RED" "$RESET" "$file" >&2
((skipped++))
fi
done
Склонение слова
if (( count % 10 == 1 && count % 100 != 11 )); then word="файл" elif (( count % 10 >= 2 && count % 10 <= 4 && (count % 100 < 10 || count % 100 >= 20) )); then word="файла" else word="файлов" fi
Итог
printf "\n%bГотово:%b сжато %d %s, пропущено %d.\n" "RESET" "
word" "$skipped"
if (( count > 0 && size_before > 0 )); then saved=(( 100 * saved / size_before )) before_mb=
(( size_after / 1048576 )) saved_mb=$(( saved / 1048576 ))
printf "Размер: %d МБ → %d МБ (−%d МБ, экономия %d%%)\n" \
"$before_mb" "$after_mb" "$saved_mb" "$percent"
fi
Я уж не говорю о том как это всё поддерживать
А не надо поддерживать, по изначальному замыслу. Просто уточняете "заклинание". "Поддерживать" теперь надо промпт, а не сгенерированный по нему код, код уходит на уровень, на котором раньше был байт-код.
По крайней мере это так задумано.
Нейросети потом на большом количестве кода галлюцинировать начинают. Поддерживать всё равно нам придётся
Вот да, тут большой риск улучшить промпт немного и получить совсем другой результат..
Поэтому первые запросы создают общую структуру, а потом отдельно работа с процедурами. Можно и более крупные блоки, но ИИ иногда жуткую ересь пишет и контролировать всё равно придётся.
И надо понимать, что не все пишут мегасистемы, очень много небольших программ и слабых программистов. ИИ наверняка спасение для возрастных программистов.
И надо понимать, что не все пишут мегасистемы, очень много небольших программ и слабых программистов. ИИ наверняка спасение для возрастных программистов.
Мне кажется тут у вас обратная логика какая-то. Возрастные часто более опытные и пишут более сложные части систем.
Возрастные программисты находятся в нескольких ловушках. Они знают как надо делать на самом деле, так как в отличии от молодых программистов имеют опыт эксплуатации систем в течении десятилетий. Они знают как сделать систему из говна и палок, молодые знают как сделать на современных в данный момент инструментах (которые через 5-10 лет все забудут и будут считать говном и палками). Они могут реально сделать всю систему сами, если... если у них будет полк программистов которые будут делать точно то что им говорят и будут знать всё - а молодые программисты сейчас почему то знают только узкие области (я встречал молоды программиста на Java который в принципе не умел читать логи!!! и не знали как работать в Linux). То есть старые программисты вроде бы всё знают, всё могут. А на самом деле просто нет времени сделать всё самостоятельно, а полка программистов-помощников в реальности нет, новые знания воспринимаются с трудом, широта интересов такая что вроде знаешь всё а в деталях - ничего. AI как раз решает проблему - он заполняет лакуны в знаниях и предоставляет тот самый полк программистов и недостающие знания.
На самом деле как распределяется количество старых и новых программистов? Наверно минимум поровну. В группах 20-30, 30-40, 40-50, 50-60 теоретически должно быть по 25% программистов, в реальности половина в группе 30-40, половина 20-30 . То есть куда-то подевались эти самые опытные программисты. ИИ должен помочь их вернуть.
То есть куда-то подевались эти самые опытные программисты. ИИ должен помочь их вернуть.
У нас в системном программировании - доля 40+ весьма значительна.
Если же говорить о "программировании вообще" - последние лет 20 в России число программистов росло экспоненциально год от года. Долю тех, кто вошёл 10-30 лет назад можете вычислить сами, в зависимости от знаменателя прогресии.
У нас это у кого, и что такое системное программирование, и какова собственно доля системного программирования в сравнении со всем программированием?
Доля программистов 50 лет, без учета естественной убыли, такая же как 30-летних при условии что они остаются программистами и выпуск программистов не рос. Насчёт экспотенциальности - сомневаюсь, ну в два раза за десятилетие возможно. А их заметно меньше. Почему?
15 лет назад. Встретился с таким php-программистом: не умеет читать логи, не знает ком. строку *nix, не знает версию php под которую пишет, не знает библиотеки,которые использует, не умеет настраивать apache.
Так что ничего удивительного что, условный java-разработчик не умеет в логи и linux, ему это не надо, т.к. рядом есть "нянька"
Скажите это моему руководству. Посадили всех в open офис. Один постоянно, то радио включит, то кашляет и крякает. Некоторые и по громкой связи говорят.
Опенофисы давно уже признали злом.
Строительные/охотничьи наушники очень помогают
Есть такое малоизвестное изобретение как закрытые наушники. Еще есть разного рода музыка, которую и слушать приятно, и заглушает ненужный шум. Например, hardtekk :D
разработчикам удаётся выкроить всего две одночасовые сессии в неделю!
Ни за что не поверю, что у какого-то разработчика может быть прямо вот столько созвонов. Тут скорее какой-нибудь СДВГ замешан.
Но в целом, проблема избыточных созвонов хорошо решается логированинм времени. Стоит один раз менеджменту увидеть время, потраченное всей командой на звонки и умножить на почасовую ставку, и выводы делаются сами собой. Если централизованного логирования нет, можно вести самому, чтобы потом показывать. Тут же такое дело, если ты провёл, скажем, 4 часа на совещаниях, то никто уже не вправе требовать с тебя в этот день больше 4 часов основной работы.
Однако, ребята, не забываем ещё одну очень важную причину созвонов: сами разработчики. Был у меня коллега, которому нужно было чуть ли не пошагово объяснять выполнение всего кода, прежде чем он возьмётся за внесение изменений. И вот потом статистика за неделю: 5 дейликов по 10 минут (они всегда в одно время в начале дня, поэтому не сильно отвлекают), и две сессии объяснения по 2 часа. То есть 50 минут в неделю совещаний с менеджментом против 4 часов совещаний с коллегой.
Стоит один раз менеджменту увидеть время, потраченное всей командой на звонки и умножить на почасовую ставку, и выводы делаются сами собой.
Были прецеденты или вы это умозрительно говорите? Могут сделать и другие выводы: не успеваешь -- твои проблемы, значит ты такой плохой разработчик, что с тобой нельзя без совещаний, оставайся доделывай после работы, задания с тебя никто не снимал.
Да, прецеденты были. Как только начинаешь включать тайм-трекер на звонке, сразу оказывается, что половина людей на звонке не нужна, половину вопросов можно решить в переписке. Плюс клиент начинает приходить на звонки подготовленным, с чёткой повесткой. Совещания сразу становятся продуктивными. А всё почему? Потому что совещания — это тоже работа, а к работе нужно относиться ответственно. Если же к совещаниям не относятся как к работе, то и требовать их посещать в таком случае нельзя.
Качество работы снижается, поэтому возникает больше проблем → планируется больше совещаний для их решения.
Помню был спринт, когда мы (команда) не успевали закрыть несколько важных задач. В пятницу нужно релизить, сегодня вторник, и ещё есть время кое-что спасти... Но тут нашему манагеры приходит идея! А давайте соберёмся на внеочередной собрание "что пошло не так". На замечание "а может быть мы лучше поработаем, больше толку будет?", наш манагер ответил, что нет, он хочет такие спринты в будущем избегать.
Разработка ПО, это как правило, оперирование огромными объёмами информации и много коммуникации в чатах. Есть задачи, при выполнении который, необходимо учитывать работу других подсистем и их синхронизацию, а для этого нужно гарантированное непрерывное время работы без отвлечения. Уточнение задачи и общение в чате, забирает много ментальных сил. Критерии работы, это факт закрытие залачи, качество и время выполнение. И все эти дейлики, почасовая оплата, слежение за экраном, созвоны есть иллюзия контроля и угнетение.
Правило универсальное для любой работы: создайте условия для комфортной работы, и результат будет.
То что ИИ усугубил проблему - в целом да. Манагеры видят, что код генерируется магическим образом за секунды, и не понимают что основная работа разработчика не печатать, а думать над архитектурой, над последствиями, над интеграцией. ИИ помогает печатать, но не думать. И для думания нужна тишина
Мой руководитель вообще считает что программу пишет ИИ а я ничего не делаю :)
Пусть пишет сам :)
Хорошо что у меня на работе еще до такого маразма не дошло, ну никто сильного ускорения пока не ждет от разработчиков из-за ЛЛМ, посмотрим как дальше конечно.
Ну да, а раньше за нас писал автокомплит в ide и прочие средства кодогенерации :)
И вообще, за что нам платить, если мы не на перфокартах код набираем :)
Почему-то принято считать, что только разработка требует глубокого погружения в задачи и проекты. На самом деле есть ещё масса других технических позиций/ролей, которые тоже требуют погружения, и людей на которых тоже достаточно дорого отвлекать и дёргать. Не разработкой единой, так сказать =)
Эта проблема не решилась с появлением ИИ-помощников в кодинге
Она не могла решиться. Просто потому, что ИИ помощники увеличивают время реализации задачи.
Так написали как будто только менеджеры и встречи отвлекают от работы. А покурить? А кофе попить? А с соседом поговорить? А шум в опенспейсе? А там кто-то смешно пошутил, надо посмеяться ещё.
Получается надо отменить перекуры, убрать кофемашины и запретить говорить в опенспейче для больше продуктивности?
Отвлекать разработчиков ПО намного вреднее, чем считает большинство менеджеров