Your Favorite Programming Quote

“If builders built buildings the way programmers wrote programs, then the next woodpecker that came along would destroy civilization.” - Unknown.

“Thomas Dolby – The man who put Apple software into a Coleco Adam computer and came up with the first computer with the knowledge of good and evil.” - Comic strip I saw in college.

“In C expressions, you can assume that *, /, and % come before + and -. Put parentheses around everything else.”

Steve Oualline (C Elements of Style)

Two RSS feeds of programming quotations:

"Quotations from the World of Programming (softwarequotes.com)"
http://feedchopper.ning.com/index.php/main/feed/showUrl?id=2848668

"Programming Quotations"
http://feedchopper.ning.com/index.php/main/feed/showUrl?id=2833755

“If it’s not documented, it doesn’t exist.” -unknown

The thing I’ve read that most describes why I like to program is the section titled “The Joys of the Craft” from chapter one of “The Mythical Man-Month” by Frederick P. Brooks, Jr.

Some examples:

“As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design.”

“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.”

“The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.”

@David H

The quote is by Dijkstra, and it’s my favorite of all time:

“Computer science is no more about computers than astronomy is about telescopes.” - Dijkstra

The most important one for me is not about software only, but still applies: “If it ain’t broke, don’t fix it”.

And here’s one from today that I think is relevant, if not actually aphorismical:

You’ll be better off if you not only keep the actual datas, but also compare the original estimate with the actual result in a project post-mortem. 2007 Scott Hanselman.

And here’s one from today that I think is relevant, if not actually aphorismical:

You’ll be better off if you not only keep the actual datas, but also compare the original estimate with the actual result in a project post-mortem.

OK, the actual link is: http://www.hanselman.com/blog/SoftwareEstimationRememberThatTargetsAreNotEstimates.aspx

Speaking of McConnell, did you happen to catch his letter to the editor in IEEE Computer last month, where he refuted a (stupid) article which actually claimed that software engineering isn’t an actual discipline of engineering? Steve totally shut that guy down – IMO it was a ridiculous article to have been published in Computer in the first place…

Paul Graham has some good ones: http://www.paulgraham.com/quo.html

Every program has at least one faulty line of code.
Every program can be shortened one line.

Conclusion: Every program can be reduced to one single faulty line of code.

Probably the two biggest influences: Bertrand Meyer and Niklaus Wirth, both of whom I have the big fortune of knowing personally (but then, I studied at ETHZ, so that’s no big surprise).

Biggest influence in the “trying to avoid doing the same thing” way: Bjarne Stroustrup (after having attended one of his lectures about C++).

The biggest influence I have had is from blogs like this. Here are some I really like to follow:

  1. coding horror
  2. blogs.msdn.com (Microsoft developer blogs)
    e.g. http://blogs.msdn.com/devdev/
  3. http://headrush.typepad.com/
  4. http://www.charlespetzold.com/blog/blog.xml
  5. Google blogs (check out at googleblog.blogspot.com)
  6. And the numerous links you get from these

Some books that have really helped me are:

  1. Programming Pearls
  2. Code Complete
  3. Applied .net framework programming
  4. Win32 API

Sesh

my favorite is
The three chief virtues of a programmer are: Laziness, Impatience and Hubris.
by Larry Wall

as it matches with my moto when programming "be lazy"
lazy as in http://www.paulgraham.com/procrastination.html by paul graham

I think the method name DestroyCity is confusing,
are we destroying the instance of the city object
or are we attacking a place represented by the city object?

Terminology and percieved or dual meanings can change a clear and concise piece of code (in one persons mind) into a confusing and uncertain piece of code (in another persons mind)

“Software Engineering: A study akin to numerology and astrology, but lacking the precision of the former and the success of the latter.”

from: http://www.softpanorama.org/SE/index.shtml

As the author points out, (Slightly Skeptical) Software Engineering Links. I would have never believed it coming from a more mature engineering discipline (i.e. electronics) but having been in the software dev world for 17 years (and still programming)… it is only too real.

Scott Meyers and his book “Effective C++” both rule!

I’d definitely say Steve McConnell’s ‘Code Complete’ was a major influence; also Steve Maguire’s ‘Writing Solid Code’ and Jon Bentley’s ‘Programming Pearls’ books.

My favourite saying (tongue firmly in cheek) is:

“It was on fire when I found it”

“If you have a problem that requires a regular expression to solve it… you now have two problems”.

Someone at work told me this, A quick google search reveals this quote is probably the origin:

‘Some people, when confronted with a problem, think "I know, I’ll use regular expressions.” Now they have two problems’.
—Jamie Zawinski, in comp.lang.emacs

Boy oh boy, reading these just re-affirms: programmers sure are boring!