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