Your Favorite Programming Quote

  1. "I don’t care if it works on your machine! We are not shipping your machine!"
    It’s the blog tagline of one Ovidiu Platon, Romanian Microsoft Student Partner [link ]
    Unfortunately it disagrees with the “Works on my machine” Certification. Damn shame!

  2. "If the user can’t find it, the function’s not there"
    It’s my blog tagline :slight_smile: [link ] I’ll probably change it and keep it for when I grow up.

  3. "In theory, theory and practice are the same. In practice, they aren’t even close"
    It can be applied to many fields, but goes great with programming.

You can have it:

  1. Good
  2. Fast
  3. Cheap

Pick two.

great one!!!

I like one Robert Martin told me once. I asked him how you convince the uninitiated that Test-First was the right way to program, and he responded:

“Would you rather Test-First, or Debug-later?”

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook

C++ Class’s, Friend and Private Keywords:

“Only a Friend is allowed to touch my privates.”

From a college teacher I had, while comparing two lines of Fortran – one which was “human readable” and a second one that was syntactically and functionally correct, shorter, but gibberish:

“The programmer who wrote this should be shot, but then again, many programmers should be shot.”

“Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.” - Edsger Dijkstra

I have many favourites. Just two of them that fit in the context of this blog:

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – John F. Woods

“We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We’ve seen the victims’ agonies and helped burn the corpses. We don’t know what causes it; we don’t really know if there is only one disease. We just suffer – and keep pouring our sewage into our water supply.” – Tom Van Vleck

Some people program with rocks. Others use a hammer. I prefer a contractors’-grade pneumatic nail gun with a belt-fed magazine. Have fun “becoming one with the metal”, I’ve got real work to do.

– Said many times in response to “VB programmers are not real programmers”.

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

Note that, I don’t take this as an influence :slight_smile:

When they first built the University of California at Irvine they just put the buildings in. They did not put any sidewalks, they just planted grass. The next year, they came back and put the sidewalks where the trails were in the grass. Perl is just that kind of language. It is not designed from first principles. Perl is those sidewalks in the grass -Larry Wall

It’s from here:,_LarryType=Q

Disclaimer: I don’t know Perl. But that’s one of the smartest things
I’ve ever read. Not strictly related to programming.

C programmers never die. They are just cast into void.

A boss gave me a book years ago called “Systemantics” (now unfortunately renamed to “The Systems Bible”) by John Gall, a pediatrician of all things. It used to be you’d order it from the good doctor’s office personally, but now it’s on Amazon and available to all. Anyway, this is a tongue-in-cheek-but-still-quite-worthy look at systems theory, including how systems are built, work, and more importantly, how they fail. And we’re talking all types of systems, of which computer systems are only one small part. I have passed on this book to more people than I can count.

The book is full of quotable lines, especially around the “axioms, theorems and corollaries” Gall puts forward. Here is a sampling. He uses other people’s ideas and quotes (with attribution), but much of the book is original, and given that the first edition was published in 1975, if you think someone else said it first, you may have to prove it predates the Ford presidency:

o Cherish your exceptions.

o New systems generate new problems.

o Systems tend to grow and as they grow they encroach.

o A temporary patch will very likely be permanent.

o People in systems do not do what the system says they are doing.

o The system itself does not do what is says it is doing.

o Systems attract systems people.

o A complex system that works is invariably found to have evolved from a simple system that worked.

o In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.

o Any large system is going to be operating most of the time in failure mode.

o If it doesn’t fail here, it will fail there.

o When a fail-safe system fails, it fails by failing to fail safe.

o In setting up a new system, tread softly. You may be disturbing another system that is actually working.

o Experience isn’t hereditary - it ain’t even contagious.

o The message sent is not necessarily the message received.

o Every picture tells a story - but not the same story.

o You can’t not communicate.

o The meaning of a communication is the behavior that results.

o Loose systems last longer and function better.

o Great advances do not come out of systems designed to produce great advances.

And my personal favorites:

o Systems develop goals of their own the instant they come into being.

o Intrasystem goals come first.

Anything by Donald Knuth.

There’s one quote I’ve read that was attributed to him that went something like:

“Computer scientists study computers in the same way that astronomers study telescopes.”

I can’t remember the exact phrasing, and google isn’t helping me.

On design:

Perfection [in design] is achieved, not when there is nothing more to add, but when there is nothing left to take away.
– Antoine de Saint-Exupry

Make everything as simple as possible, but not simpler.
– Albert Einstein

On user queries/feature requests:

On two occasions I have been asked [by members of Parliament!], ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
– Charles Babbage

On the importance of testing:

Beware of bugs in the above code; I have only proved it correct, not tried it.
– Donald Knuth

“Simple things should be simple, and complex things should be possible.” - Alan Kay

“no ethically-trained software engineer…”

What does that about the Microsoft software engineer who wrote a href=""HideTaiwan()/a

“documentation” for HideTaiwan() method

“…In fact, never ever use gets() or sprintf(), period. If you do - we
will send evil dwarfs after you.”

–FreeBSD Secure Programming Guidelines

A couple of my favourites are Kernighan’s Law:

“Debugging is twice as hard as writing the program, so if you write the program as cleverly as you can, by definition, you won’t be clever enough to debug it.”


On friend functions in C++ Scott Meyers wrote:

“Friends, much as in real life, are often more trouble than their worth.”

^^The latter I don’t believe is true, but I find it to be quite a window into a man who dedicated his book to his dog.