Pearls of Wisdom for Software Development

We’re putting together written content to supplement our usual software training for 2020. Throughout, there will be some interspersed inspirational quotes and ideas to inform, guide, enlighten, and entertain the budding software developers.

What’s your favorite pearl of wisdom related to writing software?


There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.


I also highly recommend Akin’s Laws of Spacecraft Design. They’re aerospace-oriented, but many of them are extremely relevant to software development.


Programs must be written for people to read, and only incidentally for machines to execute.

  • Harold Abelson

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

  • John Woods

Walking on water and developing software from a specification are easy if both are frozen.

  • Edward V. Berard

Computers make very fast, very accurate, mistakes.

  • Gus Michel II, @GeeTwo (I’m sure he heard it from somewhere else)

The computer programmer is a creator of universes for which he alone is the lawgiver. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or field of battle and to command such unswervingly dutiful actors or troops.

  • Joseph Weizenbaum

It’s a curious thing about our industry: not only do we not learn from our mistakes, but we also don’t learn from our successes.

  • Keith Braithwaite

Good design adds value faster than it adds cost.

  • Thomas C. Gale

Programming is the art of breaking down a process to the point that a lightning infused rock can perform it.

  • Gustave Michel III (I’m sure I heard it somewhere)

There is nothing quite so permanent as a quick fix.

  • Unknown

To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge.

  • Grace Hopper (Believed to be Mis-attributed though)

One accurate measurement is worth a thousand expert opinions.

  • Grace Hopper

You manage things, you lead people. We went overboard on management and forgot about leadership.

  • Grace Hopper

A good programmer looks both ways before crossing a one-way street.

  • Unknown

First, solve the problem. Then, write the code.

  • John Johnson

Experience is the name everyone gives to their mistakes.

  • Oscar Wilde

Every piece of software written today is likely going to infringe on someone else’s patent.

  • Miguel de Icaza

Computers do not solve problems, they execute solutions.

  • Unknown

I love deadlines. I like the whooshing sound they make as they fly by.

  • Douglas Adams

The future is here. It is just not evenly distributed yet.

  • William Gibson

Adding manpower to a late software project makes it later!

  • Fred Brooks

Only half of programming is coding. The other 90% is debugging.

  • Unknown

The nice thing about standards is that there are so many to choose from.

  • Unknown

A computer will do exactly as it is told, nothing more, and nothing less.

  • Gustave Michel III

Insanity: doing the same thing over and over again and expecting different results.

  • Albert Einstein

If you can´t explain it simply, you don´t understand it well enough.

  • Albert Einstein

In design, complexity is toxic.

  • Melvin Conway

You’re bound to be unhappy if you optimize everything.

  • Donald E. Knuth

Simplicity is prerequisite for reliability.

  • Edsger W. Dijkstra

Code never lies, comments sometimes do.

  • Ron Jeffries

I’ll also be sure to offer the opportunity to my co-workers. Though, knowing my Team Lead, I’ll surely have to filter any responses for “appropriateness”.

1 Like

You can pretty much find one of these every other page in The Mythical Man-Month - Wikipedia .

IMHO it’s one of the best programing resources I was exposed to in College.


When you have a bug in your code that you see the first time you try to run it, you will be able to fix it in no time at all, because all the code is still fresh in your mind.

If you find a bug in some code that you wrote a few days ago, it will take you a while to hunt it down, but when you reread the code you wrote, you’ll remember everything and you’ll be able to fix the bug in a reasonable amount of time.

But if you find a bug in code that you wrote a few months ago, you’ll probably have forgotten a lot of things about that code, and it’s much harder to fix. By that time you may be fixing somebody else’s code, and they may be in Aruba on vacation, in which case, fixing the bug is like science: you have to be slow, methodical, and meticulous, and you can’t be sure how long it will take to discover the cure.

-Joel Spolsky


Top notch development teams don’t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.

To add to all this… programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying competitive salaries!

-Joel Spolsky


“640K is more memory than anyone will ever need on a computer” - Bill Gates


Less of a quote and more of a saying:

Read the entire error message before doing anything.


I’d give a spin through one of my favorite Twitter accounts:


I disagree. Reading the story in it’s entirety leaves no room for adventure.


1 Like

If you try to make it idiot-proof, someone will come up with a better class of idiot.


Ha, all extremely excellent so far!

I’ll share the two that hang at my desk:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

  • Brian Kernighan

“Programs are meant to be read by humans and only incidentally for computers to execute.”

  • Donald Knuth

This applies to a lot more disciplines than software:

  • There’s never enough time to to it right the first time, but there’s always enough time to fix it.
1 Like

I think a lot of the Go Proverbs can be applied to programming in general.

1 Like

Along similar lines, The Zen of Python is pretty good too.


When I write code, I tend to use longer, more verbose variable names that describe exactly what is going on

I also like to use tons of comments for anything thats less than obvious

I also comment the flow of the program/class

I need to follow my own advice more for our FRC code


FRC-specific first line of defense debugging:
“Did you save it?”
“Did you compile it?”
“Did you deploy it?”

So many “errors” that were actually just the robot not having the new code >.<


Advice I give to FRC teams a lot is:

“Keep simple things simple; don’t make complex things unnecessarily complex.” - Bjarne Stroustrup, CppCon 2014: Bjarne Stroustrup "Make Simple Tasks Simple!" - YouTube

I paraphrase it as “don’t overcomplicate it”. The vast majority of teams can get a moving robot with feedback control in like 20 lines of code. FRC teams like to write over-abstracted fluff when it’s really unnecessary.

Also, don’t reinvent the wheel. Chances are there’s a library component that does what you need, and it’s better written and tested than what you’d write yourself. Forgoing it for learning is fine, but don’t sacrifice a successful robot for that reason.