mayton2019

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

По поводу огранчителей. Это не техническая задача. Она - организационная и называется тайм-менеджмент.

Есть техники типа "помидоро" и они позволяют лимитировать время на короткие задачи. Почему помидор?
Это - кухонный таймер. В виде овоща. Заводной. Заводишь его на 45 минут. Работаешь. Прозвучал дзынь.
Встал. Отдохнул 5-10 минут. Погулял. И снова. Время и график подбирается индивидуально. Есть техники
поощрения. Когда ты с утра делаешь самую неприятную работу и потом себя награждаешь. Покупаешь
кофе с пироженкой. Короче техник много. Ищите литературу по ТМ.

Софт никакой ставить не надо. По себе знаю это бесполезно. Любые блокеры рабочего стола
создадут проблемы самому тебе когда тебе СРОЧНО надо будет поднять какие-то бумаги по бизнесу
а тут - хопа... блокер. Поэтому ты сам эти блокеры сразу выключишь. При первом кейсе. Сам-же
автор пишет что даже снос игры ему не помогает. Снова ставит. Поэтому и нет смысла в блокерах.

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

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

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

Вопросы.

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

Сможет ли такой наивно-обученный специалист (НОС) потом пояснить ПОЧЕМУ? Почему он пишет 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% программистов - середнячки и звезд с неба не хватают.
Поэтому для них фреймворк - является предпочтительной методикой. И код с фреймворком
скорее всего будет быстрее чем при прямом кодировании на той-же выборке кодеров-середнячков.