Ten Laws of Programming

I originally answered the question, “What are your ten laws of programming?”, on Quora in 2019; I’m copying the answer here for posterity:

Why is it always 10? Why not 7, or 13, or 121? And is that binary 10 or decimal? Or maybe hex 0x10?

Ignoring the specific number, here are some “laws” of programming that I live by:

  1. Understand the abstractions you’re working with, and at least a level or two below where you’re working. Otherwise you’ll make mistakes out of ignorance that destroy performance.
  2. Optimization isn’t premature if it’s profound; Knuth’s quote is about “small efficiencies,” not about major algorithmic improvements. That said, if you’re never going to have more than 10 items, a bubble sort (or the built-in sort!) is fine. Knock yourself out.
  3. Don’t work late to solve a problem. If you’ve spent hours on a problem and it’s getting toward dinner time, put it aside. Odds are good you’ll have a fresh perspective in the morning and that staying up late to try to solve it will lead you to a poor solution anyway.
  4. Don’t work late in general. For most humans you will eventually burn out. That is No Fun At All. Exceptions can be made for the occasional deadline as long as you get time off in compensation.
  5. Don’t start coding until you know where you’re going. No one starts a trip by driving in some random direction, and you shouldn’t start writing any code until you know what direction you should start in. That said, I don’t create documents detailing my trip walking to the library three blocks away, and similarly don’t create extensive documentation for a problem I already know how to solve.
  6. Know your algorithmic complexity.1 It’s not about memorizing how to implement all the algorithms, but about understanding the general shape of algorithms, so that when you’re writing something that’s going to do a lot of work and the “obvious” way to do it is an O(n4) algorithm, maybe you’ll think twice about the “obvious” approach.
  7. Know your tools. If you’re using your IDE or editor as if it’s Notepad (or worse, using Notepad!), you’re not getting the best leverage. Spend some time learning your tools and you’ll become more efficient as a developer.
  8. Know your tools. Yes, I said this once already, but this is for the other kind of tools: Libraries that you can use to help you accomplish things faster. Know what APIs you have available, and understand how you might use them in the future, so that when opportunities to save a dozen lines of code and associated bugs comes up, you can just place a call to a library you’re already using.
  9. Know your tools. Ahem. This time it’s about external tools: Databases, cloud services, message queues, machine learning tools. PostgreSQL has advantages over MongoDB; the reverse is true as well. Know what the tradeoffs are, and don’t just pick MongoDB because it’s familiar. Dig deeper and learn what your tools can do!
  10. Know your tools. We use a lot of tools as programmers, not the least of which is the language you’re using. Don’t satisfy yourself with the surface features of your language; dig deeper. Understand even the more esoteric features. They are there for a reason! This is true for not only your traditional programming language of choice, but SQL and shell scripts.
  11. Understand the needs of your client. Sometimes clients ask for things that seem strange. Understand why they’re asking. Otherwise you may do a lot of work only to have them tell you that you’ve solved the wrong problem. “Your client” includes your boss if the software is internal.
  12. Never Stop Learning. This is well beyond a “law” and a full-fledged mantra of mine. Keep learning. It will keep you relevant, and you’ll find that the more you know, the more you’re worth, and the higher leverage you are as a programmer.

So I guess I had 10 laws…in base 12. Who knew?


comments powered by Disqus