There are many quotes from famous computer scientists that have become the wisdom that guides our profession. For example:

"Premature optimization is the root of all evil in programming."

  • Donald Knuth (citing Hoare's Dictum)

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

  • Brian Kernighan

And so on. My question is, what are your favorite words of wisdom about programming from someone who is not famous? Was it a friend, a coworker, or a teacher, or a family member?

For example, a technical writer friend of mine said:

"You can't get the right answers unless you ask the right questions."

Thanks for all the contributions! The answer I selected was (a) specifically coding-related, and (b) stated by someone who is not technically famous (though he has a popular blog and a podcast and runs StackOverflow). I.e. he's no Bill Gates or Yogi Berra.


"The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."

(Tom Cargill)

Because it is scarily true!


"Fast, good, cheap: pick any two."


"Measuring programming progress by lines of code is like measuring aircraft building progress by weight." - Bill Gates


To understand recursion, you must first understand recursion.

42 accepted

I Believe Jeff Atwood said it

Code doesn't exist until it's checked into source control.

I've lost so much interesting software that I've written over the years simply because I never had a system of storing it. Over the last 2 years, I've made sure that just about every thing, including scripts that I've written, have been stored under source control.


Another one of my favourites is from Larry Osterman:

One in a million is next Tuesday

Basically what he meant was computers operate at such high speeds, with so many people using one system, that even bugs that occur only once in a million, still come up quite frequently.


Never be afraid to say "I don't understand".


"It is easier to optimize correct code than to correct optimized code." --Bill Harlan


Not directly development-related, but true all the same...

A computer lets you make more mistakes faster than any other invention in human history, with the possible exceptions of handguns and tequila.


In my very first computer science class in college, the professor said, If you remember only one thing from this class, remember these two things:

A computer does what you tell it to do, not what you want it to do.


The IQ of a computer is zero.


I saw a quote on here about an app. "Software by Stephen King, Interface by Salvador Dali"


Trying is the first step towards failure
--Homer Simpson

This has been proven almost every time we try out a new technology at work.


"The definition of insanity is doing the same thing over and over again and expecting different results." -Einstein

This is my usual answer as to why I don?t want to attend another meeting where no decision making will occur.


I was talking to a guy about Object Oriented Programming, and added:

Just because it's made out of car parts, doesn't mean it's a car.

It promptly was entered into Bugzilla's Quips.


If you don't understand the problem you're trying to solve, writing more code will only make it worse.


Be very careful at what you type into Google Images.


"The software will ship in July, we just don't know of what year."


I think it's a book title.

Learn to program in c++ in just 10 years.

It captures the idea that programming is not something you jump into, and getting good takes a long long time. Anyone who thinks otherwise is a fool, IMHO.


Always make sure the shower curtain is on the inside.


"Measure twice, cut once" - good philosophy for any discipline...


Computer Science is no more about computers than astronomy is about telescopes.

--E. W. Dijkstra


Some people, when confronted with a problem, think "I know, I?ll use regular expressions." Now they have two problems. --Jamie Zawinski


A hard problem is seldom worth solving.

Meaning that if it seems hard you should spend time making it simple: either by understanding it better, by rephrasing it or by limiting (or extending) the scope.


Whenever someone says something like "in theory, this should work..." I sometimes reply with this:

In theory, theory and practice is the same.

I don't recall where it's from, or even if I made it up myself (in that case I probably wasn't the first to come up with it).


A favorite when trying to make a decision.

It is easier to get forgiveness than permission.


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


Stupid should hurt.

Meaning if you got immediate feed back for making that bone-headed mistake, you'd stop.


Can't remember where I heard it, must have been during some tech talk I've watched sometime before.

Regardless of how smart, creative, and innovative your organization is, there are more smart, creative, and innovative people outside your organization than inside.

Encourages open source work, peer review, reminds me not to try and reinvent the wheel.


Every single time I have been clever I have regretted it.

Can't remember who told this one either.


I can't believe these weren't already here:

Garbage in, garbage out


Know Thy Data


To err is human, to really foul up requires a computer


Another classic: "640K is Enough For Anyone".

Althought the quote is not verified, and probably wrong, it is a significant portion of computer science history.


I don't believe in documentation; if it was hard to write, it should be hard to read. Why do you think they call it "code"?




The much underrated:

"If you build it, they will come"

(Field of dreams?)


"i m the best programmer in the world."


"Don`t test what you are not prepared to fix"


None of us is as dumb as all of us.


"Think big, act small, fail fast; learn rapidly"


My all-time favourite has to be Hofstadter's Law:

It will take longer than you think, even if you take Hofstadter's Law into account.



"NOTHING is more important in a database than integrity."

from my friend Eric

"The whole idea of doing this opens up a huge can of Pandora's box" (not specifically IT related but too much fun not to include)

"Crap...I hate it when I drop the wrong table"

from my former boss


We've made a deal with God:

  • He doesn't program,
  • we don't make miracles.

Bugs? My code doesn't have bugs. It has randomly generated, undocumented features!


Quidquid latine dictum sit, altum sonatur.


An of course Murphy's law: "Anything that can go wrong, will go wrong at the worst possible moment."


Don't know whether it is not famous, but it is good advice anyway.

make it work, make it pretty, make it fast


My bit o' wisdom would be this: Don't fix what ain't broke.


Being really good at C++ is like being really good at using rocks to sharpen sticks. ? Thant Tessman


It certainly is famous, but shouldn't be left unlisted:

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away -- Antoine de Saint-Exupery


A computer is like a sewer. What you get out of it depends on what you put into it. -- Paraphrased from Tom Lehrer




(Sadly, I've never seen WAR IS PEACE to apply particularly well in computing.)


Check out my site: http://www.SoftwareQuotes.com - it has an excellent selection of quotations about software development.

Some quotes:

"The software isn't finished until the last user is dead." - Anonymous

"A well-written program is its own heaven; a poorly-written program is its own hell." - Geoffrey James


"Proper Planning Prevents Poor Performance" -- My old boss.


What I usually end up telling my colleagues

  • Stop assuming the code is wrong just because you are not the author of it.

What I usually end up telling my boss:

  • The urgent is done. The indispensable is in progress. For miracles, please forecast some delay.

Programming is communication. Communication is not programming.

-- Myself.

Here's an explanation (spoiler alert?) for those that might find it difficult to grok exactly what this phrase is suppose to mean:

The first part of this phrase is butt naked and means exactly what is says. When we write code - good code, that is - we are communicating ideas and intent, data and process. Not only are we communicating this information to our compiler, but also to our colleagues, the next guy who is going to maintain that code and to our (near) future self.

The second part; "communication is not programming," is a bit deeper and is about communicating with living people, and how different that is from communicating with a compiler. Human languages are full of ambiguity, and often require multiple different explanations before a point or idea comes across clearly. Communicating with people require "people communication." Further, people are not computers. When you ask a person to do something, they will probably not do exactly what you asked. They may do less or they may do more. They may even do something completely different, or what amounts to nothing of value (to you). Not because they are bad, but because they are people.


At a polytechnic they teach you to wash your hands after going for a piss, at university they teach you not to piss on your hands.


At least two. They are more physics, rather than computer science:

"if you always follow the minimum energy path, you are guaranteed that your potential will only decrease" - Me

"When you work in a vacuum, it's easy to fill the room" - Zachary Spencer, here on SO


It's maybe a bit obvious, but one of my lecturers in college pointed this out, and it's stuck with me:-

"If your code compiles, you've written a program. But this doesn't mean that it's the program that you think you've written".

This guy was big on formal proofs...


"For every problem there is a solution which is simple neat and wrong"


"This project is scheduled to be done when hell freezes over. But it may slip." - Keith Reynolds


From ASP.NET MVC 2 Framework by Steven Sanderson, where he tries to fight programmers natural tendency to generalize everything by saying:

Constraints are not limitations; they are insight.

Which I think explain itself.

Oh, and another one-

Assumption is the mother of all f*** ups

-Under Siege 2: Dark Territory


Here's something i came up with one day:

You can't have just madness, you have to have a method to the madness.


Don't try to build multi-threaded application in the languages that aren't designed for it.


"Nothing works until you try it." -- me

Assume everything is broken until verified.

Used in response to questions like, "If we combine feature X and feature Y in a way we've never done before, will it work?" and "Do we handle generic absurd but catastrophic error condition?"

Discovered after spending a week at a remote customer site implementing a clever use of our product I thought should work but didn't verify. We committed it to the customer, it didn't work, so I spent a week in a warehouse in Kansas City implementing said feature.


"Do it right the first time (Bertrand Serlet)"

...meaning, don't hack something together which works mostly, but apply proper engineering. Everything else requires more effort in the future.


Don't de-reference dangling pointers.


If you can't test it, then you don't need it.

Referring to source code. If it doesn't have a testable result, then you might as well use a null statement.

This is particularly true of error handling code. If the error condition can't be created, why try to handle it?


Question: What is the difference between ignorance and apathy?

Answer: I don't know and I don't care. ;)

Synopsis: You can't help someone who is both ignorant and apathetic at the same time, so don't waste your energy.


"El flojo trabaja dos veces" -my friend's Colombian mother

Spanish for, "The lazy person works twice." Applicable to everything.


From "Tips: Ten tips for being happier.":

Anything worth doing is worth doing badly.

For a mountain of wisdom take a look at some of the posts on "Sources of Insight".


Keep it simple stupid! (KISS Principle)

Don't over engineer nor over design the problem you're trying to solve, keep it simple and elegant.

Don't repeat yourself (DRY Principle)

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Never copy and paste code either.

Making progress

Do something every day towards your project, whatever you do now you won't have to do later. Seems obvious but it really helps you move forward on your projects.


"Question your assumptions"


"All of Microsoft's software is written in Visual Basic" -- My IT teacher



"I think most application development involves initial lack of understanding of how to use a particular technology optimally, followed by a downward spiral of workarounds and short cuts" - A developer friend of mine


Even though the compiler doesn't have a GUI, it still is beautiful.

-- me

Always have a healthy disrespect of the impossible

-- unknown


"I don't care how did you do it. It has to work."

My friend told me that when I created a tiny report for him 10 years ago. But It is not what he exactly told me but meaning was same.


In order to understand recursion, you must first understand recursion.

Damn, beat to the punch, I should read these threads first.