# Making a Game of Time

1 min read

Python, as languages go, is frightfully slow. But as someone familiar with Python, it allows me to create software very quickly. In many ways I’m trading one kind of time, “run time”, for another kind of time, “developer time”.

It’s actually even deeper than that. Python code is also generally quite easy to read and understand. I’m also getting faster “support time” by choosing Python.

To some extent, even modern Python tooling like uv is trading a longer development process (in Rust) for faster execution.

Over my career I’ve found a lot of magic in trading different kinds of time. There’s often assumptions around a system or solution that can be thwarted if you let yourself play with time. The old demo scene trick of pre-calculated trig tables are a great example of this - trading memory / storage for compute time.

Thinking about this makes me want to make a set of time-focused oblique strategies for solving software problems, e.g. Does it have to fast? Do it ahead of time! Is just-in-time viable?


More Notes