Каждый ІТ-специалист в повседневной работе использует множество сложнейших инструментов. Эффективность работы часто зависит от умения пользоваться этими инструментами. Всё начинается еще с редактирования текста—в любой IDE есть много горячих клавиш, функций, кнопочек которые призваны упрощать жизнь.
Каждый язык, фреймворк и технология тоже содержит кучу вещей, которые помогают в работе и повышают эффективность решения, но в замен требуют инвестиций—обучения, чтения документации, экспериментирования с параметрами и так далее.
При этом уровни этой "помощи" в разных инструментах реализованы по-разному. Например, языки программирования со сборщиком мусора очень-очень помогают программисту бороться с утечками памяти. Языки без null помогают бороться с пустыми ссылками. Раньше java когда выдавала NullPointerException то не говорила какой именно метод это вызывал—показывала лишь строку. Много лет понадобилось дизайнерам JVM чтобы добавить и эту информацию в трейс—а это отлично поможет разработчкам.
У баз данных есть EXPLAIN PLAN который покажет что с вашим запросом пошло не так. Базы без этой или похожей возможности будут больше полагаться на человека.
Я считаю что хороший инструмент должен максимально ограничивать пользователя в попытках выстрелить себе в ногу и помогать ему избежать ошибки, а если она случилась—то помогать её исправить. Например, в mysql можно включить slow query log и смотреть на все запросы которые выполняются дольше чем X секунд.
В сложных инструментах легко запутаться и ошибиться. Например сделать ерунду в k8s—проще простого. А вот накосячить в Heroku—намного сложнее. Потому что первый дает очень большую свободу действий и позволяет строить самолёт, а второй—делает лишь крошечное подмножество функций кубера, поэтому там особо негде ошибаться.
Люди всегда остаются людьми. Большинству нужно просто сделать свою задачу, и они часто не готовы инвестировать время в обучение. Поэтому берутся неподходящие инструменты, не читаются доки, делается абы как а потом пишутся failure stories как не получилось что-то внедрить. Или наоборот, success stories когда инструмент просто начинают использовать правильно.
В этой шумихе очень легко обозвать человека который не разобрался неосилятором. Ты просто не прочитал доку. Ты просто применял не туда куда надо. Ты просто не разобрался как оно работает внутри. Ты просто не осилил.
Я считаю что это такой себе victim blaming в мире от IT. Конечно все должны понимать что держат в руках. Очень часто когда это молоток, то вокруг всё кажется гвоздями. Но вину за неправильное использование я в первую очередь полагаю на инструменты сами по себе. Хороший инструмент помогает, подсказывает, тыкает "вот тут неправильно делаешь" и обучает пользователя. Плохой—кидает в океан из segfaultов.
Простейший пример—в RoR логируется каждый HTTP-запрос: метод, параметры, сколько времени заняло выполнение, какие SQL запросы были сделаны, сколько ушло на базу, на рендеринг и так далее. Всё это разработчик видит сразу же в консоли. А в Spring Boot вы не увидите ничего. Надо заморачиваться и настраивать правильное логирование, но в итоге оно все равно будет хуже чем в RoR.
Кто из двух разработчиков будет эффективнее? Тот, кому инструмент помогает, или тот, кто неосилил прочитать доку и настроить базовые вещи сам? Когда что-то будет тормозить то первый сразу увидит проблему в логах, а второй может и неосилить! И тогда мы будем в чатах и форумах козлить его "RTFM, нуб", хотя на самом деле человек не виноват.
Виноват инструмент.
Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred
