Gleaned Axioms

This is a list of common-sense axioms and wisdom that universally apply to CS. It’s the CS-based version of this page.


Roosevelt’s Law of Task Planning – Work with what you have, not with what you hope to have or might exist later.

Since computers advance so fast, all previous analysis and efforts were made in a different time period, so anything over a year old is the soft social science of history.

There’s no universal ideal solution, but there are ideals for use cases. There are also more wrong solutions than right ones.

You only legitimately understand something either the third time you see it or the first time you teach it.

You’ll never have all the information, so start the analysis as soon as possible and reconfigure often.

Make guesses when in doubt, guess in an emergency, but always clean up the mess later.

You’re not as smart or experienced as everyone else in the industry. If your analysis says your prototype will run faster than Google, you may have invented a new mathematical proof, but it’s more likely you missed something.


Atwood’s Law – If it can be, it eventually will be written in JavaScript.

Cupertino Effect – The stupidity of computers means they’ll frequently override a common use case (like “cooperation”) for an obscure one (like “Cupertino” instead of “co-operation”).

de Saint-Exupery’s Law of Design – A designer doesn’t achieve perfection when there’s nothing left to add, but when there’s nothing left to take away.

Greenspun’s Tenth Rule – Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp.

  • Morris’ Corollary – This includes Common Lisp.

Miller’s Law – All large-group discussions about a small software update will eventually include discussing huge redesigns, adding features, or replacing that software.

Liskov Substitution Principle – When inserted into a system, a subtype must be interchangeable with its parent type (e.g., if Type B is a subtype of Type A, then Type A can fit into everything that Type B fits into).

Shea’s Law – The most significant design improvements are in its interface, but are also easiest to screw up.

von Tiesenhausen’s Law of Engineering Design – To share your understanding, learn to draw, since the finished product for some reason always ends up looking like the concept art.

Zawinski’s Law – Every program keeps expanding until it can read mail (i.e., long-form time-insensitive messages), or will be replaced by ones that can.

Designing something better than requirements is completely uncorrelated to the final product’s quality.

Requirements come from the ability to “do” things, no matter what engineering textbooks say.

The fastest way to solve something is often to throw out everything and start over.


IETF Motto – Be precise in what you send, flexible in what you receive.

Klaiber’s Law – The silicon wafer’s size proportionally dictates the largest diameter of ultra-pure water piping necessary for a semiconductor wafer factory.

Marconi’s Law – The effective distance of an antenna tower is approximately the height of the antenna squared.

The only place where improvements in a chain of dependencies matter are on the slowest components.

The optimum is almost always somewhere in the middle in nature, so distrust assertions that the optimum on a graph is at an extreme point.

System Growth

Metcalfe’s Law – A system’s value grows at about the square of the number of users in the system.

Wirth’s Law – Over time, software gets slower faster than hardware gets faster.

Fixing Things

Hacking and coding is an analytical creative art pursuing vague goals, so failure is a waste of time to take personally.

What works for others may not work for you. How you can use them is more important than what they’ve already done.

After fixing anything, always document the new rules and what happened. Otherwise, you’ve made life worse for someone else (including Future You).

Before you panic or give up, make a simple web search for what you want, since others have probably found the answer.

  • To be more thorough, use appropriate search handles to narrow what you’re looking for.
  • Look for similar model numbers or alternate-language implementations of the same thing.


Don’t use a company account to sign up for something if you plan to use that service longer than staying with the company (which is very likely).

Unless you enjoy the experience, only make a productivity-enhancing system if the work to do it takes less time than the time you save over a year.


The unwashed masses don’t understand computers, but they vote with their wallet, so the tech industry is run by the tyranny of the majority.

The people who build out the winning tech trends are some random guy name Ronald who makes a Unix-based software package called “runk” that stands for “Ronald’s Universal Number Kounter”. Then, big names like Bill Gates and Steve Jobs streamline it and sell it at enormous profit.