Планы на следующий год

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

Ценность первоисточника

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

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

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

The Hamming Question

Знаменитый инженер и математик Ричард Хэмминг любил сначала спрашивать: «Какие самые важные проблемы в твоей области?», а потом «Почему ты над ними не работаешь?»

Раз уж сейчас начало года, можно в виде салюта стрелять из Хэмминговской двустволки. Троллить других людей, конечно, не стоит, а вот спросить себя — дело хорошее.

Ответ на The Hamming Question

Как мне кажется, одна из самых важных проблем в области разработки — это понять, почему одни команды и компании отстают от других в скорости и качестве разработки. Можно спорить, что такое «скорость и качество разработки», но есть некоторые внешние признаки, по которым всё понятно. Например, одни команды отстают от лидеров на 15 лет (пишут на Java 7 и нет continuous delivery), а другие отстают на все 25 (нет виртуализации нигде в инфраструктуре).

Если разобраться в причинах отставания, можно «подтянуть» всю индустрию, чтобы мы быстрее делали продукты получше. Нас много, одних только разработчиков в мире 25+ миллионов. Было бы хорошо, если бы эти 25 миллионов человек не тратили тысячи драгоценных часов своей жизни на давно решённые проблемы. Было бы хорошо, если бы миллиарды пользователей не тратили драгоценные часы своей жизни на то, что не решает их проблемы как следует.

Пока у меня нет полной картины по проблеме, только обрывки. Например, известно, что к пятому году существования команды серьёзно заболевают Not invented here-синдромом и их результаты становятся хуже. Известно, почему в компаниях возникают чёрные рынки услуг и как с ними бороться. Ну и так далее, набралось некоторое количество фактов. Возможно, чтобы сделать прорыв в изучении проблемы, нужно сломать какие-то аксиомы.

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

Дед Мороз!

Cлово grandfather можно использовать как глагол. В этом случае grandfather — это «придумать новое правило на замену старому, при этом старое правило применять к уже существующим ситуациям, а новое правило ко всем новым».

Например, когда оператор связи выкатывает новую линейку тарифов, пользователи могут остаться на интересных старых тарифах, более недоступных. Таких пользователей оператор grandfathered in.

Хорошо, когда у слов есть нюансы.

Конфетку делает обёртка

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

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

Непривычный ход мыслей — думать, какие проблемы вы уже решили и решили красиво. Совершенно естественно, что хочется рассказать про фичу, над которой вы страдаете прямо сейчас. Там может быть длинная и удивительная история про то, как вы эту фичу переделываете в четвертый раз за три года. Но лучше всё-таки рассказать про что-то полезное для пользователя, особенно если там всё просто. Только это в итоге слушатели и запомнят.

Смена перспективы

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

Однажды греческий философ дал задание своему ученику. Ученику нужно в течение трех лет давать деньги всем, кто его оскорбляет. Ученик прошёл это испытание, а потом отправился в Афины. У ворот Афин его встретил мудрец и сразу же оскорбил. Ученик с этого рассмеялся. Мудрец удивлённо спросил, почему он смеется. На это ученик ответил, что целых три года он должен был платить за оскорбления, а теперь они достаются бесплатно. Мудрецу оставалось только сказать: «Входи в город. Он весь твой».

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

Worth your time

Каналу исполнился ровно год. Это пост №110. Цифра просит какой-нибудь интересной статистики, но свои метрики я выдумывать не буду, лучше процитирую учителя, он тут попал в точку:

• Less than 1% of your writing will be life-changing.
• 3% will be trivial to write.
• 5% will be quite good.
• 15% probably should’ve never been published.
• 30% will start as one piece but finish as another.
• 40% will be good solid writing.
• 60% of your writing will never be finished. Be ok with that.
• 100% of your writing is worth your time.

Уверен, всё самое интересное ещё впереди.

Контент для инженеров от инженера.

Мысли о знаменитой шутке.

Живая доменная модель

Хорошо, когда архитекторы системы выписали все важные для доменной области существительные. Подобрали точные имена, продумали атрибуты, связи, всё красиво. Но вот в коде в результате получается anemic domain model. Читаешь такой код, а у сущностей там ноль поведения, это просто кучки данных, которые перекладываются туда-сюда. Между «самолёт разогнался и взлетел» и «взлетатель переложил самолёт с земли в небо» большая разница. Во второй самолёт так и хочется вдохнуть жизнь.

Любому писателю известно, что лучше всего предложения оживляют глаголы. Если в предложении пять существительных подряд, оно, считай, недвижимость. А вот если в предложении есть глагол, предложение улыбается. Аналогично и с кодом. Хорошие глаголы из доменной области (а не только дефолтные Store/Get/Parse) могут в разы упростить общение между всеми, кто создаёт проект.

Взять, например, мою область. У нас тут детонируют вредоносный код и спиливают клыки опасным ссылкам. Можно даже закрыть глаза на то, что глаголы не на 100% точные. Сам образ человека в каске, который закапывает вредоносный файл поглубже в песок, а потом поджигает бикфордов шнур — это ярко и живо. Ярко и живо благодаря удачному глаголу.

А не пустить ли 80% роадмапа на подготовку демки?

На hackernews регулярно всплывают темы о том, как проводить демки или о том, как записывать красивые демовидео. Про демки есть книги. Есть стартапы, помогающие делать это быстро и качественно.

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

Ревью прочитанных книг: Q1 2025

★☆☆☆☆ The Great Mental Models. Написано плохо, но идея собрать полезные инструменты вроде бритвы Оккама в одной книге хорошая.

★★★★☆ The Tao of Programming. Набор стихов в стиле Дао дэ цзин, но про проектирование, разработку, тестирование и поддержку. Коротенькая книжка с забавными философскими отсылками.

★★★★☆ Leadership Is Language. Отлично раскрывает свой подзаголовок «Скрытая сила сказанного и не сказанного». Узнал много нового. Было бы написано короче, цены бы этой книге не было.

★★★★★ The SaaS Playbook. Узнал, чем хорош SaaS на практике и как его бутстрапить. Net negative churn — мощь, про него писал выше в канале.

★★★★★ The Art of Happiness. Разум можно натренировать быть счастливым. Эта книга пытается объяснить, как это сделать.

★★★★★ Мессия Дюны. Как мне показалось, книга о человеке безграничной власти, у которого нет иного выбора, кроме как уйти в пустыню и раствориться в бесконечной Вселенной. Прекрасное продолжение первой Дюны.

Первое впечатление читателя

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

Документация обычно выглядят не такой чистой, как код. Наверное, потому что писать документацию сложнее. С ней тебе не помогает компилятор, IDE и тесты.

Но помочь писателям хочется. Им много не надо, достаточно посмотреть на статью глазами читателя. Простые варианты:
1. Отзумить страницу до 10%.
2. Вырезать со страницы всё лишнее, как на скриншоте выше. Например, с помощью букмарклета: javascript:(function(){['p','code','ul','ol','pre', 'blockquote'].forEach(tag=>document.querySelectorAll(tag).forEach(el=>el.remove()))})();

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

Хорошо, когда писатель понимает читающего по диагонали человека.

Новый пост о дизайне.

Новый пост об уважаемых людях.

Яркий признак адекватности человека — это способность спокойно держать в голове две противоречащие друг другу идеи.

Нарисовал картинку для статьи о дизайне API.

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

Возле знаменитых Гусей Новосибирского Технопарка выросли и задышали жизнью новые башни на 20 тысяч квадратных метров. Хоть башни и выглядят готично, название у них классное - Port i7. Это отсылка не только к адресу — Инженерная 7, но и ещё много к чему.

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

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

Офис — символ амбиций, но будет хорошо, если будет расти не только площадь офисов, но и местный спрос на технологии. Тут есть надежда, всё-таки Новосибирск занесён в Книгу рекордов Гиннесса как самый быстрорастущий город в мире.

Краткое содержание этого блога: https://neexee.com/ru/about/