🙃 Когда пригодится, тогда и разберусь

Это классический подход Just-in-Time Learning. В некотором смысле, он действительно рабочий. Однако, работает он для библиотек или фреймворков, которые ты видишь первый раз, но проваливается на фундаментальных вещах

1. Цена ошибки

Когда проблема уже появилась на проде — учиться уже поздно, надо тушить пожар.

Когда прод лежит, а клиенты теряют деньги, у тебя нет времени читать документацию про GC и экспериментировать. В этот момент ты либо знаешь, куда смотреть, либо панически гуглишь симптомы, пока бизнес теряет бабки. База нужна, чтобы в критической ситуации действовать рефлекторно, а не научно-исследовательски.

2. Построение фундамента

Если ты узнал про проблему постфактум, значит, ты уже заложил кривую архитектуру.

Проблема такого подхода в том, что когда "проблема появилась", часто выясняется, что архитектура была выбрана неверно полгода назад из-за незнания базы. И теперь "решить проблему" = "переписать половину проекта". Знание кишок помогает не совершать дорогих ошибок на старте, а не героически исправлять их потом.

3. Слепое пятно (Unknown Unknowns)

Ты не можешь нагуглить решение, если не понимаешь природу проблемы.

Чтобы "сходить и получить знание", нужно знать, что именно искать. Если ты не понимаешь, как работает рантайм, ты будешь гуглить "почему тормозит Go", а не "как уменьшить stw pause". Ты увидишь симптом, но даже не поймешь, в какую сторону копать. База дает тебе словарь и карту местности.

4. Парадокс невидимой компетенции

— А сколько раз тебе на практике пригодилось знание устройства мапы?

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

Одна из основных причин — знание базы часто работает превентивно и бессознательно.

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

Это касается любой базы — не только runtime:

- Алгоритмы: ты автоматически заводишь мапу вместо перебора огромного списка, потому что видишь O(n) vs O(1)
- БД: ты сразу проектируешь индексы под запросы, а не добавляешь их потом, когда таблица тормозит на миллионе строк
- Сети: ты не ждёшь, пока connection pool упрётся в лимиты — ты закладываешь их с запасом

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

Инженер, который не знает базу, героически тушит пожары, которые сам же (или его коллеги) и разжег полгода назад. Инженер, который знает базу, просто скучно пишет код, который работает годами.

————

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

JIT-learning работает для поверхностных знаний (синтаксис, апи либы), но не работает для глубоких (конкурентность, память, сеть). Глубину нельзя освоить за 15 минут, когда горит дедлайн.

Да ты просто гейткипер! Сам всё выучил и не хочешь нас пускать в профессию! 😡

Значит ли это, что без знания кишок рантайма вас не возьмут на работу? Конечно, нет. Для старта карьеры и типовых задач поверхностных знаний достаточно. Никто не требует от джуниора пересказывать исходники аллокатора памяти. А если требуют, то напрасно — я бы не стал.

🟢Речь не о входном билете в профессию, а о потолке вашего роста

Невозможно выучить всё заранее. Но есть принципиальная разница в майндсете:

➡️ "Я не буду это изучать, пока оно не сломается" — это риск стать специалистом с "10 годами опыта", который на самом деле просто повторил один год опыта 10 раз. Ты остаешься исполнителем простых задач.

➡️ "Я изучаю базу, чтобы понимать суть" — это путь инженера. В конечном итоге вы сможете решать проблеым, которые не гуглятся вообще.

Да, учиться надо в процессе. Но лучше учиться на опережение, а не только по нужде.

#guide