Хорошие инструменты невидимы 2026-07-10

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

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

Я не хочу, чтобы мои инструменты были «веселыми». Я хочу, чтобы они были невидимыми.

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

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

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

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

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

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

Я пользуюсь Sublime уже 15 лет. Это мой любимый редактор по нескольким причинам: его горячие клавиши являются надмножеством клавиш графической ОС (что сводит к минимуму ментальное переключение контекста при переходе между приложениями); мультикурсоры действительно лучше макросов в 99,999% случаев (мне кажется, за последнее десятилетие макрос в Sublime мне «понадобился» всего дважды, и в обоих случаях настройка макроса заняла больше времени, чем если бы я просто написал скрипт для решения той же задачи), поскольку они дают мгновенную визуальную обратную связь; и он оставляет мне меньше всего «головоломок» в процессе редактирования. Я нахожу, что какой-нибудь vim лучше справляется с базовым редактированием, но хуже подходит для массовых операций (и я имею в виду не grep-подобные операции) — именно поэтому я так долго остаюсь на Sublime. Я также никогда не считал, что перемещения в vim (vim motions) делают меня намного продуктивнее, чем мой рабочий процесс в Sublime, и дело тут не в отсутствии попыток или привычки (честно говоря, за эти годы я забыл большую часть своих знаний о перемещениях в vim, потому что не практикую их регулярно, да мне это и не нужно). И поскольку я практически никогда не пишу код в терминале, потребность в терминальном редакторе у меня практически отсутствует.

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

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

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

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

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

Если ваша цель — действительно продуктивность, поставьте под сомнение свои взгляды на этот счет и попытайтесь понять, что на самом деле делает вас продуктивнее. Результаты вас удивят.

Терминальные интерфейсы (TUI) против графических (GUI)

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

Один из аргументов сторонников TUI против GUI звучит так: «Я не могу управлять графическими приложениями только с клавиатуры».

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

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

(Не)популярность Linux как десктопной системы

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

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

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

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

Обеспечение хороших настроек по умолчанию — это фундаментальная обязанность создателя инструмента. У нас, разработчиков инструментов, есть тенденция перекладывать бремя на пользователя: настроить, докрутить, изучить. Большая часть этого бремени на самом деле является отказом дизайнера принимать решения. «Высокая конфигурируемость» часто служит лишь оправданием для выпуска продукта без какого-либо четкого видения, перекладывая итоговую работу на плечи пользователя. Хорошие настройки по умолчанию — это форма уважения к времени пользователя: создатель инструмента думает один раз, чтобы тысяче пользователей не пришлось делать это каждому по отдельности. И часть проектирования инструмента заключается в том, чтобы предусмотреть лазейки; эти лазейки существуют для явного меньшинства, которому нужно что-то нестандартное; они не должны заменять собой правильную реализацию базовых сценариев использования.

Крутая кривая обучения как «фича»?

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

Заключение

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

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

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

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