The centerpiece of Atwood's post is this passage:
Writing programs that the computer can understand is challenging, to be sure. That's why so few people, in the big scheme of things, become competent programmers. But writing paragraphs and sentences that your fellow humans can understand -- well, that's even more difficult. The longer you write programs and the older you get, eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.
Of all the cruel tricks in software engineering, this has to be the cruelest. Most of us entered this field because the machines are so much more logical than people. And yet, even when you're writing code explicitly intended for the machine, you're still writing. For other people. Fallible, flawed, distracted human beings just like you. And that's the truly difficult part.
I concur with Atwood and Devlin that there is a strong link between coding and writing.
I did my undergraduate study at Rose-Hulman which specializes in science and engineering, and although it does not offer degrees in the humanities, the leadership at the school strongly encouraged a respect for language, literature, and the arts. Indeed the president of the school at the time, Sam Hulbert, exhorted the student body to be "Renaissance Men" (it was an all-male school at the time :-) ). I took this advice to heart, working hard to hone my skills as a writer.
I had two additional influences during my years as a student. As a junior and senior in college, I took classes taught by Prof. Stuart Leipziger, who whose eloquence as a lecturer was profound. I don't think my understanding of heat transfer and thermodynamics would have been as enriched without his ability to illustrate and enlighten.
In graduate school, I had the good fortune to take a class by the late Prof. J.J. Carberry, who was not only a distinguished scholar in the field of reaction engineering, but also a very gifted writer. His textbook, Chemical and Catalytic Reaction Engineering, uses a writing style seen rarely in the field, rich in its choice of adjectives and elegant in its flow.
These experiences shaped my outlook towards communication, helping me to realize how much of a difference could be made by channeling energy in that direction. By thinking through the process of expression, the weak points of a position could be identified, thereby giving guidance on how to refine the ideas that comprised them.
Back in the mid-90s, when I was trying to make a transition from FORTRAN to C programming, I picked up a cheap book titled C Programming Proverbs and Quick Reference. The author, Ron Wodaski, put lots of emphasis on being a conscientious programmer, someone who was not only coding to solve the problem of the moment, but also solutions that could be reused and maintained by others.
Early on in the book, Wodaski borrows the notion of a "Reader Over Your Shoulder" from the book by that name, written by Robert Graves and Alan Hodges, to instill a sense of self awareness about one's own code.
Calling this awareness the "Programmer Over Your Shoulder" (or POYS, for short), Wodaski pictured him or her as being an intelligent, friendly, yet uncompromising software developer who sits with you as you write code. He even goes so far as to give the metaphorical awareness a name. He called his POYS "Clarence".
One of the goals of having the POYS was to catch yourself when you were about to cut corners on coding. While it is hard to see your own mistakes as you write code, it isn't hard to feel it in your gut when you're about to do something half baked. Maybe it's deciding not to write some comments about some code that's less than obvious, lying to yourself that you'll get back to it later, or perhaps it's deciding that throwing in sanity checks to protect against an error condition would be just too much trouble, given the deadlines that must be met.
The POYS fusses about the things you'd rather ignore, but you know deep down that you shouldn't. It can take some self discipline and brutal honesty to develop a helpful POYS. I believe that Wodaski's writings, published in 1992, presaged the onset of pair programming, which attempts to do code review in real-time. Instead of trusting yourself, you get a real-life POYS to help keep you honest.
At the heart of Atwood's paradox is the central truth that meaningful computation seldom occurs in a vacuum. Time, talent, and treasure are devoted to programming because it is believed that computer applications can satisfy a human goal, be that to inform, to engage in commerce, to facilitate logistics, to forecast future conditions, or even to provide amusement.
These applications operate within the context of an imperfect world. Network hardware fails, people overdraw their bank accounts, bad weather strikes, models get created with faulty assumptions, and people try to circumvent security infrastructure. Useful code has to take into account these and many other edge cases. The firm logic of a programming language must be molded around this imperfect surface of reality.
Careful communication helps mitigate the turbulence of confusion. Agreeing on precise use of terminology helps avoid misunderstanding between product owner and development team. Regular status meetings with meaningful commitments and accountability help keep things on pace. Well documented specifications help developers blaze the trail, and accurate comments help the maintenance programmer follow along. Relevant documentation helps the end user assault the learning curve.
The gift of expressiveness both in code and prose makes a software engineer more valuable because he or she must bridge the worlds of the flawed but forgiving human and the logically rigid, unforgiving, yet incredibly stupid machine.
