Developer Wisdom: Proverbs, Laws, and Humor in Code

When it comes to programming, do you have any of that wisdom?

The engineering of software is sometimes perceived on the outside as a purely clinical and mathematical subject. Ask any developer, and he or she will tell you that coding is an art form, a psychological fight, as well as a science. As tech culture has evolved over the decades, it has produced its own folklore in the form of hours spent late into the night, sitting in front of a computer, trying to fix something that doesn’t work.

We like the idea here at Quotenestify that one witty proverb can convey a universal truth. In the programming community, these “laws” and jokes are not only funny, they are a distillation of hard-learned knowledge turned into pithy sound bites.

Whether you are an experienced software developer or a tech curious outsider, these four developer proverbs give a hilarious and insightful look into the reality of software development.


1. A fun game about a law, and a headache.A fun game about a law and a headache, Karlton’s Law.

The two things that are hard in Computer Science are cache invalidation and naming things.
— Phil Karlton

The Context:
This is a famous quote from Phil Karlton, a one of the founders of Netscape that was dropped in the 1990s. It has since become the unofficial software engineers mantra, with some programmers adding “off-by-one errors.

There was a message in the laughter:
Why are these two such rough punishments?

To keep temporary data fresh is the nightmare known as Cache Invalidation. Having a system that updates and displaying the new data rather than the old and saved data is surprisingly complicated, if the user is to see the new data.
The simple idea behind Naming Things is its simplicity: A codebase is a place where communication is non-negotiable. Naming a variable or function that will be completely understandable to another person three years later is an art.

Karlton’s law: in computer science it is not the algorithm that is the most challenging part, but rather the memory and human clarity.


2. Coding for Humans is Fowler’s Dictum.

A computer can read any code as long as it is written by anyone, but a good programmer writes code that can be read by humans.
— Martin Fowler

The Context:
This is a quote from Martin Fowler, a well-known Software developer, who is an authority on Software Architecture. He was looking to break the stereotype of the “genius coder”, who writes really dense, unreadable, code just to show how brilliant they are.

The Funny Thing is, There’s a Learning Curve to It:
Computers are dumb and will carry out any instructions given to them, even if they’re quite complicated. The actual art of the engineer is to make your logic understandable by other people (or you in six months time). Fowler’s quote changed the culture of the industry to more “clean and expressive” code. It advocated the concept that code is a medium of human communication first, before it is a machine instruction.


3. Brooks’ Law: The Mythical Man-Month

The more people the merrier, but the more people the later an agressive software project.
— Fred Brooks

The Context:
The Mythical Man-Month is a book, published in 1975, by Fred Brooks that was based on his experience in IBM managing massive software projects. But when the projects started falling behind, corporate managers did what they always did – they threw more people at the problem. It backfired spectacularly.

The wisdom that lies behind the humor:
It makes no sense in business, but it does in tech, which is why it’s called Brooks’ Law. When you’re bringing new developers on a failing complex project, two things happen:

The Training Tax – Existing developers have to cease working to bring the new developers on board and train them.
Communication Overhead: As the number of people grows, so do communication paths, resulting in confusion and alignment problems.

This is a law that is still a problem for project managers today and one that developers cite whenever a deadline is missed in development.


4. The Six Stages of Debugging: A Psychological Journey

1. That can’t happen.
2. That’s weird.
3. Shouldn’t happen.

  1. Why is it that?
    5. Oh, I see.

6: How did that ever happen?

— Anonymous Internet Folklore

The Context:
This is not the case with the other entries: this one isn’t credited to an individual tech luminary. Rather, it is a trope of the early developer forums that spread like a meme and is still prevalent on the office cubicle and in Slack channels.

The Wisdom Behind the Humor:
This is the exact mood swing that every developer knows. Debugging is a embarrassing exercise in psychological de-flation. You have a “That can’t happen” attitude when you write the code, get it confused and end up with an answer that you realize you just made a stupid error hours ago. The last phase (“How did that ever work?”) points up the terrifying fact that sometimes software doesn’t even really work – it has been cobbled together via digital duct tape.


The Power of Code Folklore

Our communication networks, our cars, our banks are all run by code; code is written by flawed, brilliant humans. These proverb sayings are the cultural glue for the technology community. They are a reminder to developers to be humble, to write simply, and to be willing to ride the absurdity of a computer doing exactly what you told it to do… even when you told it to do the wrong thing.

Rajesh Khanna

Written by Rajesh Khanna

Rajesh Khanna is a quotes and captions writer with 5+ years of experience helping people find the right words for every moment. He has helped thousands of readers express their feelings through Instagram captions, heartfelt wishes, and meaningful quotes.

Link Copied!