The Ethos of Great Code
I’ve noticed many people build an intuition & cognition as their knowledge-base improves, about what makes code really fast, and what makes code really clean. There are a lot of ways to optimize code - learning about things like Data Locality, or Spatial Partitions. Even writing code in a way that is boring, obvious, or recommended by language designers can be a way to optimize, because this is what the language (and especially NCG) is going to be best at optimizing around.
The Trap
Fast & clean is the ethos of great code, and people are quite pleased when they learn how. It’s a little bit exhilarating! But this is a trap. Beginners will often look at what they know, and make the assumption naturally that they should make all of their code as fast and/or as clean as possible.
The Truth
In reality, we all have a limited amount of time to do these things. There are places where it is especially important that code be fast, clean, obvious, boring, or a million other attributions. The truth is, imparting one of these attributes onto a codebase mandates consistent effort. You cannot one-shot the best way to write every piece of code, and if you could, your time would be better spent when focused.
How do You Get Out?
A lot of people can be stuck in the trap for months, or even years. The best way to get out, in my opinion, is to build another intuition & cognition. This time, for “when”, as opposed to “what” - optimizing for any one of the aforementioned attributes of code is just as much about “when” as it is “how”. Remember that work on a codebase is often amorphous, and that you can usually dedicate your optimization time to whatever you want.
There are a few basic heuristics I’ve assembled here for when to optimize or clean up your code.
- Is the code done - does it work? Focusing first and foremost on making code work is the first step to disarm the trap.
- Is it hard to understand? Do things in your codebase interact with it often? I.e., is it creating common behavior which is surprising, or unpredictable? This might signal that you need to abstract your code differently, or clean it up.
- Inversely, is it isolated, or abstracted in a way that would let you easily focus on performance later if necessary? This may be a sign that you don’t need to optimize or clean up right now, but that you might later! Leave a comment. I go with
-- TODO: <note> - Do you know the characteristics and how to optimize your code right now? Again, leave a small comment. If that code ever does become problematic, you will love yourself for putting that
-- Investigate: Is X faster than Y?there. Similarly, you will love yourself for putting it there if it doesn’t become problematic, because you didn’t waste hours swizzling vectors in different directions, or implementing a quadtree for a frustum culling system which didn’t need it.
There are of course many more. To me, it is important that a programmer can answer a lot of these subconsciously, and that they have the capacity to think about them. It will save them time, and that time will go towards making the important parts of their codebases better.
Conclusion
In conclusion, writing good code is easy, but keeping a codebase clean over the course of months or years requires consistent effort. Obsessing over small details, or optimizing before code works or is causing performance issues can waste a lot of time which would be better spent elsewhere.
If you’d like to get started disarming the trap, repeat after me:
- code I write will be slower than it could be.
- code I write will not be as nice as it could be.
- I am building a product, not a codebase.
- I will stay hydrated, get plenty of sunlight, and sleep regularly.
This isn’t to say you should half-ass your code or leave something broken / incomplete, fix those by all means! This post is about time management, not perfectionism - that’s its own beast. Writing code which is below average lets you dedicate time where it matters the most, which is generally a moving target.
Where to Next?
If you liked this writeup, you may like:
- Another One Bytes the Dust - Bytecode - What It Is, and Why You Don't Need to Learn It
- Game Programming Patterns | Free Online | Places to Buy
- The Art of Game Design, a Book of Lenses | Purchase
(this link is not an affiliate link, and has no tracking.)
