После COVID-19 наша культура труда в основном изменилась к лучшему, но были и негативные изменения, например, увеличение количества совещаний на 13,5%[1].
Проблема заключается в том, что есть огромный разрыв между тем, как совещания воспринимают менеджеры и разработчики.
В своей знаменитой статье «Maker's Schedule, Manager’s Schedule» [2] Пол Грэм писал:
«Когда работаешь в режиме творца, совещания — это катастрофа. Единственное совещание может поломать день, разделив его на две части, в каждой из которых невозможно сделать ничего достаточно сложного».
Эта проблема не решилась с появлением ИИ-помощников в кодинге; напротив, она усугубилась, потому что менеджеры теперь считают, что разработчики могут быть продуктивными в меньших временных интервалах.
За последние два года мы изучили сотни команд разработчиков, чтобы разобраться, чем отличаются лучшие из них. В этой статье мы поделимся их стратегиями и расскажем о действиях, которые вы можете предпринять уже сегодня.
Но сначала давайте поговорим о глубокой работе:
Что такое глубокая работа?
Этот термин сформулировал Кэл Ньюпорт в своей книге «Deep Work: Rules for Focused Success in a Distracted World»[3].
Глубокая работа (Deep Work) — это работа, требующая большой доли мыслительных усилий, обычно несущая некую уникальную ценность. Её нельзя выполнять, когда тебя отвлекают! Если вы можете работать над задачей в процессе созвона через Zoom, то это — НЕ глубокая работа.
Поверхностная работа (Shallow Work) — это нечто противоположное: задачи, которые можно решать без напряжения 100% мозга. Например, это могут быть ответы на сообщения в Slack/почте, просмотр документа и так далее.
Разработка ПО когда-то была гаванью для людей, наслаждающихся глубокой работой. Стереотип о разработчике ПО, как об одиночке, работающем в подвале с наушниками на голове, возник не просто так.
Сегодня выкраивать время для глубокой работы становится всё сложнее и сложнее, но я считаю, что при использовании ИИ-помощников она ещё более важна.
Почему глубокая работа настолько критична
Глубокая работа — единственный способ достижения состояния «потока».
Длительная глубокая работа позволяет разработчикам:
Совершать меньше ошибок.
Поддерживать баланс работы и жизни — им удаётся выполнять больше работы за меньшее время, благодаря чему остаётся больше свободного времени.
Развивать свои навыки — в эти промежутки сосредоточенности решаются самые сложные задачи и происходит наибольший рост навыков.
Менеджеры совершают большую ошибку, полагая, что благодаря ИИ-инструментам это уже не важно. Они думают, что разработчикам нужно привыкать к постоянному переключению контекста — между промптами всё равно ждать всего пару минут, так что кому важны эти отвлекающие факторы?
Из-за этого качество рассуждений и промптов снижается. Мы попадаем в бесконечные циклы: просим ИИ устранять проблемы, передавая ему не очень качественный контекст.
Если оставаться в состоянии потока, то чем глубже погружаться в задачу, тем меньше нужно итераций для достижения одинакового результата. Данными я это подтвердить не могу, лишь своим опытом и чутьём.
В чём же проблема с глубокой работой?
Решением проблемы должна была стать удалённая работа — не надо тратить время на поездку до офиса, меньше отвлекающих факторов. Но на самом деле, справедливым оказался только первый пункт.
С 2020 года в дополнение к росту общего количества совещаний на 13,5% также увеличилось на 60% число удалённых совещаний[5]. Неудивительно, что 92% сотрудников сообщают, что во время этих совещаний они пытаются заниматься многозадачностью[6], и мне кажется, в случае разработчиков ПО этот показатель почти равен 100%.
Здесь возникают две основные проблемы:
1. Глубокая работа превращается в поверхностную
Помните простую проверку, о которой мы говорили выше? Если задачу можно выполнять параллельно с созвоном, то это поверхностная работа.
Отличный пример этого — проверка пул-реквестов. Если сегодня занятой день с кучей совещаний, то когда их лучше всего проверять?
Разумеется, во время совещания… Но проверка пул-реквеста должна быть глубокой работой! То же самое относится к устранению багов и написанию дизайн-документов.
Выполнение этих задач во время совещания начинает порочный круг:
Качество работы снижается, поэтому возникает больше проблем → планируется больше совещаний для их решения.
Люди отвлекаются во время совещаний, поэтому качественные решения не принимаются → планируется ещё больше совещаний…
И это вина не разработчиков, пытающихся заниматься многозадачностью, а вашей культуры совещаний.
2. Разработчики не достигают состояния потока
Лишь для того, чтобы войти в темп, требуется 15 минут, и лишь через 45 минут (!) разработчик доходит до пика работоспособности, когда он полностью погружён в задачу[7].
Каждый раз, когда его отвлекают, из-за переключения контекста этот таймер сбрасывается. Исследование, проведённое компанией Meta*[8], продемонстрировало всю серьёзность проблемы — разработчикам удаётся выкроить всего две одночасовые сессии в неделю! (И мне кажется безумием, что трёхминутная сессия вообще считается «временем сосредоточения»).
При этом теряется не только время, потраченное на совещания. Каждый отвлекающий момент отбрасывает разработчика назад на 15-45 минут, из-за чего даже в ЛУЧШЕМ случае он успевает набрать за день всего один-два часа продуктивной работы.
Мне нравится эта аналогия, которую я позаимствовал из комментария на Reddit[9]:
Представьте, что разработчики похожи на шахтёров. Их работа — копать. Каждый раз, когда планируется совещание, им нужно собрать все инструменты, чтобы вовремя подойти к выходу из шахты.
После завершения совещания им нужно пройти весь путь к месту работы, если они вообще помнят правильный путь...
Поэтому, если вы хотите, чтобы они добывали вам бриллианты, оставьте их в покое.
Разработчикам ПО нужно как минимум по 4-5 часа работы без помех в день, а задача менеджера — обеспечить им это время.
Как можно создавать время для глубокой работы
Улучшать культуру совещаний в компании
Исправить её не так уж сложно — нужно «всего лишь» сделать так, чтобы все менеджеры придерживались простых правил:
Совещания должны быть эффективными. Казалось бы, это очевидно? Но так всё равно бывает редко… Совещанию нужны чёткая повестка и чёткие результаты.
Установите неизменное время для совещаний и оставляйте большие блоки времени, свободного от совещаний. Это могут быть дни или часы без совещаний.
Приглашайте только тех, кто действительно необходим; особенно плохо это правило соблюдается при удалённой работе — сегодня стало слишком легко приглашать всех. Менеджеры думают так: «В худшем случае они будут работать в многозадачном режиме, зато окажутся доступными на случай необходимости».
Это ужасный подход! Помните, что при многозадачности достичь состояния потока невозможно.
Каким же будет наилучшее решение? Избавляйтесь от максимально возможного числа совещаний!
В течение двух лет мы изучали работу сотен команд разработчиков. Особенно нас впечатлила команда в компании Pylon.
Мы попросили у разработчика-сеньора показать календарь на неделю. Он оказался абсолютно пустым: никаких стендапов, никакого планирования спринтов, никаких периодических совещаний.
Совместная работа в компании всё равно ведётся, но она происходит, только когда это необходимо, а не на совещаниях по графику. Вероятно, это возможно благодаря тому, что разработчики находятся в офисе пять дней в неделю, но избавиться от некоторых совещаний совершенно точно можно даже в условиях удалёнки.
А если вы не можете избежать всех совещаний, то мы как минимум рекомендуем организовать в рамках всей компании блоки времени для сосредоточенной работы. Проанализировав данные более чем 600 тысяч пул-реквестов, мы выяснили, что большинство разработчиков продуктивнее всего в интервалах 09:00-11:00 и 14:00-16:00:
*Примечание: учитывалось только время отправки коммитов, и мы знаем, что люди, вероятно, работали в часы до этого (а ещё есть обеденный перерыв). Тем не менее, мы считаем, что существуют «кластеры» продуктивных временных интервалов и что дробить рабочий день сотрудников не нужно!
Пересмотрите свой процесс работы с пул-реквестами
На самом ли деле вам нужны все эти пул-реквесты?
Команда Pylon удивила нас ещё и тем, что у неё почти не было код-ревью. Разработчики мерджат собственный код и запрашивают ревью, только когда им нужна обратная связь, например, когда им кажется, что они вносят рискованное изменение, или когда они новички и только осваиваются в компании.
Код-ревью — сильный отвлекающий фактор для обеих сторон. Когда тебе нужно проверить пул-реквест, ты стараешься сделать максимально быстро, чтобы не препятствовать работе других, а когда приходит ответ, хочется немедленно посмотреть его. В обоих случаях нарушается состояние потока.
Кажется, это противоречит здравому смыслу относительно качества кода, но Pylon рассуждает следующим образом: если мы наняли опытных разработчиков и доверяем им, то нет причин создавать при каждом изменении «бутылочное горлышко» требованиями обязательной проверки.
Покажите пример
Разобравшись с совещаниями, можно начать разбираться с другими отвлекающими факторами.
Лучший способ создания хорошей культуры — начать ценить собственное время глубокой работы и сделать так, чтобы его уважала остальная команда. Должен признаться, что у меня всё ещё возникают с этим проблемы — я планирую время сосредоточенной работы в календаре и надеваю наушники, но когда прерываю работу, то иногда заглядываю в Slack и отвечаю на сообщения.
Я знаю, что это показывает дурной пример моей команде — время глубокой работы должно быть священным, и люди должны знать, что вполне приемлемо пару часов отсутствовать в Slack.
Сегодня время сосредоточения становится крайне важным
Я считаю, что чем больше мы начинаем полагаться на ИИ, тем важнее становится время сосредоточения. Постепенно модели будут становиться гораздо быстрее, и мне кажется, что компании и разработчики, которые научатся входить в состояние потока с ИИ, обгонят других с большим отрывом.
Примечания
[1] https://www.notta.ai/en/blog/meeting-statistics
[2] https://paulgraham.com/makersschedule.html
[3] https://www.goodreads.com/book/show/25744928-deep-work
[4] https://hbr.org/2014/05/create-a-work-environment-that-fosters-flow
[5] https://www.cfo.com/news/remote-meetings-up-60-since-2020-weekly-stat/654749/
[6] https://www.flowtrace.co/collaboration-blog/50-meeting-statistics
[9] https://www.reddit.com/r/programming/comments/1bbcoec/comment/ku9i16h/
Комментарии (78)
Pshir
06.10.2025 13:32Проблема заключается в том, что есть огромный разрыв между тем, как совещания воспринимают менеджеры и разработчики.
На самом деле, должно быть так: «есть огромный разрыв между тем, как совещания воспринимают те, кто только создаёт видимость работы, и те, кто действительно работает.» Менеджер, который работает, а не просто выполняет идиотский KPI, не будет почём зря дёргать всех вокруг каждые два часа.
ogost
06.10.2025 13:32Менеджер, который работает, а не просто выполняет идиотский KPI
Таковые наверняка занесены в Красную Книгу, ибо вживую я их не встречал.
Pshir
06.10.2025 13:32Их, конечно, мало, из-за обязательного отрицательного отбора среди менеджеров в крупных компаниях, но вообще такие бывают.
apcs660
06.10.2025 13:32Вспомнился один технический директор... В целом, мне на руководство везло (наверное потому что компании были маленькие). Но тут раскрутился наконец то стартап, пошли нормальные деньги и началось дерьмо. Владельцы улетели на Багамы (лет на 5), те кто пахали, остались пахать (зарплату накинули), зато пришел целый косяк начальства, включая техдира. Он был абсолютно дубовый. Если CEO и выше тихо пилили свои зарплаты и рисовали графики как все хорошо идет, то этот просто заморозил любые улучшения и вообще изменения в техпроцессах. Это можно себе позволить только если сидишь на гарантированных заказах (госах) или слишком большой чтобы падать.
Заморозка сказалась позже, когда компания в итоге крякнулась, потеряв активное ядро сотрудников.
Dmitry_604
06.10.2025 13:32Выросшие из разработчиков бывают адекватные вполне, понимающие (особенно выросшие не совсем по своей воле) :)
apcs660
06.10.2025 13:32как говорится, прусская школа - чтобы стать офицером, нужно побыть рядовым. Когда то в 90е, присматривал себе небольшой ресторанчик плюс пивная в Чехии, и на полном серьезе собирался пройти путь от посудомойки. Ресторан не получился (увы), но как наливать пиво и делать кофе, освоил. По крайней мере знаю как налить с пеной и без пены и сделать лате в стеклянном бокале чтобы слой молока был отделен от кофе. Самое главное, понял как работает кухня, куда прячут деликатесы чтобы сожрать после закрытия и тд, мотивация и контр мотивация тоже хорошо усваивается на своей шкуре.
Dmitry_604
06.10.2025 13:32И не сложно после такого в IT? :) Или наоборот, мотивирует?
apcs660
06.10.2025 13:32Полгода пил пиво и попутно сортировал компьютеры (разборка) - нет, не сложно когда еще в школе в радиокружке радио86рк собирали и программы набивали в машинном коде из журнала Радио :-),. Перед этим был стартап типография (пока учился) - вот это было сложно - из 4х нас осталось двое (целых). Наезды, попытки отжать бизнес, посадка конкурентов, они тебя тоже или посадить или укантропопить не прочь - это сложно. А IT это развлечение - сиди себе, пили код, платят достаточно чтоб не голодать... Спокойная работа. Легче чем наукой заниматься и опасности ноль. У меня как то на заводе коротнула точечная сварка и выбило предохранитель на 30КА - на память остались очки нашпигованные медью... А в IT сервера не взрываются.
krabdb
06.10.2025 13:32Замеры заново открывают то, что у Брукса написано "Мифическим человеке-месяце" в 1975 году?
gerashenko
06.10.2025 13:32Замеры))) ох уж эта автозамена, всегда каверкает зумеров)
Okeu
06.10.2025 13:32ох уж эта автозамена
необучаемые бумеры никак не научатся называть зумеров зумерами без посторонней помощи)
Serge1001
06.10.2025 13:32Эта проблема не решилась с появлением ИИ-помощников в кодинге; напротив, она усугубилась, потому что менеджеры теперь считают, что разработчики могут быть продуктивными в меньших временных интервалах.
Как будто бы ИИ делает нас продуктивнее...
А проверять за ним кто будет?
Код который я мог написать за час, нейросетка пишет за пару минут. Вот только потом ещё пару часов это всё допиливать чтоб хотя бы заработало... Я уж не говорю о том как это всё поддерживать))
AVX
06.10.2025 13:32Про "потом поддерживать" - в точку! Мне как-то надо был скриптик написать, но переключаться и вспоминать как там что в powershell делается, мне не хотелось. Решил чере ИИ. Написал подробно и точно что хочу, и через десяток доработок получил рабочий вариант, учитывающий все хотелки. Код я мельком глянул, криминала не увидел. А вот потом понадобилось добавить функционал - и я понимаю, что если бы я сам это писал, то такая доработка заняла бы ну минут 5. Но я код не знал и не вникал как там что реализовано, пришлось в том же чате продолжить и попросить добавить новую фичу. Естественно, понадобилось опять несколько итераций, чтобы получить что надо и баги устранить. Заняло это не менее полчаса. К тому времени я уже и сам к коду присмотрелся, и дальше решил что мне проще и быстрее сразу как надо самому поправить, чем описывать задачу для ИИ.
Flammar
06.10.2025 13:32Промпт не промпт, но в "человеческом" мире меня с некоторых пор начала забавлять ситуация, когда ТЗ по объёму превосходит сделанный на основе него код. Поэтому, мне кажется, в реальной жизни "качественные ТЗ" и встречаются настолько редко, что все о них слышали, но мало кто видел.
AlexMih
06.10.2025 13:32А что такое "качественное ТЗ"? То, которое можно отдать разработчику, оставить его в тихом теплом месте, и через месяц прийти за результатом?
Если так, то проблема в том, что на разработку такого ТЗ нужно затратить больше времени, чем на кодирование. Плюс только при кодировании неизбежно вылезет что-то, из-за чего становится очевидно, что ТЗ хорошо бы подправить, а если пойти на принцип "кодю как написали" - получатся дикие костыли.
Поэтому на практике все же применяют некий итеративный процесс, а отсюда и необходимость периодической коммуникации с девелопером. И это, как верно подмечено, очень дорого стоит. Но иначе создавать ПО пока не научились.
KonstantinTokar
06.10.2025 13:32У меня размер промпта, который приводил к результату, был сравним с размером полученного скрипта
Dmitry_604
06.10.2025 13:32Гы, показательно
И что быстрее по-вашему написать?
KonstantinTokar
06.10.2025 13:32То была программа на языке который я тогда не знал, в предметной области в которой у меня были обрывочные знания. Так что на пару месяцев быстрее.
Dmitry_604
06.10.2025 13:32Ну в таком случае - возможно но для рабочих задач лучше понимать область и язык, как правило
KonstantinTokar
06.10.2025 13:32Сейчас очень быстро всё меняется. Появился микроконтроллер с микропитоном - надо на нём писать. Потом переписать на С, как только производительности недостаточно. А по образованию ты совсем другой программист. ИИ это всё делает.
На хабре тусуются несколько оторванные от реальности граждане, а всё потому, что у нас есть огромный сектор реального программирования с одной стороны всякие заводы с крошечными зарплатами и соответствующими последствиями для их специалистов, а с другой стороны реальное производство почти отсутствует и не может кормить квалифицированных программистов. И там ИИ должен сильно помогать. Как результат, у определённой группы программистов складывается впечатление что программы пишут для банков, Газпрома и немного игродизайнеры. И именно эта группа основные посетители хабра.
DadeMurphyZC
06.10.2025 13:32Де жа вю! На выходных для личных нужд с помощью ИИ делал два скрипта (PowerShell, и Bash). Вот прямо то же самое.. Почти до ночи с ИИ сидел..)))
Dhwtj
06.10.2025 13:32Думаешь, свой код бы понял через месяц?
Надо структурировать и документировать.
AVX
06.10.2025 13:32Так ИИ сделал в целом норм, и с комментариями, как надо. Свой тоже бы понял, но всë равно это надо вчитываться и вникать.
KonstantinTokar
06.10.2025 13:32ИИ мастер структурировать и документировать. Вот что он мне выдал когда я попросил улучшить код "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 [[
![# -gt 0 ]]; do
case](https://habrastorage.org/getpro/habr/formulas/2/28/28a/28a39d002779d6562587f25d6eb3886f.svg)
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") fiif [[
![{#log_files[@]} -eq 0 ]]; then
printf](https://habrastorage.org/getpro/habr/formulas/6/65/650/650b33bed027b45bc36eb1167f628a9f.svg)
YELLOW" "
RESET" exit 0 ficount=0 skipped=0 size_before=0 size_after=0
for file in "
![{log_files[@]}](https://habrastorage.org/getpro/habr/formulas/2/29/298/2986cb5c509e3f7931d75ace7cc99581.svg)
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++)) fidone
Склонение слова
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
Flammar
06.10.2025 13:32Я уж не говорю о том как это всё поддерживать
А не надо поддерживать, по изначальному замыслу. Просто уточняете "заклинание". "Поддерживать" теперь надо промпт, а не сгенерированный по нему код, код уходит на уровень, на котором раньше был байт-код.
По крайней мере это так задумано.Serge1001
06.10.2025 13:32Нейросети потом на большом количестве кода галлюцинировать начинают. Поддерживать всё равно нам придётся
Dmitry_604
06.10.2025 13:32Вот да, тут большой риск улучшить промпт немного и получить совсем другой результат..
KonstantinTokar
06.10.2025 13:32Поэтому первые запросы создают общую структуру, а потом отдельно работа с процедурами. Можно и более крупные блоки, но ИИ иногда жуткую ересь пишет и контролировать всё равно придётся.
И надо понимать, что не все пишут мегасистемы, очень много небольших программ и слабых программистов. ИИ наверняка спасение для возрастных программистов.
Dmitry_604
06.10.2025 13:32И надо понимать, что не все пишут мегасистемы, очень много небольших программ и слабых программистов. ИИ наверняка спасение для возрастных программистов.
Мне кажется тут у вас обратная логика какая-то. Возрастные часто более опытные и пишут более сложные части систем.
KonstantinTokar
06.10.2025 13:32Возрастные программисты находятся в нескольких ловушках. Они знают как надо делать на самом деле, так как в отличии от молодых программистов имеют опыт эксплуатации систем в течении десятилетий. Они знают как сделать систему из говна и палок, молодые знают как сделать на современных в данный момент инструментах (которые через 5-10 лет все забудут и будут считать говном и палками). Они могут реально сделать всю систему сами, если... если у них будет полк программистов которые будут делать точно то что им говорят и будут знать всё - а молодые программисты сейчас почему то знают только узкие области (я встречал молоды программиста на Java который в принципе не умел читать логи!!! и не знали как работать в Linux). То есть старые программисты вроде бы всё знают, всё могут. А на самом деле просто нет времени сделать всё самостоятельно, а полка программистов-помощников в реальности нет, новые знания воспринимаются с трудом, широта интересов такая что вроде знаешь всё а в деталях - ничего. AI как раз решает проблему - он заполняет лакуны в знаниях и предоставляет тот самый полк программистов и недостающие знания.
На самом деле как распределяется количество старых и новых программистов? Наверно минимум поровну. В группах 20-30, 30-40, 40-50, 50-60 теоретически должно быть по 25% программистов, в реальности половина в группе 30-40, половина 20-30 . То есть куда-то подевались эти самые опытные программисты. ИИ должен помочь их вернуть.
WASD1
06.10.2025 13:32То есть куда-то подевались эти самые опытные программисты. ИИ должен помочь их вернуть.
У нас в системном программировании - доля 40+ весьма значительна.
Если же говорить о "программировании вообще" - последние лет 20 в России число программистов росло экспоненциально год от года. Долю тех, кто вошёл 10-30 лет назад можете вычислить сами, в зависимости от знаменателя прогресии.KonstantinTokar
06.10.2025 13:32У нас это у кого, и что такое системное программирование, и какова собственно доля системного программирования в сравнении со всем программированием?
Доля программистов 50 лет, без учета естественной убыли, такая же как 30-летних при условии что они остаются программистами и выпуск программистов не рос. Насчёт экспотенциальности - сомневаюсь, ну в два раза за десятилетие возможно. А их заметно меньше. Почему?
WASD1
06.10.2025 13:32и что такое системное программирование,
Вы всерьёз спрашиваете или троллите?
Впрочем в любом из этих вариантов смысла в дальнейшем разговоре не вижу. Всего хорошего.
avegad
06.10.2025 13:3215 лет назад. Встретился с таким php-программистом: не умеет читать логи, не знает ком. строку *nix, не знает версию php под которую пишет, не знает библиотеки,которые использует, не умеет настраивать apache.
Так что ничего удивительного что, условный java-разработчик не умеет в логи и linux, ему это не надо, т.к. рядом есть "нянька"
Dddn
06.10.2025 13:32Скажите это моему руководству. Посадили всех в open офис. Один постоянно, то радио включит, то кашляет и крякает. Некоторые и по громкой связи говорят.
Shermike
06.10.2025 13:32Есть такое малоизвестное изобретение как закрытые наушники. Еще есть разного рода музыка, которую и слушать приятно, и заглушает ненужный шум. Например, hardtekk :D
Dddn
06.10.2025 13:32А ещё если их слушать целый день, то происходит потеря слуха? Вопрос, к вам, как к специалисту.
А ещё я сидел в наушниках и иногда подскакивал, когда сзади уже за плечо трясли, хотели что-то сказать.
Serge1001
06.10.2025 13:32А ещё есть изобретение под названием "удаленная работа" :)
KonstantinTokar
06.10.2025 13:32Вот я сейчас удалён от работы. Приближен к семье, у детей каникулы. Стремлюсь в офис где я один, да ехать долго.
gun_dose
06.10.2025 13:32разработчикам удаётся выкроить всего две одночасовые сессии в неделю!
Ни за что не поверю, что у какого-то разработчика может быть прямо вот столько созвонов. Тут скорее какой-нибудь СДВГ замешан.
Но в целом, проблема избыточных созвонов хорошо решается логированинм времени. Стоит один раз менеджменту увидеть время, потраченное всей командой на звонки и умножить на почасовую ставку, и выводы делаются сами собой. Если централизованного логирования нет, можно вести самому, чтобы потом показывать. Тут же такое дело, если ты провёл, скажем, 4 часа на совещаниях, то никто уже не вправе требовать с тебя в этот день больше 4 часов основной работы.
Однако, ребята, не забываем ещё одну очень важную причину созвонов: сами разработчики. Был у меня коллега, которому нужно было чуть ли не пошагово объяснять выполнение всего кода, прежде чем он возьмётся за внесение изменений. И вот потом статистика за неделю: 5 дейликов по 10 минут (они всегда в одно время в начале дня, поэтому не сильно отвлекают), и две сессии объяснения по 2 часа. То есть 50 минут в неделю совещаний с менеджментом против 4 часов совещаний с коллегой.
Flammar
06.10.2025 13:32Стоит один раз менеджменту увидеть время, потраченное всей командой на звонки и умножить на почасовую ставку, и выводы делаются сами собой.
Были прецеденты или вы это умозрительно говорите? Могут сделать и другие выводы: не успеваешь -- твои проблемы, значит ты такой плохой разработчик, что с тобой нельзя без совещаний, оставайся доделывай после работы, задания с тебя никто не снимал.
gun_dose
06.10.2025 13:32Да, прецеденты были. Как только начинаешь включать тайм-трекер на звонке, сразу оказывается, что половина людей на звонке не нужна, половину вопросов можно решить в переписке. Плюс клиент начинает приходить на звонки подготовленным, с чёткой повесткой. Совещания сразу становятся продуктивными. А всё почему? Потому что совещания — это тоже работа, а к работе нужно относиться ответственно. Если же к совещаниям не относятся как к работе, то и требовать их посещать в таком случае нельзя.
Aleus1249355
06.10.2025 13:32Качество работы снижается, поэтому возникает больше проблем → планируется больше совещаний для их решения.
Помню был спринт, когда мы (команда) не успевали закрыть несколько важных задач. В пятницу нужно релизить, сегодня вторник, и ещё есть время кое-что спасти... Но тут нашему манагеры приходит идея! А давайте соберёмся на внеочередной собрание "что пошло не так". На замечание "а может быть мы лучше поработаем, больше толку будет?", наш манагер ответил, что нет, он хочет такие спринты в будущем избегать.
atues
06.10.2025 13:32В пятницу нужно релизить
Эх, хтош так делает! Забыли святое: в пятницу деплой - в выходные геморрой )
Aleus1249355
06.10.2025 13:32Верно глаголишь! Но мы с утра релизили :-)
Тем более у нас было десктопное приложение, и пользователи сами решали когда обновиться, примерно как в VSCode или Notepad++.
Естественно были пользователи с очень древними версиями
T700
06.10.2025 13:32Разработка ПО, это как правило, оперирование огромными объёмами информации и много коммуникации в чатах. Есть задачи, при выполнении который, необходимо учитывать работу других подсистем и их синхронизацию, а для этого нужно гарантированное непрерывное время работы без отвлечения. Уточнение задачи и общение в чате, забирает много ментальных сил. Критерии работы, это факт закрытие залачи, качество и время выполнение. И все эти дейлики, почасовая оплата, слежение за экраном, созвоны есть иллюзия контроля и угнетение.
Правило универсальное для любой работы: создайте условия для комфортной работы, и результат будет.
Dimmirslr
06.10.2025 13:32То что ИИ усугубил проблему - в целом да. Манагеры видят, что код генерируется магическим образом за секунды, и не понимают что основная работа разработчика не печатать, а думать над архитектурой, над последствиями, над интеграцией. ИИ помогает печатать, но не думать. И для думания нужна тишина
KonstantinTokar
06.10.2025 13:32Мой руководитель вообще считает что программу пишет ИИ а я ничего не делаю :)
Dmitry_604
06.10.2025 13:32Пусть пишет сам :)
Хорошо что у меня на работе еще до такого маразма не дошло, ну никто сильного ускорения пока не ждет от разработчиков из-за ЛЛМ, посмотрим как дальше конечно.
Serge1001
06.10.2025 13:32Ну да, а раньше за нас писал автокомплит в ide и прочие средства кодогенерации :)
И вообще, за что нам платить, если мы не на перфокартах код набираем :)
sgrinchenko
06.10.2025 13:32Почему-то принято считать, что только разработка требует глубокого погружения в задачи и проекты. На самом деле есть ещё масса других технических позиций/ролей, которые тоже требуют погружения, и людей на которых тоже достаточно дорого отвлекать и дёргать. Не разработкой единой, так сказать =)
diderevyagin
06.10.2025 13:32Эта проблема не решилась с появлением ИИ-помощников в кодинге
Она не могла решиться. Просто потому, что ИИ помощники увеличивают время реализации задачи.
atues
Слушайте, ну это же очевидно. Чем меньше разработчика дергают на всякие встречи, созвоны, совещания и бог знает на что еще, тем разработчик продуктивней, качество кода однозначно растет, решения, принимаемые в процессе разработки, взвешеннее и логичнее. Сколько можно мусолить одно и то же. Главная задача менеджера не пальцы растопыривать, а обеспечивать спокойную рабочую обстановку. С техническими проблемами разработчики сами прекрасно разберутся.
2medic
Всё бесполезно. Порою им просто хочется поболтать или что-то рассказать, когда у них, казалось бы, появляется минутка, и тут начинается вот это самое, типа: ой, а можно я тебе расскажу о... , или как на картинке: найдётся пару секунд для... Ну или у них внезапно возникла идея, и им нужно экспертное мнение, или иная информация.
Zekess
Или кому-то очень хочется показать "Активную деятельность" перед начальством :D
apcs660
с одной стороны да... но если посмотреть на митинги как на отдых? Поработал пару часов - митинг, пицца, кофе, отдыхаешь, набираешься сил... Главное научиться отдыхать на митингах. На митинге на удаленке я иногда рюмку коньяка мог пропустить (доклад CEO на тему "все хорошо, прекрасная Маркиза!" - все равно от разработчиков требовалось только присутствие послушать высокородных с трибуны).
А вот работа над тикетами в разных проектах меня вымораживала больше - нужно хорошо обдумать изменения и тебя раз и дергают на что то в другой проект. Три разных проекта глянуть в течении дня раздражает неимоверно.
flower9
Не знаю, я для отдыха лучше посижу в тишине (
или в телефоне), чем это. Митинги – это иллюзия отдыха. Казалось бы, присутствовал на встрече = работал, а нет. Это как в школе во время контрольной зашел директор сообщить новости и все обрадовались, что контрольной не будет, а на самом деле она будет, только теперь на 15 минут меньше времени на решение.Понимаю, что надо себя перенастраивать, чтобы относиться как вы, но как-будто это костыль, а не решение)
apcs660
Это работает если на удаленке. Вживую на митинге конечно не расслабишься
Dmitry_604
Ну если от тебя требуется участие в дискуссии или использование сказанного в дальнейшей работе, то сильно больше и не расслабишься тоже, а таких митингов все же большинство у разработчиков по крайней мере, ну если процесс правильно выстроен (ну и их в принципе не очень много).
apcs660
Тогда это рабочий, а не пустой митинг. Можно их делать по расписанию либо уходить в проект с меньшим количеством людей.
У меня был проект, к примеру, на 90 модулей примерно - пилил его в одиночку, иногда выделяли помощников, кто свободный. Хватало нормальное покрытие тестами делать.
Соседний базовый проект примерно 12 человек превратили в спагетти свалку.
Когда прибегали тестеры с криками "у тебя ошибка" - как правило ошибка была в базовом проекте.
Причина?
Ни одного рефакторинга в течении 10 лет (до смерти проекта).
Плохое управление кодом (ревью не успевали).
Нет покрытия тестами потому что 1 в том числе. - сразу не сделали а потом поздно, слишком дорого.
И ничего, начальство вваливало ресурсы именно в гавнямбу. Более того меня сократили (с кодом легко разобраться) а владельца гавнямбы оставили (кроме него в этом лабиринте никто не мог и не хотел разбираться).
Вот и думай, хорошо ли писать код понятным для других или лучше понятным только для себя
Dmitry_604
Не очень понимаю зачем делать нерабочие митинги тогда для разрабов, ну помимо общекорпоративных каких то собраний пару раз в год, или обучения точечного (что является все же частью работы).
А про код да, тоже знал человека который один над кодом сидел и разбирался строго только он один. В итоге начал шантажировать увольнением ИЧСХ выбил себе повышение через это.
dmitrijtest24
Обычно митинг никто не учитывает как работу. Это так, на обсудить вопрос, а сроки двигать никто не хочет, так что не сильно отдыхается на разговоре когда работы много а от говорения толку 0.
Dimmirslr
Это не отдых, а смена типа нагрузки - вместо глубокой концентрации поверхностное внимание и социальное взаимодействие - это тоже утомляет просто по другому. После 3-4 часов совещаний чувствуешь себя выжатым как лимон, хотя ничего не делал
Flammar
Особенно когда в анамнезе имеется ковид с реанимацией, от которого страдают внимание и память. Крадут последние остатки внимания.
apcs660
есть такая проблема... у меня было двусторонее воспаление ушей (среднего уха) - доигрался после бассейна зимой, пропустил электричку и промерз... Тупой был. Лет 10 восстанавливался и все равно, форму не вернул.
Anarchist
Если нужность разработчика достаточно очевидна, то свою нужность менеджерам приходится доказывать. Проще всего организуя совещания. Чем больше сотрудников удастся на них затащить, тем больше их будет осведомлено о важности работы этого менеджера. У самых бесполезных вообще нет другого способа.
dom1n1k
Команда посредственных разработчиков с хорошим менеджером сделает продукт, хотя он и будет далеко не идеален.
Команда хороших разработчиков с плохим менеджером скорее всего не сделает ничего, только сожжет время и бюджет (если только менеджерские функции не возьмёт на себя неформально кто-то другой).
totsamiynixon
Очень спорное утверждение.
Dmitry_604
Хорошие разработчики обычно понимают что и для чего они делают. И могут и менеджеру высказать что получится говно. Но если менеджер совсем непробиваемый - увы.
viktorov_aa
Как менеджер выросший из разработчика хочу сказать, что тут есть одно заблуждение.
Вы предположили, что задача разработчика только писать код и ничего больше. Это не всегда так.
В компаниях с большой кодовой базой зачастую надо еще понимать, когда код писать надо, а когда вообще не надо.
Например, опытный разработчик на совещании зачастую может сэкономить сотни часов на разработку, объяснив почему это вообще делать не надо или как адаптировать прошлое решение. А без этих знаний разработку нормально даже не запланировать.
Или надо продумать решение с учетом различной архитектуры. И это тоже важная и сложная глубокая работа, в которой будет несколько участников. То есть это тоже совещание.
PS
Я в целом то согласен, что после того, задача проработана надо не мешать ее решать. Но зачастую, чтобы ее проработать и запланировать, без созвонов никак.
KonstantinTokar
Должна быть заранее известная повестка
(чтобы тот самый опытный разработчик подготовился) и должен быть зафиксирован результат (чтобы после совещания не возникали вопросы типа "а что это было"). Может быть в конце рабочего дня, может быть в начале. По-видимому в статье идёт речь чём то другом.
Dimmirslr
Проблема в том, что у многих менеджеров KPI завязаны на активности: количество совещаний, отчетов, синхронизаций. Их система поощряет за создание шума, а не за обеспечение тишины