О книге «Поток»
«Поток — психология оптимального переживания» Михая Чиксентмихайи — медленное разочарование. Ощущение, как-будто начал читать хорошую техническую литературу, а закончил сочинениями Пауло Коэльо.
Покупал книгу для того, чтобы разобраться с «технической» составляющей состояния потока (концепцию которого и предложил автор книги), понять как им управлять. Оказалось, что интересующим меня темам посвящено всего две первых (вводных) главы, а дальше Чиксентмихайи начинает продвигать свой (на мой взгляд стрёмный) взгляд на счастье и его достижение. Само собой, высшее счастье у автора — это находиться в состоянии потока.
Как я понял, этой книгой исследователь подводит итоги своей работы и философских поисков и пытается поделиться мудростью с миром. Я с этой мудростью не согласен, но некоторым она может быть полезна.
Поэтому разобью отзыв на несколько частей:
- Почему книга стрёмная.
- Почему книга может быть полезна.
- Что такое сознание (в представлении автора).
- Что такое поток (в представлении автора).
- Взгляды автора на счастье и почему я их не разделяю.
Изменение восприятия сложности
Написал философской рефлексии пост про изменение восприятия сложности за последние полвека.
Когда надо слушать пользователей
Вечные направления.
Первое, чему учат начинающего разработчика — это не слушать хотелки своих пользователей. Умение игнорировать чужие идеи даже важнее урезания фич, не говоря уже о какой-то там монетизации. Начнёте потакать им (или менеджменту, хе-хе) и всё, считай нет продукта, вместо него адская химера.
Конечно, в реальной жизни всё не так однозначно и данное табу полезно только для неокрепших умов. Мы же люди опытные, поэтому вместо безусловного запрета подведём небольшую теоретическую базу под этот вопрос. Ладно, не теоретическую базу, просто хочу сделать пару заметок.
Так кого и когда необходимо слушать при разработке ПО?
Верификация через дублирование логики
Привет.
В посте Тесты, которые тестируют тесты я описал свой взгляд на верификацию программ через дублирование их логики в виде отдельной модели и последующее сравнение с ней. В качестве частного случая выступили юнит-тесты.
В этот раз, опираясь на изложенные идеи, я попробую сформулировать общий подход к оценке уровня верифицированности ПО.
Зачем нужен план
Самый известный план на планете
Сначала я хотел назвать этот текст «Зачем нужен бизнес-план», но к чему себя ограничивать? План — он и в Африке план, не важно для чего. Тот, что для бизнеса, называется бизнес-планом. Тот, что для эвакуации, называется, как ни странно, планом эвакуации. И так далее.
Но идея текста таки пришла из области, где актуальны бизнес-планы. Часто стал встречаться с высказываниями о том, что «бизнес-план, конечно, нужен, но вот конкретно в нашем случае он пользу не принесёт потому, что»:
- у нас слишком большая неопределённость, будет гадание на кофейной гуще;
- и так всё предельно ясно, план — лишняя трата сил.
Сам я тоже страдал этими тараканами, но так получилось, что периодически разного рода планы составлять всё-таки приходилось. И хочу вам сказать — планы делать полезно и нужно.
Но сначала…