Multi-Perspective Note-Taking: Mastering focus as a solo-developer

When I first started building software products alone, I gave myself a lot of deadlines. The deadlines were never quite deadly enough, and so, I would extend a one-month plan into a three-month plan. And that would become a six-month plan. Some of this delay was from overestimating myself; some of it from underestimating the problem; but a lot of it was just unforeseen complexity. Eventually I started to anticipate when a project was beginning to run away from me. And one of the tell-tale signs was my misuse of focus.

A monster hunts you, developer. This monster is self-indulgence, a siren that seduces you and drains your time.

A design problem, like building a software product, is mother to this siren. And like any good mother does to feed her monstrous kid: It sets the trap. It reflects your beliefs and skills, and then grips you like a mirror. I spent too many years not having a good understanding of what a design problem is, which is unfortunate, because knowing what it is allows you to recognize its allure.

If an abstract problem is adding one plus one, then a design problem is planning a blind date for your two lonely friends. It captures you with its many variables to think about: What’s happening? Who’s involved? When and where's it happening?; demands you to try and make sense of it: Why’s it happening?; forces you to dream of solutions for it: What’s possible? What could happen?; and finally, it submits you to the agony of choosing: What’s good enough? How do I make it happen?. It’s a problem warped by its circumstances, asking you to figure out how these circumstances matter, and then leaving you to solve it to your satisfaction.

Key point: Your satisfaction. Big or small, you solve a design problem with your knowledge, your skills, your prejudices, your hopes, and your anxieties. All of it. It can spellbind you as you question yourself using everything you know and everything you feel. Solving one can feel personal, because it is.

And when you try to solve a design problem, it explodes. It fragments into smaller design problems; each grabbing at you for your opinion; each threatening to explode even further. And when these sub-problems do explode, the shock waves throw you further away from the original problem. You gain distance from it. And that's what makes sub-problems dangerous.

If you’re not careful with a sub-problem, because all design problems pull you in, you get transfixed; engulfed by its context. When time and uncertainty apply pressure, this becomes the many-named monster: Yak-shaving, time-sink, and rabbit hole. I call it self-indulgence because the experience feels like being thoughtful. Here’s the tension: When working against uncertainty and time, you look self-indulgent when you stress about a smaller sub-problem. But on the inside, you feel like you’re caring. And that’s what makes it a monster. It makes fixation, the kind that derails progress on the larger problem, feel like care.

To escape the trance of self-indulgence, something outside of you has to break it. Someone looking at the house while you paint it can warn you when a sixth coat of paint is a waste of time. They can also warn you when the basement’s flooding. They can drag you away, show you things have changed, explain how the original problem is now viewed differently, and insist on working on something else. They don’t simply remind you of time passing, they argue for the larger problem.

This is why time limits, often called timeboxing, are weak when working alone. A timebox doesn’t yell at you about the cost of time spent; doesn’t refocus you if something’s changed. It has no context; no reasoning. A time limit doesn’t do enough to protect the lone developer from fixation. She ends up thinking she lacks self-discipline, or project management, or some other ideal. But the lack is something simpler: She has no one to argue with.

To effectively argue with yourself to break a trance, you need to probe your thoughts in a way that makes their flaw obvious. Imagine you see a strong, solid wall. The sort of wall you’d like to hide behind if your life depended on it. You walk towards it, and you tap it with your knuckles. It echoes. The wall’s hollow. You walk to its side, and you notice how thin it is. You then walk behind it, and you see its insides. It has poor structure. It’s weak. This is a wall that fooled you. Similarly, how you examine your thinking from multiple perspectives is through writing.

As you write, you can wear the hat of a marketer, engineering manager, or developer. You can wear these hats one at a time, but on the page they can all argue in parallel. This parallel, multi-perspective argument is hard to hold in your head. But on paper they can be stitched together to form a whole, just like that wall from before, ready to be probed.

You probe for what’s most important to work on. Each hat or perspective is constantly fighting for what’s most exciting, most worrying, and most valuable. When you’re deep in the work as a developer, the developer perspective enjoys a bit of favoritism. You proactively write down other perspectives to keep it in check; to prevent your most used perspective from declaring itself king.

This makes timeboxing useful again. Each hat argues for a different part of a larger problem. And having these perspectives written down, you have yourself a collection of arguments you can browse quickly. When a timebox ends: You zoom in and out of sub-problems; switch between points of view to see what’s most important to work on; and make sure the original problem is the one being progressed. This is how a solo-developer can fight the monster of self-indulgence: Write as both developer and manager; be both arrow and archer.