Paul Graham: Superlinear returns
(c) DALL-E: "Vrubel painting of a blogger crying with admiration while reading an essay by another, more experienced, author." DALL-E отказывается рисовать по запросам с именами.
Рекомендую эссе Paul Graham: Superlinear returns.
Что мне нравится в текстах Paul Graham так это опережение моих писательских планов. Пол периодически пишет про то, что я давно хочу написать, но пока не могу — ещё не Paul Graham :-D
Конкретно на тему нелинейных изменений я уже лет 10 хочу написать эссе да побольше. Но если бы я сел его писать сейчас, то это был бы длиннопост со странными графиками и терминами и без таких интересных примеров как у Пола. Поэтому приходится давать ссылки на его эссе.
Дальше, в общем-то, можете мой пост не читать. Главное оригинальное эссе прочтите. Но оставлю пару заметок для истории, которые лучше читать после оригинального эссе.
Верификация частными случаями
Буду говорить в контексте программирования, но соображения можно распространить шире.
Когда мы описываем алгоритм: программу, доказательство теоремы или решение математической задачи — мы строим его описание в рамках некоторой формальной модели. В рамках соглашений и ограничений, которые мы явно или неявно принимаем.
Описать алгоритм вне формальной модели невозможно. Хотя бы потому, что любой язык — уже формализация.
Отсюда вытекает интересная проблема.
Изменение восприятия сложности
Написал философской рефлексии пост про изменение восприятия сложности за последние полвека.
Когда надо слушать пользователей
Вечные направления.
Первое, чему учат начинающего разработчика — это не слушать хотелки своих пользователей. Умение игнорировать чужие идеи даже важнее урезания фич, не говоря уже о какой-то там монетизации. Начнёте потакать им (или менеджменту, хе-хе) и всё, считай нет продукта, вместо него адская химера.
Конечно, в реальной жизни всё не так однозначно и данное табу полезно только для неокрепших умов. Мы же люди опытные, поэтому вместо безусловного запрета подведём небольшую теоретическую базу под этот вопрос. Ладно, не теоретическую базу, просто хочу сделать пару заметок.
Так кого и когда необходимо слушать при разработке ПО?
Верификация через дублирование логики
Привет.
В посте Тесты, которые тестируют тесты я описал свой взгляд на верификацию программ через дублирование их логики в виде отдельной модели и последующее сравнение с ней. В качестве частного случая выступили юнит-тесты.
В этот раз, опираясь на изложенные идеи, я попробую сформулировать общий подход к оценке уровня верифицированности ПО.