Programming Principles


Here are a few principles that have helped me in my programming career.

Reasoning from first principles

Fundamentally, programming consists of inputing a series of 1s and 0s into the computer such that it does something interesting. If we start from that context it allows us to reason about programming paradigms, “best practices”, programming languages, frameworks, etc with a pro-engineering mindset. In other words, we examine the problem and grab the right tools for the job.

This is compared to what many programmers do, which is identify a problem and then grab their favorite tools to solve the problem. In other words, the only consideration is programmer ergonomics.

Learn skills over tools

Prioritize learning the fundamentals of programming over learning tools. While tools are useful, they will always change or die. If we focus on tools - instead of skills - we’ll always be dependant on someone else to provide us with the “hot, new mental model” of how to program.

Reinvent the wheel

If you’ve been on Stack Overflow for any amount of time you’ve probably seen a comment like this, “Just download {insert_package_here}. Don’t reinvent the wheel”. That statement should be rejected outright. It is merely an abstraction for one of the following (all of which are negative):

  • Bad logic: Since its creation, the wheel has been fundamentally perfect for the problem it solves. Of course, it’s been iterated on over the years, but the basic idea hasn’t changed. If you’ve ever used software you know that “fundamentally perfect” is not one of its attributes.

  • Bad assumptions: “Just download some package” makes the assumption that developer time is the most important metric to optimize for, as compared to performance, simplicity, robustness, etc. And even that assumption is wrong because it assumes the package won’t bring any additional complexity - outside of integrating with its API - that will slow down development.

  • An excuse for lack of understanding: Out of the three, this is the most nefarious. As humans, when we don’t understand something, we’ll come up with excuses to justify our ignorance. The reason I use the word “nefarious” is because that impulse comes from a subconcious level, and since all humans do it, we tend to accept it as a reasonable argument. It’s not. It’s an excuse.

I’m not saying we should build everything from scratch at all times. That’s not practical. I’m saying we shouldn’t assume the current tools are worth using simply because they exist, and sometimes we should build things from scratch.

Simple does not mean easy

I got this one from Rich Hickey. It’s a brilliant talk.

As programmers we often confuse “easy” with “simple”. It’s “easy” to run npm install to create a new React application. However, the results aren’t “simple”. If we want to build robust software we should to avoid conflating “easy” with “simple”. That’s all I’ll say here. For a much more elegant and informative conversation listen to Hickey’s talk.

That’s it for now

There are other useful principles, but that’s enough for this list.