Хороший инструмент должен быть незаметен, и разработчикам следует к этому стремиться.

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

Я же хочу, чтобы мои инструменты не создавали для меня «увлекательные» головоломки, а просто незаметно делали своё дело.

Война текстовых редакторов

Возьмём в качестве примера Vim¹. Я постоянно вижу, как некоторые хвалят его не за реальные достоинства, а за недостатки, которые человек воспринимает как загадку, которую ему интересно решить.

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

Я не хочу сказать, что редакторы не играют важной роли для вашего рабочего процесса. Я лишь ставлю под вопрос ту преданность, с которой люди относятся к инструменту только потому, что он дарит им некий «хакерский вайб». А ведь именно это, по сути, и затягивает новичков в vim или emacs.

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

Я осознаю, что и в моём любимом Sublime есть немало проблем, но я не пытаюсь выставить их как увлекательные головоломки. Меня просто раздражает отсутствие реально нужных мне инструментов, из-за чего приходится писать плагины или использовать отдельную программу для преобразования текста нужным мне образом.

Этим редактором я пользуюсь уже 15 лет и выбрал его по нескольким причинам. Его хоткеи включают в себя все стандартные комбинации из ОС (что снижает мыслительную нагрузку при переключении между приложениями). Ещё в нём есть мультикурсоры, которые в 99,999% случаев удобнее макросов², поскольку дают прямую обратную связь. Да и в целом Sublime не создаёт мне лишних загадок, которые приходилось бы решать.

По моему опыту, редакторы вроде vim лучше подходят для простого редактирования, но хуже справляются с масштабными операциями — и я не имею в виду операции типа grep. Поэтому я и прикипел к Sublime. Сколько работал с vim, никогда не получал той же продуктивности от его системы vim motions, какую мне обеспечивает Sublime. И дело здесь не в недостатке опыта.³ Поскольку я практически никогда не пишу код в терминале, потребности в заточенном под него редакторе у меня нет.

Если кто-то находит vim, emacs или любой другой редактор поистине удобным и продуктивным, то я не стану осуждать их выбор. Человеку, в принципе, комфортнее работать с чем-то ему знакомым и привычным. Но в случае фанатичных людей такое тесное знакомство с инструментом только ослепляет к его недостаткам, которые начинают чествоваться как некие занятные игры.

Инструменты как часть идентичности

И эти споры о предпочтительном редакторе становятся религиозными отчасти потому, что своим выбором вы как бы водружаете флаг, отражающий вашу идентичность. «Хакерский вайб» здесь оказывается уже не просто эстетическим штрихом. Это племенной сигнал, и он является реальной ловушкой. Как только вы начали ассоциировать себя с инструментом, признание его недостатков становится признанием собственных. Поэтому люди не просто терпят эти недостатки, они их защищают и в конечном итоге чествуют как достоинства. Невозможно вести объективный диалог об инструменте с человеком, который сделал этот инструмент частью своей идентичности.

Ощущение продуктивности не равно реальной продуктивности

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

Если вашей целью действительно является продуктивность, то нужно пересмотреть собственный взгляд на эти вещи и постараться понять, что именно её вам даёт. Уверен, вы удивитесь, когда откроете глаза.

Терминал против графического интерфейса

Ещё один пример — это когда люди утверждают, что приложения для терминала лучше тех, что работают через графический интерфейс (GUI). Если вы сидите в терминале днями напролёт, то его преимущество становится бесспорным, но большинство программистов не проводят в нём столько времени.

Один из аргументов тех, кто заявляет о превосходстве TUI над GUI, звучит как: «В них нет навигации с клавиатуры».

Хорошо. Но это не делает приложения с GUI по определению плохими. Это лишь означает, что им недостаёт возможности перемещения с помощью клавиатуры. И нет ничего архисложного в том, чтобы восполнить этот недостаток. Просто большинство разработчиков этим не заморачиваются, зачастую потому, что просто не осознают, насколько эффективнее такая навигация в сравнении с постоянным перекладыванием руки на мышку. Если бы в качестве аргумента звучало, что конкретное приложение с TUI лучше своих GUI-альтернатив, то это уже ближе к истине. Но вот утверждать, что TUI по своей природе лучше GUI, это всё же заблуждение.

Причём заблуждение общее. Люди смотрят на текущее положение дел в той или иной категории инструментов и предполагают, что их текущие недостатки являются неотъемлемыми, хотя на деле никто просто не брался эти инструменты доработать.

Недостаток популярности Linux в качестве десктопной системы

«Год Linux на десктопе всё ещё не наступил⁴ (а на дворе уже 2026)», и отчасти это объясняется фундаментальной причиной: многие пользователи этой ОС любят ковыряться в конфигурационных файлах, подстраивая систему под себя — это их личная «увлекательная» загадка.

Я и сам прошёл через этот этап. Но со временем для меня стало важнее, чтобы система просто работала. Тратить часы (а то и дни) на настройку я больше не желаю. Мне нужно, чтобы базовые установки были достаточно хороши и просто работали. А когда мне вдруг нужно подстроить какую-то деталь, на это должны уходить считаные секунды.

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

Вся эта излишняя сложность⁵ характерна для большинства программистов и технарей, так как придаёт им странное ощущение безопасности.

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

Высокий порог освоения как «фича»

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

Заключение

В этой статье я высказался не против каких-то отдельных инструментов, а против модели мышления. Можете использовать хоть vim, хоть emacs, хоть Sublime — главное, чтобы этот инструмент незаметно растворялся на заднем плане, не отвлекая вас от основной работы. В этом и заключается весь тест, и он у каждого свой. Я критикую не конкретный выбор, а те мифы, которыми он обрастает: когда люди преподносят недостатки как фичи, вложенные усилия по преодолению проблем — как заслугу, или даже делают инструмент частью самих себя.

Самый очевидный признак того, что инструмент действительно вам служит — это когда вы перестаёте его замечать. Тогда вам уже не нужно чествовать его недостатки, потому что вы не превращаете их преодоление в своё увлечение. Вместо этого вы лишь слегка раздражаетесь и находите обходные пути. Вы не бросаетесь слепо на его защиту, потому что на кону не стоит часть вашей личной идентичности. И вы не принимаете ощущение собственной смекалки за показатель продуктивности, потому что на личном опыте ощутили разницу.

Так что наслаждайтесь вашими инструментами всеми возможными способами. Главное — будьте честны насчёт того, что в них действительно хорошо, а что вы сами себя уговорили полюбить. Лучший инструмент — это не тот, вокруг которого сложилась красивая история, а тот, про который вы забываете в процессе работы.

Хороший инструмент должен быть незаметным, и создание таких инструментов является главной задачей разработчика.

Сноски

1. Это лишь пример, который применим и к другим редакторам. ↩

2. За последние лет десять макрос мне понадобился всего пару раз. Причём в обоих случаях его настройка заняла больше времени, чем я бы потратил на написание скрипта. ↩

3. Хотя с годами я многое из vim motions позабыл, потому что пользуюсь этими командами редко, да и не пригождаются они. ↩

4. Я понимаю, что здесь обязательно возникнут реплики в духе «Linux — это ядро, а ОС — это [вставьте имя дистрибутива]». Простите, но большинство людей рассуждают о Linux не так, и меня не волнует ваше буквоедство, от которого нет толку. Особенно с учётом того, что для критики этого тезиса вам сначала следовало бы понять, о чём вообще идёт речь. ↩

5. Характеристики, которые проявляются у объекта условно и могут меняться без изменения его основной сути. ↩