In fluid dynamics, laminar flow is water moving in parallel layers — quietly, looking smooth as glass, and without losing energy to itself. Turbulence is the same water spending its energy fighting itself instead of going anywhere.
The same applies to technical work. Most of what makes it miserable is turbulence — rework, blockages, half-finished things, missing documentation, tangled dependencies, systems that need attention at 3am. None of it is real effort. It’s effort cancelling itself out, like Sisyphus pushing the same stone up the same hill.
Flower Engineering is my answer to that. It’s the methodology I use for technical challenges, built as a solo engineer working alongside AI agents, and made to grow into teams. Its goal is simple: get into flow, stay there as long as possible, and when turbulence returns, clear it to prepare for the next flow.
So the job is not to push harder. It’s to let things flow on their own, and keep clearing the way, continuously. Make it flow-er. The invented comparative turned into a word game, and the sunflower became its symbol for something beautiful and joyful. 🌻
The core idea is to keep the methodology meaningful but simple. Flower Engineering doesn’t try to reinvent what has already been proven. It cherry-picks from whatever I learn and find valuable (DevOps, Design Thinking, Lean, SRE, anything that can be taught) and assembles it into workflows that fit how I actually work. Where nothing fits, I build my own. The framework grows with me, adapts to new challenges, and always leaves room for my own ideas.
About My Turbulence
There are countless methodologies, frameworks and best practices out there. I can read about all of them, but I can’t apply them all. So I chose the parts that work for me and built my own. I’m a slow, big-picture thinker who easily gets lost in details. Without structure, my mind runs in five directions at once and leaves half-finished projects behind. That’s my own turbulence. Flower Engineering started as my way out of it. The principles, together with patterns and workflows, keep me grounded and help me return to flow.
The Principles
Principle: A rule for deciding that does no work of its own but guides the choice when two good options compete.
Nine principles grow from my personal ideals and group into three stances: flow-oriented, privacy-focused and human-centered. They aren’t set in stone. I change them whenever experience shows me a better way. What makes principles valuable is that they give everyone involved a shared basis for decisions. That means me and my AI agents, and some day, I hope, other engineers too. Instead of arguing every choice from scratch, we agree on the principles once and decide from there.
Each one is written as this over that. The right side is never worthless; it’s simply what I give up when the choice gets hard.
Flow-Oriented
- Stupid-simple over complex-clever: Build the simplest solution that carries the load, and keep the system boring. Clever is fun to build but expensive to keep.
- Self-healing over hand-held: The desired state lives in code, and the system returns to it on its own. Whatever repeats is automated; whatever breaks repairs itself.
- One thing done over many things begun: Break work into small batches that still deliver value, and finish one before starting the next. Half-finished things are turbulence.
Privacy-Focused
- Open and owned over closed and rented: Build on open-source and run on hardware I control. What someone else runs can change its terms, its price, or disappear.
- Least access over convenience: Grant only the access the work needs, verify every request, and keep every secret encrypted. When it clashes with simplicity, security wins.
- Minimal data over more data: Collect, keep or share only the personal data the work needs. Data never stored or shared can’t leak or be misused.
Human-Centered
- Human over agent: The agent does the work, but the human sets the direction, makes the decisions, and holds the keys. Systems are built to serve people, not the machinery that runs them.
- Lived need over assumed need: I am my own first user, feeling every friction myself instead of guessing it. Then I widen by listening to the people who use what I’ve built.
- Written and shared over remembered and kept: Knowledge, decisions and tools leave my head and go into writing, open for others to follow and reuse. Knowledge grows when it’s shared.
Principles say how to decide. The next part shows how the work itself is organised: How the Work Moves in Flow.