По мотивам Unix:
- заставьте каждый компонент делать хорошо ровно одну вещь;
- делайте каждую функцию фильтром, естественно компонуемым/комбинируемым с другими функциями;
- чистый код лучше чем умный код;
- храните данных в "плоских" текстовых файлах (просто, читабельно, легко редактируемо);
- меньше по размеру это значит лучше (лучше много независимых модулей чем один монолит; только не забывайте, что если у вас 10 слабо изолированных микросервисов, как-то связанных в фоне друг с другом, вы легко можете получить 3,628,800 монолитов).

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

Мы часто шутим или жалуемся, что дескать программирование сегодня -- это просто "копипастинг из StackOverflow". Однако практически не задумываемся, а как мы можем более лучше поддерживать копипастинг из StackOverflow в наших проектах.

Я серьёзно. Если это обычный рабочий процесс, то мы должны искать и находить способы его улучшить. Вот тут AI однозначно может хорошо помочь.

Программисты в 1980-х: "Всё есть указатель на непрерывный буфер значений... потому что Cи".
Программисты в 1990-х: "Всё есть объект, потому что бизнес-логика и базы данных".
Программисты в 2000-х: "Ясность кода и паттерны проектирования, потому что железо дёшево, и любой может писать код".
Программисты в 2010-х: "Мы проводим ежедневные митинги, чтобы выяснить, какой JavaScript-фреймворк нам попробовать сегодня, потому что мы гибкая команда".
Программисты в 2020-х: " Всё есть указатель на непрерывный буфер значений... потому что дата-ориентированный дизайн и кэширование".
В каком десятилетии застряла ваша компания? :)

+16 Полезное: algorithm for passing programming interviews , очень рекомендую выучить эту модель решения типовых задачек по алгоритмам.

Бонус: как за одну неделю подготовиться к прохождению интервью по System Design в MMANGA.

Только конечно важно понимать, что скилл прохождения интервью по System Design -- далеко/совсем не то же самое, что скилл System Design в реальном проекте, когда на вас вся ответственность за архитектуру :)

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

Очень хорошая бесплатная игра Bitburner — медитативный хакерский киберпанк с программированием на JavaScript :)

На тему программирования видео принципиально не смотрю, а вот мотовидео помногу регулярно, и так удачно...
"Как стать программистом в 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-будущего превращаются в тупой фарминг.