This is the third follow-up to my my previous entry on self-knowledge and motivation. The entire series can be found here.

I’ve finally figured out the problem that I’ve been having with motivation for working on Project X. It’s really pretty simple, and I don’t know why I didn’t realize it before.

I’ve taken some college classes in data structures and such, but I’m primarily a self-taught software developer. The way I design and write software was learned through many years of trial and error. It’s very good, but it’s not something that could be taught in a classroom.

Any good developer comes to have a software emulator in his head. It’s the natural consequence of writing and debugging code; he learns to read a function and mentally “run it” to see exactly what it would do when it’s given a particular set of inputs. The better he gets at this, the faster and easier he can debug a function, and presumably write one as well.

The better developers can look at an entire module, or an entire program, and see how each part interacts at a high level of abstraction. This is largely what makes them better developers; they write code that supports this mental model. They seldom need to write comments in their code, because their code itself explains what it’s doing: their variable names explicitly describe what they represent, their function names explain exactly what they do. Comments are generally reserved for explaining why something needs to happen, and that’s usually self-explanatory with code written by these guys.

(Although examples of this style of design are provided in most programming courses I’ve read about, and it’s often explicitly emphasized, most new developers simply don’t get it. I don’t think that’s a defect in the programming courses; it seems to be the natural consequence of the fact that it takes years of experience before a developer can really grasp the reasons behind it, and start writing code that properly supports it themselves.)

The end result is that a really good developer can design an entire program in his head before he even touches the keyboard. The design is subject to change and refinement as he develops the program, but even those changes are almost instantly designed in his mind. If you describe a bug in code that he’s written or studied to him, you’ll often see him sit back with his eyes unfocused for a few seconds, then he’ll be able to tell you exactly what the bug is and how to fix it, or at least exactly where in the code to look for it.

And that’s the problem: nothing quite like Project X has been done before. I can easily remember dozens of details about Project Badger, even about code that I designed and wrote a decade ago, because it all fits into a well-understood framework. But I find myself flailing and grasping to hold onto some simple details about Project X because I don’t have a clear mental model of the overall design yet.

As I’ve worked on it over the past couple weeks, I’ve found myself tensing up and getting anxious because I can’t see how the end result should look. After an hour or two of work, I have to get away from the computer or work on something unrelated to calm down, and it’s hard to get back to it because I still don’t have answers to the design questions that drove me away in the first place.

A clearly-identified problem usually contains the seeds of its own solution. I’m getting anxious about working blind. There are two obvious paths to counter that: don’t work blind anymore, or don’t get anxious about it.

There’s little I can do about the working blind part. The reason I don’t have a clear vision of the end result is because it doesn’t exist yet. No one knows how to do it. The only solution to that is more thought and experimentation. So is there anything I can do about getting anxious about it?

Maybe. Simply understanding why it’s happening should help counter it. Giving myself permission not to know exactly what I’m doing… easier said than done, because it goes against nearly twenty-five years of experience at designing software, but it’s worth a try.

I’ll write more on this as I get it.