Почему не стоит перебирать в резюме по каким-то нешаблонным темам?
Ну, если вы давно работаете в 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 кстати зачот за его работы, некоторые в исходниках можно на гитхабе найти. Кстати, эталонный пример хорошего программиста, кто хочет делать карьеру в геймдеве, ориентируйтесь на уровень проектов его гитхаба.

Классная исследовательская группа в духе легендарной Xerox PARC, занимающаяся очеловечиванием компьютеров + планы на ближайшие 50 лет (Алан Кэй одобрил). В сравнении с Dynamicland современные смартфоны -- это тюрьма, как выразился один из позанимавшихся там.
https://dynamicland.org/

Конец света в ИТ быстро настанет, когда в компиляторах начнут активно применять алгоритмы машинного обучения -- а такие работы активно ведутcя корпорацией добра например:
"...and achieve up to 7% size reduction, when compared to state of the art LLVM -Oz."

Пять стадий принятия неизбежного -- строгой статической системы типов:
- Отрицание: это ошибка компилятора, мой код правильный...
- Гнев: этот язык -- отстой...
- Торг: может быть, мне просто нужно уточнить здесь аннотации, или выполнить явный кастинг типов...
- Депрессия: мой код никогда не скомпилируется...
- Принятие: это нормально, если мой дерьмовый код никогда не будет компилироваться.

Программист "дурацкого" фул-стека (fool stack) -- это тот, кто убедил руководство попробовать Forth, а потом навечно застрял на обслуживании получившегося беспорядка )))

P.S. Хотя покодить на форте рекомендую однозначно,
поучиться думать в конкатенативной парадигме,
а также поразбираться в архитектуре генератора виртуальных машин Vmgen и сопутствующих темках.

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

"Экономьте не 5 строк кода, а 50"
(с) Михаил Донской

P.S. Хотя, конечно, в реальности 80% программистов ускорить разработку действительно помогает скорее слепая печать, потому что та форма "думания", которой они следуют, не только не экономит код, а скорее немножечко вредит. Тут, да, полезнее поскорее выплеснуть своё кривое мышление в реальный кривой код, увидеть его со стороны, ну и начать бесконечно дебажить, для чего шорткаты и вот это вот всё неплохо помогают.

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

Тут буду писать какие-то наиболее очевидные моменты, а полноценная формализация, какие именно абстракции, когда и как надо и, главное, не надо использовать в своих проектах, будет как обычно только для тех кто у меня регулярно занимается.

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

А если ещё добавить к тайпклассам алгебраические типы данных, что хаскелисты особо любят, вообще получается огонь.

Ну, на демо-примере из 5 классов, действительно, может показаться, что можно теперь про классическое ООП с наследованием и полиморфизмом забыть навсегда :)

Однако когда начинаешь кодить что-то уровня Dwarf Fortress -- сюрприз! :)

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

Как правильно, на днях пост будет в основном паблике.

P.S. Но если вы про тайпклассы никогда не слышали, вообще не парьтесь; рядовой программистской работы на десятки лет вперёд хватит навалом на всех, причём тем дальше, тем её будет только больше:
78% of the web powered by PHP (1% on PHP 8)

Изучайте легаси-версии пыха (помня, что семёрка закончится в ноябре), и будет вам щастье :)

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

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

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

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

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

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