tl;dr - “Wow, you make mistakes too… But you make them REALLY fast.”

Not really sure what category to put this in so I’ll just file it under “hacking”.

Back at Temple University I had been running MUDs (multi-user dungeon games) on my machine, bigboy.cis.temple.edu. It was a great way to learn Unix IPC and work on complex C systems, but I had a summer free to hack and I decided I wanted to build an object-oriented adventure game development system. (The game would be an environment supporting objects like places, monsters, players, etc, but it was written in C.)

So I designed a language that resembled a mismash of dBase, Pascal, with some object-ification. Dr. Kapps told me “semicolons are for lazy compiler writers” so semicolons became optional.

I spent over a week on the data structures for the parser and game engine and then it was time to write the code.

The office I inhabited was hot that week so I went out to the lab to start writing. After a while my friend came up and watched me code for a while. You know, type type type, compile, fix syntax error and hope you are paying enough attention to not have any subtle semantic errors along the way. I think I was doing the parser at the time, just dumb stuff because I was too lazy to think hard and do lex/yacc.

After a while my friend said to me…

“Wow, you make mistakes too… But you make them REALLY fast!”

Most of the mistakes were just typos, but in some cases it was whacking away a function or two and re-implementing a different way.

20+ years later, my style is the same - see it enough to know it’s possible and whack out what I call “running specification”.

That’s how I generally make the first version of something that I need to do or think needs to exist. But for docs, edge cases, config parsing, and in some cases scaling, if the code is going to get used, especially by others, it’s time to bring in someone who’ll do the actual software engineering.

So was that a compliment or a criticism?

He meant it as a compliment but I took it as a bit of criticism (for not exerting the focus to just do it perfectly).

And my current take -

Without understanding that it’s OK to try things rapidly as part of the learning or just implementing process, people get stuck and can stay there for way too long trying to analyze their way out of it. Wishful coding, printf() debugging, and other lazy techniques continue to be useful for me.

But… It’d be interesting to see what I could do or at least how I would do things if I could get un-lazy or un-distracted enough to focus on precision for hours at a time. I don’t feel like it’s been a blocker as I know how to identify things that should be done by focus-ers and just engage them.