I used to think documentation was the creative equivalent of eating your vegetables. It was the boring, administrative chore you did after the real, exciting work was over. It was the tax you paid for being a professional. My process was to create, deliver, and then, if I absolutely had to, grudgingly write a README file before moving on to the next shiny thing.
This philosophy crashed and burned during a portfolio review. A potential client pointed to a complex interactive piece I was incredibly proud of and asked a simple question: "Can you walk me through your creative process on this? Why did you make these specific technical choices?"
I opened my mouth, and nothing came out.
The project was only six months old, but the reasoning, the "why" behind the work, was gone. I could describe what I did, but I couldn't explain how I thought. The code existed, but the thinking was a ghost. I’d have to reverse-engineer my own creative process, and in that moment of embarrassing silence, I realized the terrible truth: work without a story is only half-finished.
I hadn't just been failing to document. I had been failing to give my work a memory.
The Shift: From Chore to Creative Practice
Here's the thing: we've been sold a bad definition of documentation. We think it means writing dry, technical manuals for some hypothetical future developer. That's not it.
Let's strip this down to its essence. Documentation isn't about creating a record. It's about making your thinking visible.
The moment I stopped seeing documentation as an administrative task and started treating it as a creative practice, everything changed. It became a design tool, a thinking partner, a way to have a conversation with my future self.
You're not just writing a README file. You're building a time machine. You're sending a message to Future You, who will inevitably be staring at a piece of your code with a fresh cup of coffee, wondering, "What on earth was I thinking?"
My System: A Conversation with Myself
My documentation system isn't a rigid set of rules. It's a series of rituals designed to capture my thinking while it's fresh.
1. The 5-Minute End-of-Day Journal This is the most important habit I've built. At the end of every work session, I take five minutes—literally, I set a timer—to answer three questions in my project log:
- What did I learn today? (A new line of code, a failed experiment, a client insight.)
- What decision did I make and, more importantly, why? (e.g., "Chose to use OSC instead of WebSockets because UDP is faster for real-time data, and I don't need guaranteed packet delivery for this.")
- What's the next open question? (What am I stuck on? What do I need to figure out tomorrow?)
That's it. Five minutes. But after a month, this journal becomes a rich, searchable narrative of the project's journey. It's a time machine that lets me instantly recall the context of any decision.
2. "Working in Public" (Even When It's Private) I treat my process like a story that's unfolding. I capture it constantly, not just at the end.
- Photos & Screen Recordings: I take photos of whiteboard sketches, screen recordings of interesting bugs, and short videos of prototypes. These aren't for a big presentation; they're for my own memory. They're the B-roll for the story of the project.
- "How I Solved It" Gists: When I solve a particularly nasty technical problem, I take an extra 15 minutes to write a short explanation on GitHub Gist. I'm not writing for an audience; I'm writing for Future Me, who will absolutely run into this problem again and will have forgotten the solution. The fact that it might help someone else is a bonus.
3. Writing to Understand (The Feynman Technique) The most powerful realization was this: I don't document what I know; I document to figure out what I don't know.
If I can't explain a concept or a piece of my code in simple, clear language, it means I don't understand it well enough. The act of writing the documentation—of trying to "make my thinking visible"—is a ruthless bullshit detector. It forces clarity. It reveals the gaps in my logic. The documentation process doesn't just record the work; it actively makes the work better.
The Unexpected Payoffs
When I started this practice, I was just trying to solve my "future me" problem. But the side effects were far more profound.
1. My Work Became My Best Marketing. My library of process photos, technical notes, and "what I learned" reflections became a treasure trove of content. I could now write a case study that wasn't just a glossy "after" photo, but a compelling story of the "before" and the "during." This kind of authentic, process-driven storytelling is what attracts the best clients. They don't just see the final product; they see how you think.
2. I Became a Better Teacher. By documenting my process, I was inadvertently creating teaching materials. My "How I Solved It" notes became the basis for blog posts, conference talks, and workshops. Teaching what you learn is the best way to solidify your own knowledge, and it builds your reputation as an expert more effectively than any self-promotion ever could.
3. My Ideas Started to Compound. My project journals became a personal knowledge base. I could see patterns in the problems I was solving. I could connect an idea from a project two years ago with a challenge I was facing today. My old work wasn't just sitting in an archive; it was an active part of my creative process, a compost pile where old ideas fertilized new ones.
Your First Message to the Future
You don't need a complex system. You don't need to buy new software. You just need to start a conversation with your future self.
Here's my challenge to you: for one week, at the end of each day you work on a creative project, take five minutes. Open a blank text file. And answer those three questions:
- What did I learn?
- What did I decide and why?
- What's the next open question?
That's it. At the end of the week, read it over. Notice how much context and insight you've captured that would have otherwise evaporated. You'll have built your first time machine.
The work isn't finished when it's delivered. It's finished when its story has been told.