Architecture

There is a particular failure mode that has bedeviled my project life for decades. I call it the “extra mile” problem. I build things because they solve a problem for me. Once I get a solution that works for my particular case, that itch has been scratched, and the remaining work — onboarding, explainers, error messages, edge cases, polish — is an extra mile of annoying minutiae that never seems as appealing to me as the next problem waiting to be solved. So I tend to move on without ever sharing the results with anyone else.

It’s a shameful, totally selfish habit, but fighting your own subconscious is a constant battle that you’re doomed to lose in the end anyway. So instead of fighting my own nature, I look for ways to trick it. And with FrankenTongues, I think I’ve finally done that.

But the epiphany required was so profound that it had to arrive in three parts.

It’s funny how hard it can be to defuse old habits. Historically, my approach to writing code has always been to plan out a good architecture and then implement the framework first, knowing that any time spent building a decent infrastructure first can pay off enormously over the life of the project. But as part of my new policy of leaning into my distractible attention span, I’m embracing a more “rapid prototyping” workflow. Unfortunately, somebody forgot to inform my subconscious about the new plan.