There was an article highlighted in a variety of nerdy news sites called "I'm A Good Engineer But I Suck At Building Stuff," and while I was reading it, I felt the writer Lionel Barrow's pain.

Because I'm a better engineer, but I still suck at building (some) stuff. When Barrow writes: "I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth," I don't sympathize. Not only do I know how to do all those things, I know how to avoid them. A hard-to-test function should be broken down into public components; injected dependencies shouldn't be a difficulty, they should absolutely be the starting point of your composition; integration tests are mastered by giving your interface the smallest possible surface area. When Barrow writes, "Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the best, most natural expression of the ideas it contains — obsessing over my own construct, rather than on the thing my code does," I remind my self that the very first thing my code does is communicate with other developers. Code is meant to be read first and compiled second. Yeah, maybe if you're doing a prototype you can cut that corner once or twice, but get it out of your habit.

Where I work, my fellow engineers have a joke about "Elf's de-cleverizing pass." I work in Javascript but am a Lisp programmer at heart, and I start by writing everything in terms of transformers and partials wrapped inside and around map/filter/reduce, and then at the end I will remove the partials and break out the transformers into functions and make the code look like something my peers expect. Most modules I write end up as long, easily-followable lists of var expressions that end with a single side effect, because that's what all code is: an expression that ultimately has some real-word consequence.

On the other hand, I feel Barrow's pain because I, too, suck at building stuff. Modifying other people's code is easy. Even if I've been tasked with building "something entirely new" for my employer, the skeleton of every application we've ever built is in our repository, and if I can find something that does 51% of what my new task calls for, the rest is more or less fait accompli.

But when it comes to my own projects, I get analysis paralysis. I wanted to write a simple compiler with a few ideas of my own, something that would make my life as a developer easier, at least for a few follow-on projects, and ...

There's way too much to know about compilers. Stephen Diehl's wonderful (if woefully incomplete) articles on "Write You A Haskell," James Longster's expedition into his Outlet project, all the effort I put into Lisp In Small Pieces, parsing, hygiene and scope, type systems (oy! Type systems!), compiling with continuations... My eyes start to glaze over and I get this terror that I'm never going to be smart enough or have time enough to do anything at all. The size of my ambitions overwhelms me. I lose track of what I'm trying to do as yet another article on CPS Transforms and Nanopass Compilation comes to my attention.

The twin impulses of wanting something useful now and wanting to know everything now are, rather than helping each other, constantly at war with time itself. I'm sure it's an ADHD problem that no amount of Adderall is going to handle, because it's not about attention, it's about desire. I never have this problem professionally, because when it comes to money both what must be done and what I desire to be done are more or less well-aligned. It's about the projects I'm really passionate about; I don't want to screw them up, and there's no pressure to get them out the door. I really don't know how to make these impulses play well together.