One Shot
—
So my catjam submission is coming along nicely! Besides add win/lose states, more art, polish and some hats there's not much to talk about really, so here's a screenshot and I'll leave it at that.
In the post, I want to talk about some opinions I have about software creation, and the idea of "one-shotting" problems, which is a verb I've heard used quite a bit recently.
The main idea I want to put forward is that writing software, like many design oriented tasks, is bottlenecked almost entirely by information.
By information I don't mean the data that the software operates on, but with all the information about the design decisions for the program. The logical extreme of this is if you could see into the the future and could copy the completed program, you could be done in an afternoon.
For a more tangible example, if like me, you've ever accidently lost changes you made in a project and were force to rewrite them, you'll find it takes significantly less time to retype in those changes. I'd say you can complete it in 20x faster, and you might have even used the chance to improve the solution slightly in the process.
But we can't always front-load the process of getting all that information when working on a feature, or fixing a bug, and we're often left to drudge through the code until we get to a solution that solves the problem effectively. Often attempting to one-shot a problem before validating it you'll be guessing, which is usually a bad idea.
In the face of ambiguity, refuse the temptation to guess.
- Zen of Python by Tim Peters
But the information you need to design well and not guess comes from the process of iterative development, which come in many forms like Agile, TDD, REPL driven development.
Each of these strategies, while not perfect, do acknowledge that we aren't all know-it-alls that can make something out of nothing without playing around with it and testing it out. These are really useful tools… until you've full mastered the design space, in which case they can just get in the way if followed dogmatically.
Related is the phrase "Premature optimization is the root of all evil". To phrase it in these terms, "one-shotting" optimizations without first validating that they are necessary is harmful. I have heard this one get some flak, and understandably so in a world where performance is often an afterthought. But I do this it holds up in this light, and it's really more a knock on know-it-alls than it is on real performance experts.
Baking in optimizations to a program that are battle tested is not "premature", as you've already validated it's relevance. On the other hand throwing in optimizations that guess will be relevant will only add complexity with no added benefit.
In conclusion, I think one-shotting is a good strategy for when you already have the information necessary at hand, otherwise you should really be iterating and focus your attention on exploring the design space than on immediate perfection.
We will never get to a point where one-shotting alone is a realistic strategy to create new stuff, since one-shotting only produces results derived from existing information, therefore cannot exist outside of any previously explored design space.
When in doubt, iterate. Otherwise, just do it.