How to Be a Programmer: A Short, Comprehensive, and Personal Summary (2002) [pdf]

As for not hard--I don't know. We have an unusually high paying career, which companies do not do out of the generosity of their hearts. They have a limited supply of people that can do it. Quite a few people show no aptitude at all. At the high end, it merges into pure computer science, with an essentially unlimited amount to know. So, you can draw badly, or become a professional artist. Certainly, a person can program badly, but I don't think you can call it "not hard" any more than you can call anything else "not hard".

I wouldn't, and don't, romanticize it. It often just sucks. And programmers can often come with pointless, inflated egos from some view that they do something special, and I would like to see a check on that and those pointless egos deflated. But "not eating the world" and "not hard" don't really check out, from my perspective.

Like blacksmiths, programmers are capable of building tools that not only change the way they work but enable new kinds of work to be done, often by making previously onerous tasks trivial, and giving the individual a much large potential impact.

Unlike blacksmiths, programmers can share their inventions with the entire industry in the blink of an eye. So the rate at which the programmer's toolchain can change is indeed special.

Sure, it can also be glorified plumbing at times, but I think we think programming is special because it is.(Not that that will continue to be the case forever.)

I think if you look in the communities formed by any groups of people sharing professions, you'll find a similar magnification of the importance and uniqueness of that profession: humans generally have a tendency to find the stuff they spend the most time around more significant, and often forget that the significance-difference is in perception only.

That said, because of software's generality (in terms of the number of domains it's applicable to), it is relatively unique.

We're also entering a new era of the difference between cutting-edge or transformative engineers, and (the still respectable, but more normal) standard dev.

I do some pretty basic science based engineering. It's not special, it just helps some business people in my firm. But the deepmind guys are special, and there really isn't anything like it right now in other fields. The potential seems unbounded right now, that's really exciting!

Programmers, even those of us working outside of the valley, therefore demand high wages - ultimately because of amoral unicorns and deceptive business practices. The demand outstrips supply, making programmers in other roles overvalued as well. This leads to a sense of entitlement, and a perception among programmers that we are somehow superior by virtue of our chosen career and the skills that accompany it.

This in turn leads to outsized egos, unreasonable tolerance of bad behavior, and toxic culture.

"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more"

-- Alan Perlis

No credentials. All it takes to be a programmer is appeasing somebody in a 30-60min interview. What other white collar career can you say that about? It takes more to be a truck driver.

A gnarly function in C will sometimes be impractical to fully 'comment'. English is too verbose and imprecise compared to the code. But, in particular, inserting uninformative comments that explain simple statements (statements that can be clearly understood by reading the line of code) is a known rookie mistake. It can lead to a case of not being able to "see the wood for the trees"—how the code works is still obscure, but every line has a literal translation in the accompanying comment.

Googling "don't comment code" brings up a number of articles and blog posts discussing this issue. One thing people sometimes say is that comments should explain 'why', not 'what', the code does, e.g. an explanation of what the algorithm is doing, where necessary, rather than a description of each programmatic operation. That kind of comment is like a gloss on what the function is doing, or a conversational explanation of the procedure that the code implements.

Again, this is not about documenting interfaces.

Without documentation, you're left with merely: the code is supposed to do whatever it happens to do right now. Systems like this are terrible to work on. At best, you have to verify O(n) call points across the entire code base whenever you touch any function. At worst, that interface is already public, and you can't ever "fix" anything.

What's clear for one person is not for another. Ancedotally, most people don't write as a good a code they think they are.

Because the chapters for instance under 2.0 are absolutely spot on.

Edit:

The rest are absolutely as well. Are what you say? Spot on!