Как предлагать помощь

«Могу тебе чем-нибудь помочь?» — это хорошая, но слабая фраза.
«Что я могу сделать, чтобы тебе на этой неделе стало немного полегче?» гораздо лучше.

Структура настоящего ⇒ будущее

Как известно, документация и код — это информация в чистом виде. А для информации хорошо, когда у неё есть продуманная структура.

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

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

Бывает, люди слишком длинно и не по теме отвечают на «простые и понятные» вопросы.

В таких ситуациях не нужно волноваться, нужно просто удлинять вопросы. Чем длиннее и точнее будет вопрос, тем короче и полезнее будет ответ.

False Moat: Unique Features

Вдумчиво читаю The SaaS Playbook. Это сборник советов по постройке стартапа в самой лучшей модели поставки софта. Расписано под случай, когда не нужно привлекать венчурный капитал, то есть когда продукт делается для пользователей, а не для инвесторов. Много что в книге нравится, контент жизненный. Ниже пример интересной мысли оттуда.

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

Так что уникальные фичи — не наше всё. Есть более надёжные и приятные варианты создания конкурентного преимущества. Надо бы про них отдельно написать :)

Написал о парочке любимых клавиатурных удобств.

Период полураспада памяти

Стали понемногу накапливаться проекты, про которые я забыл практически всё, даже их названия. Иногда случаются флешбэки, после которых остаётся ощущение шок, я это делал и делал годами?!

Если подойти к вопросу с точки зрения физики, грубая формула забывания вырисовывается такая:

Как долго буду помнить о проекте = 4 * степень вовлечённости * как долго делал проект.

Например, если пахал на проекте два года, будешь вспоминать его лет 8. Степень вовлечённости лежит в отрезке [0, 1]. 0 — слышал название проекта, 1 — всё сделал с нуля под ключ.

Как бы уточнить эту формулу?

Как запоминать профессионально

Раньше интересовался запоминанием, а не забыванием. Поэтому прочитал интересную книгу: Moonwalking with Einstein. Её написал мастер по запоминанию, участвовавший в Чемпионате мира по памяти в 2006 году. На таких чемпионатах люди могут за час запомнить и точно воспроизвести число из 3421 цифры. Тем временем люди без тренировки затрудняются запомнить телефонные номера из 10 цифр.

В книге в подробностях описаны мощные методы запоминания. Например, для запоминания последовательностей объектов используется метод локусов. Допустим, тебе нужно запомнить число 24...(и ещё 100 цифр). Начинаешь с того, что воображаешь себе хорошо знакомую улицу и прогулку по ней. Для запоминания 2 представляешь воздушный шар в форме 2, привязанный к столбу в начале прогулки. Для 4 представляешь себе стул, стоящий сразу за столбом. Ну и так далее, пока цифры не закончатся. Для того, чтобы воспроизвести запомненное, достаточно мысленно прогуляться по улице снова.

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

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

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

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

Ячейка памяти 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()))})();

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

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