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.
Give it 200 years and programming will probably be thought of as accounting. Well paid and nessisarily, but hardly revolutionary.
PS: Salaries have generally stagnated over the last 10 years suggesting supply and demand are well matched. Their is a lot of stratification, but most programmers make well under six figures.
I don't think we can ever standardize programming any more than we can standardize humanity's collective goals and ambitions.
Plumbers still need to get things to work in your house, but tools and techniques have largely removed guesswork. The end point will be different than accounting, but I feel the trend is clear with knowledge replacing the need for extreme generic problem solving skills.
‘Design Patterns’ are of real though limited value, that’s a meta example of exactly what I am talking about.
Programmers should be making closer to 200-300k per year; but then everyone else would be making 30 or 40 dollars an hour minimum wage.
Supply and demand aren’t well matched, considering the job posting out there. But there’s a lot going on influencing all of this
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!
Or, most other fields have already transformed the world. Programming is in the process of transforming the world. So it looks to us as if it is unique.
That said, most of us have pretty plain jobs. And most of what we write isn't that impressive. But still, just like you can invent a completely new gadget (that is likely useless), you will always be able to invent a completely new piece of software (that is likely useless).
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.
That's with barely any thought - I expect there are more.
This is such baloney. I understand that many programmers want barriers of entry to their chair at the office but rationalizing it is self-deception.
The author is essentially saying to write strcmp() "self-explanatory" rather than the a black box description like:
strcmp() is useless without knowing what the return values mean and reading the code to figure it out is way more time consuming than reading the docs.
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.
"When it comes to actually documenting code itself, as opposed to producing documents that can actually be read by non-programmers, the best programmers I've ever known hold a universal sentiment: write self-explanatory code and don't document code except in the places that you cannot make it clear."
I would say eg. Doxygen style function documentation or that strcmp() doc. I linked falls under documents non-programmers wont read.
Hi is emphasizing writing "little" good documentation over "write crap nobody will read". Is it really a good advice to new programmers about documentation?
Can everyone who have spent their career cursing former coworkers that wrote too much code documentation raise their hands. Congrats you were working in heaven.
I'd say when in doubt, write comments. 'How', 'why' and 'what' ... and 'when' and in what order. But that's a matter of taste of course.
When the algorithm itself really needs verbose documentation, or if the code it's intended to be used for instruction (incorporated into a book, for example), there's always literate programming.
The notorious Unix comment mentioned here https://en.m.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_... is actually a good example of a situation where a comment is needed to explain the rationale of the code. At the same time, it was clear to the documenter that the situation was too complicated to be made totally clear by the comment alone (or by reading that piece of code in isolation.) That is the kind of situation in which a comment is necessary, but also inadequate. That is the difficult reality behind this advice: comments don't really work that well when you really want them to.
Another interesting example on comments is the original implementation of 'cat'. A lot of comments.
V2 of Unix had no comments in cat.
It's a extreme example, but I know which one i would prefer to debug or modify.
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.
Proceeds to have 40 pages
You mean sometimes.
How to become a better programmer makes some kind of sense, though the short answer is similar: write more code.
Which leaves no time to fill the ether with noise, so it's a double win.
How does this end up on the front page in the first place?
Because the chapters for instance under 2.0 are absolutely spot on.
The rest are absolutely as well. Are what you say? Spot on!