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.
I would not hesitate to recommend Fred Brooks' No Silver Bullet. It was written 20 years ago but still remains true today.
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.
Portrait of a Noob is wonderful: the opening quote is stunning and the idea is both sophisticated and well-articulated.
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.
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. http://www.joelonsoftware.com/articles/fog0000000017.html
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.
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.
I realize we've already seen plenty of Joel, but you simply must read this one: In Defense of Not-Invented-Here Syndrome
Teach Yourself Programming in Ten Years
Not exactly about programming but computer science nonetheless:
Computational Thinking
Computing is a Natural Science
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.
Picture Hanging made a huge impression on me when I first read it.
"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.
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.
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.
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.
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.
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.
Link: http://news-service.stanford.edu/news/2005/june15/jobs-061505.html
I really liked Jack Reeves essays about Code as Design:
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
This is a great one: http://oreilly.com/catalog/opensources/book/larry.html .
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.
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.
Programming is Hard, Let's Go Scripting by Larry Wall.
I recently re-read and continue to be inspired by Larry Wall's 2007 State of the Onion speech.
Why functional programming matters by John Hughes. (runner-up)
It was my first introduction to FP - sold me on it, and got me interested in Lisp.
UNIX co-inventor Ken Thompson reports on how he hacked his own C compiler.
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.
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.