Я вообще большой сторонник TDD, всегда к нему призываю, всегда рекомендую, потому что это первый шаг в направлении TLA+ (мышление спецификациями) и полноценных формальных методов в перспективе. Однако всё же надо честно признать, что когда тимлид вроде как по моим рекомендациям пытается "внедрять" TDD в своей команде, в 70% случаев получается карго-культ )))

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

Только вот интерфейсы всех компонентов, сюрприз! оказываются в итоге спроектированы так, чтобы успешно проходить тесты, а не быть удобными в работе )))

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

Ok, это моя недоработка :) В следующем году будем с этим очень плотно разбираться.

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

Я бы даже сказал, что эта схема работает так продуктивно, что похожа на жульничество :)

8 когнитивных багов начинающих архитекторов распределённых систем:
- сеть работает надёжно;
- задержка нулевая;
- полоса пропускания бесконечна;
- сеть безопасна;
- топология сети неизменяема;
- стоимость трафика нулевая;
- сеть гомогенна (только винда например :);
- для суппорта сети достаточно одного админа на удалёнке.

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

+16 Важные коаны проектирования :)
- плоское лучше, чем вложенное;
- разреженное лучше, чем плотное.

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

"Чем более масштабируема сеть, тем более централизованной она становится, и в конечном итоге все эти ваши "масштабируемые" криптовалюты будут делать то же самое, что и обычный процессинг кредитных карт" (с) Гради Буч

все криптопроэкты -- это зашкваренные версии классических highload-архитектур, старайтесь не вляпаться в 2022-м :)

с Наступающим! 🎄

По мотивам 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) в ошибках и запутанности кода всегда виноват кто-то другой или что-то другое (архитектор, тимлид, менеджеры, уволившиеся программисты, разработчики-коллеги, пользователи, заказчики, обновлённые фреймворки, патчи безопасности, плохая документация...), только не он сам.