mayton2019

Я думаю такое возможно. Это похоже на обучения языку ребенка. Ребенок слушает. Потом обобщает.

Вообще способность мозга к обобщению просто поразительна. Я думаю что программирование
таким образом освоить можно. К примеру ты сначала смотришь как пишут код другие. Потом
пишешь сам.

Вопросы.

Будет ли такой режим обучения эффеткивным? Тут я не знаю. Для ребенка - безальтернативно.
А для взрослого изучающего программирование ... ну такое.

Сможет ли такой наивно-обученный специалист (НОС) потом пояснить ПОЧЕМУ? Почему он пишет Set[Int] вместо
Array[Int]. Это - очень важный вопрос. Ему ведь в процессе обучения предьявляли только семплы
кода но не объяснили причит почему массив в одном случае заменили на сет а в другом случае
почему-то проигнорировали это правило.

Будет ли такой наивно обученный специалист знать стек вплоть до основ железа и системотехники?
Предполагаю что нет. Ну вобщем все завист от уровня технического любопытства. Для кейса который
привел автор - все очень печально ИМХО. НОС не будет заинтересовать копать стек клубже
чем технологии браузера и HTML. Ему ведь безразлично что стоит в основе.

Я вобщем -то в программирование пошел потому что с детства был любопытен к технике. И
именно такое топливо дает бесконечный энтузиазм в освоении смежных техник.

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

Из резюме надо убрать такие слова как "не готов".
Это можно потом выяснить в процессе устного общения. Но резюме должно быть более открытым чем закрытым.

Для скиллов необходимо указать уровень (junior/middle e.t.c).
И не стоит писать много скилов. Иначе складывается впечатление что
кандидат - многостаночник и эникейщик.

Про освоение инструментов писать не надо. Мы все этим занимаемся каждый день.
Это и есть собственно наша главная работа - быстро освоить что-то новое.

Английский надо поднимать хотя-бы до буквы B.

Далее. Не для резюме. Для вопросов-ответов. Вот если ты написал что есть базовые знания back-end.
То ты должен быть готов рассказать архитектуру вашего backend. И перечислить стек технологий.
И нарисовать диаграммы. Тоесть любое дополнение или случайное слово в резюме будет
поводом для "поговорить". Поэтому если ты точно-точно имел базовые знания - то расскажешь.
Если нет - то лучше убери это слово.

Обычно в проекте заводят отдельный модуль. Версионный контроль для БД. Можно на базе
liquibase или flyway. Можно на базе каких-то Go-технологий.

Но суть такова. Хранимка устанавливается синхронно с обновлением версии комплекса. Как
часть установочного pipeline. И далее из кода ты ее просто вызываешь по имени.

Ответ - и да и нет.

Обычно классический ЯП - предполагает прямое (директивное) управление процессом.
И качество оптимизации будет сильно зависеть от того как программист проработал весь прямой ход алгоритма.
В том числе работу с I/O и сетью.

Фреймворк - это ограничитель, который очень строго лимитирует присуствие программиста в результирующем
коде. В идеале программист делате только хендлеры. Или лямбды. Как в Inversion of Control.
Это позволяет хорошему фреймворку сильно соптимизировать поток выполнения базируясь
на том что I/O и сеть будут обеспечиваться фреймворком а программист будет вставлять только лямбды.
Кроме сети и ввода-вывода фреймворк может обеспечивать пул объектов (соединения с БД)
и типичные шаблоны обработки ошибок (retry-pattern) перформанс (cirquit-breaker) и
рейт-лимитеры и троттлинг.

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

Но мы исходим из предположения что 80% программистов - середнячки и звезд с неба не хватают.
Поэтому для них фреймворк - является предпочтительной методикой. И код с фреймворком
скорее всего будет быстрее чем при прямом кодировании на той-же выборке кодеров-середнячков.