На тему программирования видео принципиально не смотрю, а вот мотовидео помногу регулярно, и так удачно...
"Как стать программистом в 30+"
Очень честно и реалистично, рекомендую!

В продолжение темы, авторитетные люди рекомендуют:
"Pragmatic System Design"
From preparing for System Design interviews to Architecting Real World Systems

Системы типов современных языков даже уровня Java тьюринг-полные, поэтому если научиться правильно готовить статическую типизацию, то она может работать как юнит-тесты со 100% покрытием.

По Пирсу хотя бы, система типов -- это синтаксический метод доказательства отсутствия определённых поведений программы.

Отговорил знакомых ребят от рефакторинга большого легаси-проекта)))
В их понимании рефакторинг кода -- это мартинфаулерщина, ну и что будет получено в итоге? Кривизна тотальная так и останется, только теперь будет вид в профиль. Рефакторинг --- это формальные математические приёмы; это по Фаулеру их множество, написаны толстые книги, курсы хорошо продаются, однако 97% всех их возникает как комбинация небольшого числа ключевых строительных блоков. Например, один из довольно популярных приёмов, который я и сам нередко использовал -- это replace type code with subclasses, описанный "отцом рефакторинга" Уильямом Опдайком в его диссертации 1992-го года ( версия для малышей ).

Но я больше не буду этот приём применять и рекомендовать потому, что теперь знаю, что это всего лишь частный случай более мощной техники, работающей с функциональностью как с типом данных (на эту тему в СильныхИдеях будет отдельный материал).

За четыре месяца из джуниоров в миддлы, возможно ли?
Digital Tutor , 10+ лет разрабатывающийся военным агентством передовых исследований DARPA для продвинутого обучения айтишников, сегодня демонстрирует удивительные результаты.

Ребята, занимавшиеся с этим AI, превзошли в решении профильных задач не только тех, кто обучался параллельно с ними классическим способом на протяжении 16 недель, но и даже экспертов в данной области с пятилетним опытом!

Это хороший пример экспоненциального выигрыша при использовании AI: страна с таким умным софтом может готовить хороших программистов существенно быстрее других (особенно в сложных областях), ускоряя своё развитие в целом. На фоне например панического хантинга метой массы хороших программистов за двойные зарплаты, когда сильные разработчики окончательно вымываются из многих критически важных областей, где не могут платить 300k/s.

P.S. Ну по сути это работа с индивидуальным ментором, которая всегда была несравненным топом по продуктивности. Просто живые менторы не масштабируются, а вот AI — легко.

Синдром самозванца действительно частая проблема; решать её правильно так, что надо просто качественно разобраться в темах, которые вызывают у вас этот синдром. Конечно, если механически использовать веб-фреймворк для создания онлайнового просмотрщика котиков, не понимая, а как подобные фреймворки устроены внутри (хотя это тоже очень относительно, на днях напишу подробный пост в паблике), как работает ORM и т. д., ну... естественно, вы пока и есть самозванец :)

Сермяга в том, что каждое ваше проектное решение, в идеале каждая ваша строчка кода, должны на 100% соответствовать известным требованиям программной инженерии, опирающимся на оригинальные монографии признанных мировых авторитетов в computer science. Сегодня ими отлично покрываются 97% всех прикладных тем в разработке.

По каждой сроке вашего кода, по каждой сигнатуре, по каждому классу, по каждой абстракции вы должны
a) хорошо понимать, зачем именно она нужна в проекте,
b) хорошо понимать, почему сделано именно так,
c) обязательно подумать, а нельзя ли сделать получше?

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

Классная подборка игр для программистов , но в ней (вроде) не упомянута "Move Code Lines", которую прошёл с огромным удовольствием. Она конечно "для начинающих", но очень приятный и удобный интерфейс, вообще идеально сделан геймплей, ну и немного голову понапрягать тоже получается по ходу.

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

А вот тем, кто уже уверенно пишет скрипты на сотню строк, вполне можно потренироваться, задачки в конце уже довольно сложные. Ну, impossible реально хороши, на уровне литкода )))

Стоит ли "тренироваться в программировании" на играх типа Factorio или Satisfactory? Не знаю, мне лично крайне нравится Automation Empire в этом жанре, и недавно ещё смешная Timberborn (империя бобров :) вышла, тоже весьма залипательна. Возможно, стоит поиграть с прицелом не столько на программирование/проектирование, сколько на техническое архитекторство -- именно на создание в игре максимально эпической системы со всеми фичами которые только есть, чтобы прочувствовать на собственной шкурке типичные паттерны кривизны крупных проэктов :)

P. S. Имею в виду, что для архитекторства полезно уметь регулярно выстраивать с нуля (а не по подсмотренным гайдам) такие большие системы из логических элементов, со сложными взаимосвязями внутри (которые все в голове не удержишь) так, чтобы
a) они работали стабильно и сбалансировано, а не уходили со временем вразнос, и
b) это умение прокачивать на разных играх такого жанра, когда правила довольно сильно различаются.

Почему не стоит перебирать в резюме по каким-то нешаблонным темам?
Ну, если вы давно работаете в Java-бэкенде, а в резюме у вас много странных слов вроде Haskell или теоретико-категорной семантики, вот в чем проблема...

Даже если это работает... это звучит неправдоподобно.

Мне например сильнее всего (вообще несравнимо ни с какими другими темками, в десятки раз) повысить продуктивность и качество повседневного программирования помогло изучение математики (теории типов прежде всего). Но я гарантирую, что если вы броситесь изучать новый Розеттский камень или хотя бы TAPL, результат будет негативный: вы испортите отношения с окружающими, и скорее всего провалите даже скромные текущие проэкты... Уже имел печальную честь наблюдать (кстати тренд): чем зашкварнее текущая работа, тем сильнее рвутся в ФП, HoTT и все эти темы. Ну, это хорошо объяснимо к сожалению.

Когда стоит начинать изучать это всё? Ну, стартовый порог (абсолютно обязательны оба пункта):
a) проект (подсистема в проекте) от 100,000 строк кода под вашей полной ответственностью внутри команды, успешно проживший в эксплуатации хотя бы пару лет, и
b) достойная оплата за это.

Потому что, к сожалению, для большинства людей... упоминание математики звучит слишком круто, чтобы быть правдой...

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

Правдоподобность имеет огромное значение.

4 характеристики плохого программиста:
1) в его коде находятся ошибки;
2) ошибки в его коде находятся часто;
3) код, в котором часто возникают ошибки, программист называет запутанным и непонятным;
4) в ошибках и запутанности кода всегда виноват кто-то другой или что-то другое (архитектор, тимлид, менеджеры, уволившиеся программисты, разработчики-коллеги, пользователи, заказчики, обновлённые фреймворки, патчи безопасности, плохая документация...), только не он сам.

Прогресс в применении формальных подходов практически всегда достигается прежде всего за счёт сокращения/свёртки синтаксиса в сторону выразительности; математика в этом направлении всегда развивалась. Абсолютный контр-пример -- это паттерны проектирования, количество которых только растёт и охватывает всё больше областей ("Patterns in Functional Programming", Linux kernel design patterns, SQL Design Patterns...), надо толстенные скучные учебники изучать чтобы просто познакомиться с этим всем. Хотя в оригинальной работе 1993-го года Банды четырёх речь шла исключительно про ООП.

Так вот, сегодняшние паттерны проектирования, которые требуются в каждой первой вакансии -- это примерно то же самое, что версинус и коверсинус ))) В школах уже к счастью их не проходят, но во времена бумажных тригонометрических таблиц они были обязательны.
Или например, вы знаете, что такое Zenzizenzizenzic ? )))

Peter наш Norvig ещё 20 лет назад в "Design Patterns in Dynamic Programming" отмечал, что паттерны проектирования по сути то же самое, что и Zenzizenzizenzic сигнатуры пользовательских типов в функциональном программировании. Это же глупость: всё равно вы их описываете в своей программе как типы, а затем ещё даёте зачем-то им вторые имена )))
Единственное реальное удобство паттернов проектирования по сути -- это терминология, именующая такие "микроархитектуры" (которая, главное, очень хорошо продаётся).

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

В продолжение вчерашнего. Например, паттерн Стратегия куда нагляднее объясняется в ФП, потому что он использует объекты и наследование как способ обёртывания функций первого порядка. Адаптер -- это функция, "преобразующая" интерфейсы. Приспособленец -- просто другое название интернирования, в ФП есть специальный термин hash consing (расшаривание структурно эквивалентных сущностей). И т. д.

Объекты сами по себе -- это уже паттерны! Вот как занимаемся проектированием с помощью АТД, чему я сейчас учу, точно также можно заниматься проектированием с помощью объектов-паттернов, если вам ближе парадигма классических паттернов проектирования, это просто другая методология.

Объекты как паттерны -- ну это на самом деле просто определенный стиль использования экзистенциальных типов ("инкапсуляция" типа, размещение множества представлений с поддержкой их взаимодействия за единым интерфейсом).

Короче говоря, из всех паттернов проектирования я теперь буду преподавать только единственный, который имеет самоценность в смысле ООП, остальные все -- совершенно лишние вторичные приляпки. Какой единственный? на неделе в СильныхИдеях выложу подробный разбор.

Понимаю, что сейчас всех интересует больше всего, станут ли Diablo, Starcraft и ВоВка работать только на Xbox, и что дальше будет с Котиком??

Ну, вот за Боба точно стоит волноваться меньше всего, такие пацаны никогда не пропадут :)

Поэтому, традиционно, выскажусь на скучную тему о пользе для любого программиста классического университетского обучения (Котик например учился на искусствоведа, и очень хорошо эту темку по жизни монетизировал, а бизнесом занимался ещё в школе), как бы это образование в современном формате не ругали (и весьма заслуженно), однако если вы сами не учитесь ровно для того чтобы работать, никакой топовый университетский уровень не поможет.

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

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

В противном случае, если вы учитесь просто ради учёбы, в расчёте что дальше каким-то волшебным образом хорошая работа сложится сама собой, возможно когда-то после окончания, лишь бы сейчас не потрудиться под предлогом "учёбы", ну... тогда и вся ваша "карьера" в ИТ вот так и будет вяло-вяло тянуться у самого дна многие годы, если не всю жизнь :)

Будь как Котик!

Самая главная реальная опасность AGI в отличие от кино -- что второй попытки точно не будет :) Если ИИ надумает уничтожить белковых существ, то сделает это наиболее коварным и непредсказуемым способом, у человечества 0 шансов. Именно поэтому особенно вредны исследования в области нейросеток, "логика" которых полностью непрозрачна.

Стартапы в эпоху web2: внимание своих пользователей они обменивают на бесплатный доступ к развлекательным услугам и сервисам общения.

Стартапы в эпоху web3: реальные деньги/реальную работу своих пользователей и инвесторов они обменивают на иллюзорные обещания будущего доступа к десятикратно большим деньгам в формате криптовалют.

Например, как игры web3-будущего превращаются в тупой фарминг.

Особая опасность слабых/плохих разработчиков, как ни парадоксально -- это их трудолюбие ))) Они очень активно делают проект всё хуже и хуже, старательно накачивая его ужасным кодом.

Львиная доля рабочего времени стажёров и джуниоров должна уходить на обучение.

Стажёры -- 99% времени на работе только учиться.
Джуниоры -- 80%.
Миддлы -- 50%.
Сеньоры -- 30%.

Фильмы и блогеры высмеивают нас. Семьи разочаровываются в нас. И все же большинство из нас гордится тем, как мы подходим к решению проблем (да, и даже к проблемам в жизни). Инженерное дело - это решение проблем, и мы, инженеры, склонны находить способы заставить вещи работать так, как положено.

Не-инженеры часто бывают озадачены, когда перед ними ставится проблема, особенно связанная с числами, и не знают, с чего начать поиск решения. Инженеры же, похоже, обладают врождённым чувством поиска правильного подхода. Решение любых проблем - это рациональный процесс, которым инженеры овладели лучше, чем большинство других людей. Ну даже в "Криминальном чтиве" специалист по решению проблем демонстрировал идеальный рациональный процесс действий :)

Многие "программисты" получают 40-50 тысяч, а хороший разработчик вполне может стоить 500 тысяч в достойном проекте. Даже в типовом мэйнстримовском проекте, где, вероятно, много легаси, нормальный разработчик обойдётся в 200 тысяч. Следствие, что абсолютное большинство задачек в большинстве проектов выполняют, мягко говоря, не очень хорошие разработчики.

Строка кода -- это не актив. Строка кода -- это пассив. Актив -- это то, что код делает (поясняю это в "Трёх уровнях мышления о программе" в Сильных Идеях). Если в проекте много строк кода, которые не делают ничего особенного, и соответствующую логику можно переписать гораздо более компактно, то это означает, что их создатель активно формирует технический долг.

Идеальный вариант -- иметь теоретически минимальное количество кода, который делает ровно то, что нужно.

Казалось бы, любой код делает то, что нужно? Да, но, даже обычный сеньор напишет на порядок более компактный код, чем джуниор. Чем больше разница в квалификации и чем сложнее задача, тем сильнее будут различаться объемы и качество кода начинающего и мастера для одной и той же задачи.

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

Лучшие программисты мира с миллионными долларовыми зарплатами постоянно упарываются по computer science, чтобы стать ещё сильнее в ИТ, причём по таким темкам, которые и среднему сеньору тяжело даются. Получается парадоксально, что богатые знаниями и умениями становятся ещё богаче, а бедные умом -- только ещё беднее (причём ради своей жалкой зп 40-50т). Тут надо работать с вашей головой прежде всего.

Разница в понимании идёт уже тысячекратная по отношению к рядовым миддлам.

Чего же ждёшь ты?

Ну, можно например потратить тысячу часов на проектирование завода )))

Нередко замечаю, что даже "настоящие" сеньоры в серьёзных проектах (известный финтех например, имя которого убоюсь упоминать всуе :), которые выступают на highload-конференциях и учат других "правильному" проектированию, делают такую системную ошибку: определяют в программе собственные вычислимые типы данных (например, "денежные") как АТД с какой-то локальной спецификой (что само по себе очень правильно), но не понимают, что это по сути поля, которые в их кривой реализации обычно алгебраически незамкнуты.

Ну блин, ребята, почитайте хотя бы "От математики к обобщенному программированию" Степанова (как правильно проектировать библиотеки наподобие STL C++), это уровень недо-джуниора.

По моей матрице компетенций, средний джуниор должен свободно решать задачки из "Курса алгебры" Винберга.

Проблема с обучением детишек программированию заключается в том, что последующая работа в индустрии неизбежно превратит детское увлечение в нечто невесёлое.
https://store.steampowered.com/app/1386180/Bitty_Engine/

Автору Tony Wang кстати зачот за его работы, некоторые в исходниках можно на гитхабе найти. Кстати, эталонный пример хорошего программиста, кто хочет делать карьеру в геймдеве, ориентируйтесь на уровень проектов его гитхаба.