Ask three Computer Science geeks their “programming philosophy” and you’ll get four different answers. I don’t have a direct answer, as I borrow from different schools of thought, and simply have a handful of Canon.
Canon of Simplicity
Following the tradition of Worse is Better, I strongly believe that code should be simple above all else. A lot of people like writing large bodies of code, with complex options and switches. They consider it “more complete”. I don’t. nPr tells us that if your program has two binary options, then your program has four conditions it needs to account for. If it has four binary options, it has sixteen conditions, if it has six binary options, it has sixty-four conditions, if it has ten binary options, it has one-thousand and twenty-four conditions it needs to account for… While some people go “ya but…” and have excuses or defenses, the bottom-line is that you’re increasing the complexity, decreasing the security, and exponentially increasing the likelihood of “bugs” with every feature you add. Do one thing, and do it well.
This doesn’t mean I don’t build large systems.
Canon of Modularity
In the mid-1990’s, I wrote a Visual BASIC class to implement Perl-like associative arrays (hash maps). It’s very small, probably 20 lines of code. It’s Provably Correct. Anytime I need an associative array construct in Visual BASIC – or even if I would just prefer one, I’ll include that class module, and be on my merry way. I can cite hundreds of similar examples.
By adhering to the Canon of Simplicity, I write small, usually Provably Correct modules of code that can be combined into a larger system. If every module of code is small, self-contained and doesn’t make assumptions as to what other pieces of code will or won’t do right, and those modules are then combined together, the system as a whole stands a chance of being resilient against defect.
Canon of Correction
I detest the term “bug” when dealing with software.There are no “bugs” in the code! Something didn’t just crawl in and misplace a semi-colon. A gremlin didn’t truncate a file before checking for a lock. You did that. YOU. YOU fucked up. Programmers make mistakes. By dehumanizing those mistakes and giving the blanket excuse of “bugs”, we’re failing to own up to our own foibles, and worse, generally failing to learn from them. “Oh, I squished the bug”… In other words you didn’t bother looking for others, or prevent them from occurring again, did you, propeller-head? It’s not a bug, it’s an error. Your error.
All of your code has a battery to test discrete operations with known input and assumed output or actions, right? When you find an error, you don’t just bang on the keyboard, wipe your brow, and say “phew, I squished the bug”. Nay nay! You update your test battery such that it finds that error and balks as such. Then you bang on the keyboard, rerun your test battery, and ensure it is happy. This prevents regressions.
You’re not done yet. Don’t push out a new release. Don’t make a press memo. You think and search for other cases where that error or errors of the same family may have occurred. Chances are, you just learned something by fixing that error (e.g. “wow, it’s a bad idea to truncate a file before checking for locks”), so go fix it everywhere.
You’re almost done, code monkey. You’ve found the errors, updated the test battery, corrected the errors, and you’ve updated production code: now you need to fess up. Fully document the error, where it was found, what flawed logic was used to cause it, and what the appropriate remediation was. Cite the test battery check number. Be humble. This serves not just the informational/educational purpose of documentation, but also allows patterns to percolate (e.g. “Gee whiz, we’ve had an awful lot of problems with Function X, maybe someone else should take a look at it?” or “Wow, Code Monkey Y keeps making the same type of mistakes, maybe we should send him for training (or to HR for termination)” or “Hmmm, Module Z has consumed 80% of our man-hours, maybe we should break it down a bit as it may be too complex”).
- Update test battery.
- Fix all occurrences.
- Document the error.
Canon of Alignment
Primum non nocere. It is imperative, as a programmer, that the code written not be used for harm. Not to harm a system, as in a virus. Not to harm someone’s privacy, as in a spy tool. First, do no harm.
There is nothing more important in human existence than honor. I don’t care about mythologies, politics, popularity or peer pressure: Your honor as a human is all you have to define yourself by. The people who run (directly or indirectly) the code you write are trusting your integrity… Your honor. While you may feel you are superior to them, and have the Right to spy or be malicious, you are not… and you do not. You are not entitled to your job, thus justifying a virus to hold your employer hostage. You are not entitled to certain benefits, thus justifying a siphon to augment your perceived salary inequity. You are not Lord or Lady of the Realm, thus justifying espionage of the communications, files, or existences of others.
It is a violation of the Canon of Alignment to do these things surreptitiously or irresponsibly. If they’re within the scope of your official duties, there is no collision, although perhaps you might make a moral check all the same.