What is your favorite essay about programming? Something which has made you think, or made you a better programmer. Something that you feel portrays the field well, or maybe that was just hilarious to read.

Some of my choices would be some of Paul Graham's essays, such as Hackers and Painters. The Cathedral and the Bazaar is also up there.

+15  A: 

I would not hesitate to recommend Fred Brooks' No Silver Bullet. It was written 20 years ago but still remains true today.

Greg Hewgill
It's so good that I think every developer should re-read it every 2 years or so.
David G
+4  A: 

Even though not exactly an essay and somewhat outdated, I always liked the Interface Hall of Shame. A good read if you're doing GUI design. And, of course, Joel on Software. I especially remember one of his essays, but I can't find it. Guess I have the link at work though.

+12  A: 

Portrait of a Noob is wonderful: the opening quote is stunning and the idea is both sophisticated and well-articulated.

Michael Easter
Excellent post +1
Gurdas Nijor
+8  A: 

Joel's The Perils of Java Schools is fantastic. It makes me glad that I had a well-rounded education with respect to languages, and has inspired me to continue learning/studying. The points about Map-Reduce and Google are bang-on.

Michael Easter
I read that too. The only problem with it is that the statement that you can't implement MapReduce in Java is incorrect. Hadoop, for example, is a MapReduce implementation in Java.
+2  A: 

I hearken back to an old essay by Joel called "Good Software Takes 10 Years, Get Used To It". It was a good long term perspective, that I,a few years out of college, needed to see.

+5  A: 

The transcript of the ACM Turing lecture given by Edsger Dijkstra should be compulsory reading for all programmers who are "fresh from the farm", a.k.a. college, uni., etc.

Please, please read it and enjoy.

Rob Wells
+1  A: 

I like "How to be a Programmer: A Short, Comprehensive and Personal Summary", by Robert L. Read. You can find it here.

Besides the technical stuff, it is also oriented towards team skills, communication and working with other people. It`s really interesting and the essay is divided in three levels: begginer, intermediate and advanced.

+7  A: 

I realize we've already seen plenty of Joel, but you simply must read this one: In Defense of Not-Invented-Here Syndrome

Russ Frank
That. Is. Awesome. It seems that far too much emphasis is given to the work that using someone else's code saves you, as opposed to the work it costs you.
+16  A: 

Teach Yourself Programming in Ten Years

Not exactly about programming but computer science nonetheless:
Computational Thinking
Computing is a Natural Science

+20  A: 

I'll throw in a word of warning about Joel Spolsky. He is a great businessman and writer, but he is no computer scientist.

When Spolsky writes about human issues -- business, management, recruitment, methodologies and so on -- he is second to none. When he writes about technical matters, he often gets it wrong, and he's such a good writer that, if you don't know any better, he will lead you seriously astray.

For instance, he defends Hungarian Notation on the grounds that Hungarian Notation allows us to perform static checks on our code. It never occurred to him that he could have used the type system to automate these checks.

So enjoy his writing, but take the technical stuff with a pinch of salt.

Edit: A commenter has asked me to explain what I meant about type systems.

Joel's argument goes something like this:

People say that Hungarian Notation is dumb, because it just replicates what the type system does. There's no point in prefixing an i to a variable name, just to remind ourselves that it's an integer. The compiler already knows that iFoo is an integer -- if you get it wrong, the compiler will spot your mistake.

That's true, but we can encode other information in Hungarian Notation. For example, we can encode whether a string is "safe" (i.e. it has been sanitised, or comes from a trusted source) or "unsafe".

What Joel doesn't seem to realise is that we can trivially encode this in our type-system too. That's what type systems are for!

E.g. in C/C++ we could have a struct called safeString which acts as a type wrapper around a string:

struct safeString { string the_string };

At run-time, a safeString is identical to a regular string, but at compile-time, we cannot mingle the two without explicit casts. Then we just need a function like:

safeString sanitize (string str) { /* sanitizing code */ }

and we're done.

If you want to be more sophisticated about it, you could have a hierarchy of string types. Some functions work with all strings. Some only work with safe strings. Some only work with unsafe strings.

I hope that makes sense.

Would you care to give an example of using the type system to automate those checks? I'm especially interested because the examples he cites have to do with variables that are the same type, but serve different purposes (like say pixels and twips, or distance and totals).
I think the OO approach would be to create a pixel class and a twip class. This way the typing system would catch you trying to treat a pixel as a twip and vice versa. Though I never would design something that way, it's certainly better than relying on Hungarian notation.
Kyle Cronin
well, in that article he explicitly says that Hungarian notations should not be used to prefix every integer variable with an 'i' and so on, but to add more useful info. So I don't know if that fully applies...
A type system will never be able to tell you that you've mixed up screen coordinates with window coordinates or utf8 cstrings with ascii.
Rhythmic Fistman
Why couldn't a type system have screen coordinates and window coordinates? Apart from the fact that you will normally be at the mercy of a third party API when dealing with these things.
Rhythmic Fistman: Type systems can and do perform exactly those kinds of tasks all the time. They can handle window vs screen or utf8 vs ASCII just as easily as int vs float vs string. If you want to get a feel for the possibilities, try learning Haskell.
@dysfunctor not true!!! you can't have read the Joel article because you have made the same mistake. MS changed apps HN (HN applied to a variable's _name_) to sys HN (HN applied to the _type declaration_ of the variable). BTW Totally agree with you about some Joel technical articles. Yeesh.
Rob Wells
That Hungarian stuff always made my skin itch -- thanks for articulating why. There's a more general rule here, right? Covers this, and putting dates in file names, and putting podcast series titles in the title of every episode. Don't overload a name?
For an example of doing exactly what it suggests in the article, see this paper:
Agreed on the Hungarian, but there may be some cases where you can't do that for some reason (perf, legacy API, etc.). Still, I'm an advocate on using the type system for that, but I still find it useful that the original intent of Hungarian was for that type of validation.
+5  A: 

Picture Hanging made a huge impression on me when I first read it.

Very entertaining =P. I'm not a professional developer yet, but I can definitely see how something analogous to the picture hanging example can happen.
+6  A: 

"Real Programmers Don't Use Pascal" is a classic, both of humor and self-awareness.

Real programmers don't play tennis, or any other sport that requires you to change clothes. Mountain climbing is OK, and real programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.

Part of the joy of the article may well be lost on anyone under not old enough to remember "Real Mean Don't Eat Quiche" from 1982.

Andy Lester
+4  A: 

From Mythical Man-Month: The Joys of the craft

Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. 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.

Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.) Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures,produces sounds, moves arms. 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.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

Artur Carvalho

"Computer Power and Human reason" (not an essay - but a short book)



Neither of these are what the OP had in mind I assume, but they are pretty timeless

+3  A: 

For something that really focuses the mind take a look at Richard Feynman's appendix in the NASA report on the Challenger disaster.

It's not specifically about software, but does give a good description of software done right, and how badly it can go if you do engineering all wrong.

Andrew Edgecombe
+5  A: 

I'm surprised nobody mentioned something from Paul Graham, like Why nerds are unpopular. He is one of the most "philosophical" software essayists, so to speak.

Reminds me of ytcracker - meganerd (remix by tanner4105). Loves that text.
Wonderful essay!! Thanks for the link.
Mark Lubin
+1  A: 

Not really an essay but Code complete by Steve McConnell was an inspiration. I read it every year. @amason

+1  A: 

I saw this question earlier today and then when I came across and read this - link text - I immediately felt compelled to come and leave it as an answer.

Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.

+7  A: 

Ryan Tomayko's How I Explained REST to My Wife.

Bill the Lizard

Thank you for another insighful post! I admire your ability of pointing out (by blogging) little things that others don't take the time to mention


+2  A: 

Not directly about programming, but Steve Jobs' talk at the Stanford really got into me and made me think. The things he talks about are very practical, so you can easily relate to them with your life and see what he means.


+1  A: 

I really liked Jack Reeves essays about Code as Design:


This is a great one: .

+2  A: 

This essay by Paul Graham. It's not exactly about programming, but it's good mind-stuff to chew over, and definitely rings a bell with those whose 'passion' is programming.

+3  A: 

While less relevant today, this 1968 letter to the ACM, Go To Statement Considered Harmful by Edsger W. Dijkstra, is a classic of computer science:

For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.

Yeah, this is probably the most famous paper in Computer Science.
+1  A: 

Paul Graham's web site has a large collection of his essays. Some of them make for an interesting read.


"Distributed Computing Economics" by Jim Gray of Microsoft Research. It got me interested in high performance computing research.

+1  A: 
+2  A: 

The Humble Programmer by E.Dijkstra

Nicolas Dorier

Reflections on Trusting Trust

UNIX co-inventor Ken Thompson reports on how he hacked his own C compiler.


A plea for lean software, by Niklaus Wirth


On the cruelty of really teaching computing science Edsger W. Dijkstra


Zen and the Art of Motorcycle Maintenance

I've read this twice and want to read it again. Many insights, especially in the art of investigating and fixing defects.

Jeffrey Kemp

Charles Petzold's Does Visual Studio Rot the Mind?

Dominic Rodger

Mine's Edsger W Dijkstra's 831: Why numbering should start at zero.

I mostly love the concise elegance of the statement, and the very "human" aspect added by the last paragraphs.

Felix Ogg