Avi Freedman's Tech and Biz Topics

on internet plumbing, gadgets, nerd herding, and other related topics

Making Mistakes Fast

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.