Эта статья строится на двух простых идеях:

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

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

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

У каждой компании свои оправдания:

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

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

В крупных компаниях: "У нас очень сложная инфраструктура, джунам потребуется слишком много времени, чтобы освоить ее".

Это полная чушь.

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

После многих лет жизни с психическими расстройствами (тревожность, депрессивные состояния) я получил неожиданный для себя диагноз. Синдром дефицита внимания и гиперактивности, широко известный как СДВГ (ADHD). В 44 года. Диагноз оказался неожиданностью: я был спокойным ребёнком, хорошо учился. Врач объяснил, что СДВГ может проявляться по-разному и оставаться незамеченным до взрослого возраста. С тех пор я испробовал множество подходов для купирования симптомов с максимальной пользой для своей профессиональной деятельности. В этой статье я резюмирую то, что мне удалось понять и применить.