Организация рабочего пространства, будь что реального, что виртуального было всегда вопросом индивидуальным. Безусловно, порой есть best practictes: убрать всё лишнее с рабочего стола; отключить уведомления, иметь своё выделенное рабочее место. Вспоминаются сразу нон-фикшн литература о менеджменте пространства, психологии определённых ритуалов и атрибутов. Эта тема будто бы была актуальна всегда, и она настолько же исследована, насколько и индивидуальна: кто-то не может начать свой день, не погладив попугая на рабочем столе. Кто-то не может читать почту, пока не проведёт чайную церемонию, поливая телефон, мышку, колонку и прочее. Когда-то достаточно было просто стола и перфоратора, а сейчас сложно представить человека, работающего за компом без кресла - комбайна, которое затрагивает все частички твоей души в каждый конкретный момент; с механической клавиатурой, Дб нажатия клавиш которая должна быть всегда в пределах 55-60; диагональю монитора, чтобы он вмещал 2 любимые IDE, 1.5 любимых браузеров, 5 чатов с LLM, рабочий мессенджер (1 инстанст по каждой из работ). В каждой IDE 10 открытых pop-up’ов, 2 сплита на каждый буфер, 4 открытых таблиц, 7 активных докер exec bash процессов, 20 рабочих localhost вкладок и более 50 важных, но до сих пор не прочитанных; на каждое действие автокомплит + подсказка от агента + ai-powered copy/paste’ом c ai-powered буфером обмена с blazing fast и thread save обёрткой. Упс, не та тема уже; Общаясь с людьми, понимаешь, что всё чаще идёт сдвиг опциональных инструментов в первостепенные, и это то, о чем будет эта статья. Она не о хейте изобилия инструментария, она для рефлексии и инвентаризации того, что у вас уже есть.

Вы скажите: “Я фронтенд разработчик, мне критично важно использовать LLM, чтобы не тратить время на вёрстку”, “Зачем мне помнить psql синтаксис, если я могу использовать UI таблицы в своей любимой IDE?”, “Мне нужно это git окошко 100% времени разработки, потому что я 1% своего времени что-то коммичу/добавляю/сравниваю”, “Мне нужно окно структуры проекта, т.к. я часто перемещаюсь по нему”. Верно, это на первый взгляд инструменты, которые помогают что-то быстро решать. Но лишь на первый взгляд, но давайте по порядку

LLM

Давайте сразу возжгу это пламя Великого Холивара. Использование любых инструментов оптимизации – это всегда палка о двух концах. Делегируя свою обязанности (даже рутинные) на LLM вы не обращаете на них должного, привычного внимания, тем самым теряя навык этих рутинных действий, получая skill delay

Вы не занимаетесь настолько важными делами

Использование LLM для фокусировки на более важных вещах не всегда оправдано. Я думаю что архитектура всех ваших методов, алгоритмов и функций в купе важнее, нежели ваша гениальная архитектура из 10 квадратиков и 15 стрелочками между ними. LLM не умеет в детерминизм, строгость и логику: она не умеет видеть различные типы в сигнатурах. Тут будто бы даже логичнее отдать LLM более творческие задачи, как архитектура, нежели более точные и детерминированные задачи. Понятно, что самое интересное хочется себе взять, но, увы, писать нормальные функции LLM модель еще до конца не может.

LLM позволяет сделать рутинные дела, как проверку текста, линтинг и прочее приемлемо. Но не забывайте, что будто бы проще себе сразу приучить к правильному написанию, нежели к вечной проверке (речь не про прод паплайны, где лишние проверки, очевидно, являются плюсом) + не забывайте, что LLM – это не детерминированный инструмент

“LLM помогает мне быстро найти способ, куда двигаться, вместо того, чтобы читать документацию” – да, это круто, при условии того, что вы действительно больше никогда не прикоснётесь к этому предмету изучения, что вряд ли. Я сам раньше думал, что LLM позволяет быстро писать код особенно на тех фреймворках и языках, на которых ты раньше не писал. Если ваша задача сделать копипаст get started структуры, то LLM даст вам хорошее решение (ровно как и запрос в поисковике). Но если вы пишите что-то сложнее обычного мануала, то готовтесь к тому, что вы будете возвращаться к документации, фиксам, пёрфам, фичам, рефакторингу снова и снова. Невозможно создать хороший продукт с первой попытки, тем более с LLM, тем более в том виде, в которым они существуют сейчас. Думать что делегация чтения документации LLM – оптимизация, игра на краткосрок. Она поможет вам сэкономить 1-3 часа ваших часов сфокусированной работы, но, зная факт того, что вы всё равно будете погружаться в предмет изучения, разумнее выглядит изучение вопроса.

Проблема ещё и в том, что LLM по умолчанию генерирует информационный шум. Это как пытаться разобраться в запутанном, плохо написанном коде, пока на фоне играет ток-шоу с политическими дебатами. Кажется, что новости — это просто фон, но ваш мозг вынужден постоянно фильтровать и отсеивать лишнее, что создаёт неявную, но изматывающую когнитивную нагрузку. Точно так же ответ LLM, даже полезный, часто содержит избыточные объяснения, альтернативные варианты и шаблонные фразы, которые вам приходится "парсить". В итоге вы тратите ментальные ресурсы не на суть проблемы, а на фильтрацию этого потока. И в отличие от настраиваемого линтера, LLM по умолчанию не настроена на ваш контекст и даёт универсальный, "сырой" ответ, требующий доработки

Хорошая аналогия — регулярные негативные новости с радио или телевизора, который вроде только был фоном, но сильно нас в течении времени истощает. Это тот же тип фоновой когнитивной нагрузки, что и при работе с запутанным легаси-кодом: кажется, что вы просто смотрите на код, но ваш мозг постоянно и безуспешно пытается выстроить его непонятную логику, что приводит к такому же ментальному истощению, как и бесполезный информационный шум.

«LLM делает code-review за меня». Как доп. инструмент, наравне с линтерами и тайп-чекерами, приемлемо. Но делегация даже бОльшей части ревью на LLM — большой риск. (она вам не гарантируем результат. Ровно как и человек). Даже с учетом того, что мы может иметь детерминированную модель, она не учитывает бизнес контекст, стиль вашей команды, паттерны и прочее.

Ровно как и с код-ревью, цель документации — это документирование того или иного объекта в рамках всего проекта, а не обособленно. У меня каждый раз вызывает скрежет зубов документация и комментарии от LLM, которые описывают ровно то, что я вижу в коде: ни больше, ни меньше. Зачем мне читать в комментарии что функция «get_users» возвращает пользователей? Лучше было бы добавить примечание, что подобное получение обычно выносится через определенный паттерн, но в рамках хотфикса был добавлен явный метод. Данная проблема меня побуждает писать линтеры, которые запрещают комментарии. Да-да, комментарии по талончикам это ваш не шутки на проде

«Но зато LLM умеет дебажить код». Не умеет. Даже скажу обратное. Смотря как большинство разработчиков дебажат код с помощью LLM, я всё больше ужасаюсь: вместо того, чтобы открыть документации и прочитать описание поля, они виртуозно играют с промптами с целью объяснить LLM, что ничего не работает. Простите, но дебаг и решение проблем — это сложный и детерминированный процесс. Он, как ничто иное, завязан на специфике вашего проекта и которое может иметь 1000 и 1 зависимость

Мой основной тезис, не в том, что LLM — это про работу с вероятностями, нежели про работу с примитивами. А в том, что LLM подсаживают нас на их использование из-за кажущийся оптимизации, что является препятствием в профиссиональном росте и замедлением разработке на долгосрочной перспективе. LLM — хороший инструмент, но ровно как и любой другой в руках опытного разработчика. А для того, чтобы понять, насколько вы опытны, можно попробовать не использовать привычные инструменты, которые делегируют «банальные», «рутинные» вещи, т. к. именно в этих моменты всплывают белые пятна, заполнение которых и прокачивает нас, как разработчиков. В последней указанной статье эта тема хорошо расскрыта.

«Ты хочешь сказать, что если моя любимая IDE автоматизирует часто-используемые pop-up’ы — это плохо? Типо умение вручную через git diff смотреть изменения или подключать к бд через cli драйвер сделает меня опытным разработчиком?» Не совсем

IDE

Подхватив мысль о том, что проблема не в этих инструментах, а в бездумном использовании, рассмотрим как IDE часто предлагают функционал, который часто не нужен разработчикам. Рассмотрим лишь некоторые важные аспекты, чтобы не поливать водой и без того статью без кода.

Мы в основном читаем код, а не пишем

«IDE помогает давать каталог проекта». Каталог проекта — важный инструмент. Но я часто вижу, что бОльшую часть своего времени разработчики загораживают 10-40% своего экрана этим окном, с учетом того, что используют его 1-5% своего времени. Напомню, что вы имеете право это окно закрывать и даже отключить поведение по-умолчанию, чтобы оно открывать только вручную. Мы больше читаем, нежели пишем. Так давайте упростим и без того сложный процесс чтение кода, не захламляйте свой экран не важными на момент чтения окнами. Вы можете явно открыть каталог в любой момент времени по требованию

«Консоль помогает в одном месте сразу что-то выполнить и вынести почти весь воркфлоу в одном процессе IDE». Консоль, как и структура проекта, загораживает 20-50% нашего экрана и информационной нагрузки там гораздо больше, чем в окне с каталогом проекта. Следую эвристическому правилу, что мы больше читаем, нежели пишем, логичнее выглядит явно вызывать только консоль по требованию. Но проблема многих IDE в том, что консоль поставляется со множеством «полезных» фичей, некоторые разработчики ни разу их не использовали, хоть видят их перед собой на протяжении 2-8 часов в день в течении многих лет (!!!). Не забывайте, вы имеете права кастомизировать поведение консоли и ее внешний вид. Зачем вам комбайн от IDE, если вам нужно просто скосить траву через обычную bash оболочку?. Если вам нужна консоль, то вы можете ее либо явно открыть в IDE, либо в процессе

При работе с  опциональными процессами, как БД, Докер, k8s, etc, та же проблема. Эффективнее, когда вы в своём фокусе держите только объект изучения, нежели всё и сразу. Я уже молчу о том, что семантически, ваш объект фокуса, при работе с БД или докер, находится не в центральной части вашего экрана. Ну и конечно же, эвристика того, что мы реже работаем с этими процессами, нежели они у нас появляются в обзоре.

Это касается всех остальных подобных окон, как работа с VSC, структурой, дебагер и прочее. Если вам нужно поработать с конкретным процессом, то вы можете его явного открыть либо через IDE, либо через отдельный процесс

«Подсказки кода и паттернов ускоряют процесс написания кода». Да, они помогают вам сократить 1-60 секунд при написании кода. Но я в основном код читаю, нежели пишу. Вы можете ответить, что «эти мелочи в долгосрочной перспективе экономят целые дни!». Возможно, но лично моя проблема, как разработчика — это недостаток энергии и сил на понимание кода, нежели недостаток времени на его фактическое написание. И как раз мелочи, как подсказки кода, 70% забитого экрана IDE различной информации, подсветка ошибок, предупреждений и прочего на даже на краткосрочной перспективе влияют на вашу когнитивную нагрузку при чтении кода. А для меня это важнее, т. к. скорость написание кода в первую очередь зависит от его понимания, нежели от его физического написания. «Но ведь тогда я буду тратить много времени и главное своих сил на ручной поиск корректного паттерна или блока кода!». В первое время, конечно же да. Но красной нитью в этой статье поднимаются несколько тем, одна из них — привычка определяет workflow, а не удобство или практичность инструментов. Я просто исхожу из такого наблюдения. Если мы работаем над каким-то проектом, где используется настолько неизвестный нам фреймворк, что требуется автокомплит или подсказка паттернов, то звучит логичнее освоить такую базу, как написание базовых конструкций.

Тоже касается и подсказок кода, только от AI. Да, бОльший объем некорректных подсказок на малую долю корректных — похожая история как и излишними окнами. Т.е. не проблемы в самом инструменте, но есть проблема в его излишке. Если хотите помощь от AI в конкретном блоке коде — пишите сразу в чат LLM

«Постоянные предупреждения, ошибки и прочие помогают понять, что происходит в коде». Не совсем. Я себе поставил за правило, что чаще всего ваш код должен в редакторе должен подсвечивать только базовый синтаксис, не более. Если есть другие метки в коде: куча перманетных ошибок, предупреждений, которые продолжительное время просто существуют как часть кодовой базы (из-за специфики легаси, MVP версии, пет-проекта), то стоит задуматься, о том, что действительно ли корректно настроили под ваши требования LSP

“Множество сплитов, буферов и окон с кодом позволяет решать связанные между собой задачи, так как код действительно часто опирается на другие модули”. Но это в первую очередь вопрос привычки, а не реальной необходимости. Разработчики, привыкшие работать с десятками вкладок и сплитов, уже в самом начале проекта подстраивают свой workflow под такой режим, искусственно создавая себе потребность держать в голове одновременно десятки контекстов. На практике же такое переключение ведёт к постоянным прерываниям и росту когнитивной нагрузки: мозг вынужден поддерживать рабочее состояние для нескольких файлов сразу, что делает процесс чтения и понимания кода более утомительным.

Некоторые редакторы понимают эту проблему и позволяют ограничивать количество открытых вкладок

Также и дашбордами. Чем меньше дашбордов, тем быстрее и лучше вы сможете уделить ему внимания. Не спорю, со стороны они выглядят эффектно, но это ведь не практично. Чаще всего мы должны по требованию смотреть ту или иную метрику с дашбордом. Но подтягивать множество других — лишний шум.

«Плагины помогают автоматизировать работу с внешними инструментами или фичами». Работа с плагинами порой похожа на CV, где человек указывает те инструменты, которые трогал пару раз. Если вы используете в одном проекте BitBucket и редко делаете коммиты/пуши, то тащить целый плагин ради этого выглядит избыточно

.

Опять таки, проблема не в IDE. Они — комплексные IT-продукты, нацеленные на полную кастомизацию, которое можно подточить под индивидуальный workflow. Даже в документации JetBrains говорят минимизировать UI. Есть множество на мой взгляд перегруженных сборок в Emacs, Vim, Nvim и много удачных решений в VSCode (https://github.com/neinAlkem/minimalist-vscode + https://github.com/HuXn-WebDev/Cleanest-VSCode-Setup), и гайды idea-like редакторов (https://handbook.gitlab.com/handbook/tools-and-tips/editors-and-ides/jetbrains-ides/setup-and-config + https://howik.com/jetbrains-customization). Также рекомендую курс от Никиты Соболева по настройке VSCode. Но допустим вы преисполнились и начали на бумаге с перьевой ручкой писать код. Ваша мусорка с комочками бумаги — BitBucktet и доска со стикерами — реляционная БД. Всё, можно покорять вершины разработки и брать куча проектов, раскидывая своей опытностью и экспертизой их по порядку?

Многозадачность

Чаще всего, разработчики стремятся получать больше (денег или проектов или стресса?) и помимо основной занятости, берут другую. В итоге помимо основной работы со своими процессами, тайм- и такс-менеджментом добавляется ещё одна. Причём, чаще всего, мы подразумеваем процессы почти везде не идеальны и тем более они не подточены под совмещению разработчиком более 1-ой работы. Вы можете думать, что просто «поделите внимание», но на практике когнитивная система устроена так, что переключение контекста в вашей голове не бесплатно. Чем больше проект и больше от него перерыв, тем сложнее возвращаться в контекст. Каждое переключение — это не просто «перескочил из одного окна в другое», это потеря состояния рабочей памяти, заново выстраивание модели задачи в голове, заново вхождение в код. В итоге многозадачность превращается в псевдопродуктивность: вы вроде бы постоянно заняты, но ценности производите меньше.

Вам не нужно сжимать руку на пульсе

Каждый алерт - это триггер, который ломает ваш поток. Независимо от того, важен ли он или нет, ваш мозг отреагирует. Даже если вы не открыли уведомление, ваш фокус уже ушёл. В теории алерты должны помогать быстрее реагировать на проблемы, на практике же они превращаются в постоянное дергание, зачастую по вопросам, которые не требуют немедленного вмешательства. Я видел проекты, где Slack-бот или ТГ-бот дублирует алерты из мониторинга, и команда работает не над задачами, а над тушением фиктивных пожаров. Настоящая оптимизация - это правильная настройка приоритетов: что должно реально вызывать немедленную реакцию, а что может уйти в отложенный бэклог.

Хорошая аналогия — регулярные негативные новости с радио или телевизора, который вроде только был фоном, но сильно нас в течении времени истощает. Это тот же тип фоновой когнитивной нагрузки, что и при работе с запутанным легаси-кодом: кажется, что вы просто смотрите на код, но ваш мозг постоянно и безуспешно пытается выстроить его непонятную логику, что приводит к такому же ментальному истощению, как и бесполезный информационный шум.

То же касается и мессенджеров. На деле мессенджер превращается в постоянный шум, где важные сообщения теряются среди мемов, обсуждения футбола и вечного «а кто в офисе завтра?». Более того, сама модель «мгновенного ответа» убивает концентрацию: у вас всегда есть ощущение, что вы должны быстро отреагировать. Рабочий день превращается в лоскутное одеяло из мини-контекстов, и к вечеру у вас ощущение, что вы «весь день отвечали», но не сделали ничего. Я не имею подобной экспертизы, чтобы ставить под сомнения корпоративные стандарты индустрии, но чувствую, что стоит во время работы ограничиваться исключительно одним каналом связи, и желательно чтобы он был выделен исключительно для работы.

Приложенные усилия важнее времени

Что на счет браузера? В нём и код, и таск-трекер, и CI/CD, и документация, и YouTube, и личная почта. Проблема в том, что браузер превращает ваш рабочий процесс в хаотичный набор вкладок. Вы открыли документацию - потом ещё одну вкладку для проверки кода в проде - потом случайно отвлеклись на новость - и уже через 20 минут вы забыли, с чего начинали. Большинство разработчиков держат десятки вкладок открытыми «на потом», но это «потом» никогда не наступает. В итоге браузер становится центром не работы, а расфокусировки.

“Это что, мне теперь нужно уделять каждому курсу или книге полный фокус, когда я могу параллельно изучать что-то другое?”. Каждый разработчик понимает, что учиться нужно. Но в многозадачном режиме обучение превращается в фоновый процесс: курс куплен, книга открыта, вкладка с видео лежит в браузере - но сил на глубокое изучение нет. Получается имитация обучения: вы постоянно что-то «пробуете», «смотрите», «откладываете», но без системного подхода прогресс минимален. Даже эту статью большинство людей бегло читают в перерыве от чего- то, нежели осознанно будут пробовать ставить под вопрос и/или анализировать её. Да, я согласен, много чести для этой статьи уделять столько вашего времени, но я хочу донести то, что когда у вас избыток, вы не уделяете почти никакого внимания, и наоборот, когда вы читаете буквально 1 статью в месяц, то волей не волей будете ее лучше усваивать и самое главное, заранее осознанно подходить к этапу подбора. Возможно эту статью вы читаете из-за её заголовка, кол-ва просмотров, кол-ва комментариев или рейтинга, т. к. сейчас ваш workflow настроен на это. Но в ваших силах сделать так, чтобы ваш workflow привычные действия подстраивал по-иному.

Настоящее обучение требует сосредоточенности и явного выделения времени, иначе оно растворяется в том же шуме, что и все остальные процессы. Даже самый «лучший» и «качественный курс ничего не даст, если на него явно не выделить ресурсы (тут речь не про время (!!!)). Процесс обучения должен измеряться в кол-ве ваших усилий, которые вы тратите в процессе изучения, нежели в абстрактных человекочасах обучения и тем более, «качестве материала». Лично у меня нет проблемы в том, что найти «качественный» материал, у меня как и всю жизнь проблема в том, что качественное освоение материала требует качественных усилий. Не прослушать статью на 2х скорости, параллельно читая корпоративную почту на пробежке. Я могу за кратчайшие сроки поглотить и книги, и курсы, и статьи, но это мне не даст того же импакта, как если бы я уделял должного времени каждому из них.

Ваше внешнее, не рабочее, влияет на внутреннее, рабочее

Бытовые проблемы (семья, уборка, доставки, готовка еды, выходные и многое другое) неотъемлемые части нашей жизни. И даже полезны в контексте работы, т. к. позволяют отдохнуть от долгих задач (мы все понимаем, что работать 8 часов подряд тяжело). Но каждая мелочь - это переключение контекста, и чем больше таких переключений, тем меньше остаётся глубокого фокуса. Когда всё это накладывается на и без того перегруженный рабочий процесс, вы работаете вечно, но ощущаете, что никогда не работаете по-настоящему. Тут рекомендую перед каждым переключением доделывать таску до логического чекпоинта

Ну и конечно же, пару слов о формате работы. Я большую часть своего рабочего опыта в WFH. И я понимаю что это очень сложно, даже с учётом того, что я и занимаюсь тайм-менеджментом, и разделяю личную рутину, и налаживаю локально рабочие процессы. Поход в офис, как поход в спортзал. Статистически, в спортзале люди чаще всего занимаются тем или иным спортом, и идут туда с определенном настроем. В офисе также. Там есть рабочая атмосфера, мы понимаем что идем туда, чтобы потратить ресурсы на тот продукт, который мы разрабатываем. Но с удалёнкой всё не так. Вы, безусловно, можете заниматься спортом и дома, но статистически, люди это делают не так часто, нежели со спортзалом . Из этого не следует, что удалёнщики не работают, но я уверен, что без должных усилий, граница между «работой» и «не работой» будут размываться, что уже влияет на качество вашей работы. Кто-то себе выделяет рабочий кабинет и рабочие часы, в которые нельзя беспокоить. Кто-то арендует себе кабинет или офис. Кто-то ходит на коворкинги, библиотеки или кофейни. Кто-то себе выстраивает дом, как рабочее пространство. Способом много, но я считаю, что и тут разделение ответственности гораздо важнее, нежели все перечисленные проблемы вместе взятые. Т.к. если вы уже находитесь в обстановке 1 на 1 со своими рабочими задачами и нацелены то, чтобы их решить, то вы по-умолчанию уже выжмите свой максимум, т.к. наша открытость и готовность первичнее. Явное разделение обстановки - это не панацея или строгое правило, но гарантия самому себе что у вас на данный момент работа в приоритете. Я сразу понимаю, что каким бы я себя осознанным и ответственным не считал, мне важно подкреплять свои намерения подобными внешними действиями. В противном случае, в глубине души я остаюсь дома ради чего-то: чтобы отдохнуть, чтобы меньше работать и так далее

Пару слов в завершение

Эта разговорная статья - не манифест против технологий и не призыв вернуться к «Блокноту» и перфокартам. Это приглашение к рефлексии. Мы живём в эпоху изобилия инструментов, которые обещают нам немедленную продуктивность. Но парадокс в том, что, стремясь оптимизировать каждую мелочь, мы часто создаём систему, враждебную глубокой работе.

Красной нитью через все примеры — от LLM и IDE до многозадачности — проходит простая мысль: привычка диктует workflow, а не удобство инструмента. Мы сначала бессознательно привыкаем к подсказкам, дашбордам и уведомлениям, а затем уже не можем без них работать, оправдывая это «оптимизацией». Но настоящая оптимизация — это не добавление, а вычитание. Это поиск и устранение всего, что мешает главному: пониманию кода и решению задач.

Кажущаяся простота оборачивается избытком вкладок, уведомлений, подсказок и вариантов от LLM. Вспомните ощущение от работы с запутанным кодом: ментальная тяжесть, вызванная необходимостью держать в голове клубок противоречивых связей. Примерно такую же, но неявную нагрузку создаёт и наше перегруженное окружение. Каждый алерт, каждая лишняя панель в IDE и каждый поток сознания от LLM, который не настроен под ваш контекст, — это тот же "ментальный мусор", что и плохо структурированная кодовая база. Он незаметно ворует самые ценные ресурсы: внимание и когнитивные силы

Минимализм в настройке окружения про стресс-тест для ваших навыков и единственный способ обнаружить «белые пятна», которые маскируются костылями автодополнения, AI и бесконечными вкладками. Когда вы заставляете себя обходиться без них, вы понимаете, что на самом деле знаете, а что лишь иллюзия знания, созданная умным инструментом.

Поэтому главный вопрос, который стоит задать себе после прочтения, звучит так: «Что в моем рабочем процессе я делаю по привычке, а что — по необходимости?»