On Being a Slow Developer

Harold Combs

So this is going to be odd coming from a guy working at a place with a Leadership Principle saying “Speed matters in business”

If I’m doing my job right, I consider myself to be a “slow” developer.

I’ve watched the recent explosion across my social feeds about AI SUPERCHARGED DEVELOPMENT ENVIRONMENTS! like Copilot, Cursor, Windsurf, Claude, and Warp Terminal. They all seem neat, and this seems like a Nova (if not a Supernova) of dev tooling we haven’t seen since Netbeans/Eclipse/IntelliJ battled it out 15 years ago to see who could make IT departments upgrade from 512 MB developer machiens fastest.

Still, they don’t solve a key problem: I’m not thinking any faster. Well, I’m not thinking faster correctly.

So a “feature” of my brain chemistry is a euphoric flow state. It feels…well, it’s hard to describe. Imagine feeling like you can conduct an entire orchestra inside your own head, only you’re writing all the parts in realtime, one measure of music ahead of the players. Further, imagine you having the sheer hubris to imagine you can do that with a full orchestra just waiting on you to fart out perfection. To you, it’ll seem like “This. is. SO. Brilliant.” To everyone else, it will seem like “This guy is a raging lunatic.” So that maniacal flow state is me thinking “fast”. To a degree–that sort of impetus is me writing today. I took a notion on the way to work, and I’m compelled to write it down. Like, I can’t not do it.

This euphoric hubris has had some hilarious side effects in my career. I’ll just give one example because I’d like to be remain employable: I used to program a printer fleet management tool at my previous employer when I was a junior engineer. This was in the days of installed software that was burned onto a CD-ROM. As part of that we had weekly builds that progressed from Alpha -> Beta -> Gold Candidate. I decided that our network scanning/discover subsystem was “wrong” and decided to rewrite it from scratch over a weekend…on the 3rd Gold Candidate. That was a “fun” meeting with the team lead, manager, project manager, and PROGRAM MANAGER.

Anyway, the point is: I can be fast. I can do the right thing. I can rarely do them both at the same time. Many times, I’ve walked in at 8am, coded like mad for 6 hours, then just thrown the git branch away in disgust. Why didn’t I just spend 15 minutes THINKING ABOUT IT?

To mitigate, as I’ve progressed in my career, I’ve become more deliberate. I intentionally slow-down, but I don’t feel I’m less productive:

  • I tend to think about what I’m doing, why I’m doing it, and the best way to do it.
  • I’ll reach for a scripting language like Ruby, Node, or Bash instead of C++, Go, or Java.
  • Example: This website is generated-on-push from Github and Hugo. I’m sure WP would be “fun” (maybe?), but my purpose here is to have a web-presence without massive ecosystem lockin, with minimal lift using tech I understand. AWS + Github + articles written in Markdown is tech I understand.

Said a different way, I don’t know that AI tools are going to be the step-function improvement we all expected. I don’t know that literature improved markedly from Jane Austen writing in longhand to typewriters to word processors. Hemmingway was more than happy to avoid conjunctions without modern conveniences. (No, I’m not Hemmingway. Just an illustration.). I do agree IDEs jumped productivity and democratized programming. There were a certain breed who could hold all the symbols in libc inside their head, and know “le mot juste” while hacking in vim. But that was a narrow group, and they created great UNIX Kernels, not the best user applications.

For me, I’d say the logarithmic growth curve has been:

  1. Hardwired plugboard computers. Yikes
  2. Switch-programmed computers. Barely less likes.
  3. Punchcards: Associated with programming languages like FORTRAN and COBOL, these were a gamechanger
  4. Online editors: Vim, Emacs, etc. No more punchcards!
  5. Windowing/refactoring editors: I have to give Smalltalk its due here. Really wish it’d made it out of Xeroc PARC.
  6. IDEs: Visual Studio felt like cheating, especially once IntelliSense came around
  7. Refactoring IDEs: Be Honest, the first time you used “Extract Method” in IntelliJ, wasn’t that a good day?
  8. AI Tools: Omnipresent co-development pair programmer.

So, I’ll continue to be “slow” but with better tooling.