mayton2019

FILE *handle = fopen("filename", "r")
возвращает файловый указатель. Если открываешь на чтение - то он обычно null если файла
не было или была какая-то другая ошибка. Детали по ошибке выдает другой системный вызов errno, streeror или
что там еще есть другое не помню точно.

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

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

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

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

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

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

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

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

Вопросы.

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

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

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

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

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

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

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

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

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

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