Okay, I’m going to be a little bit far out there. A lot of this seems to be grounded in the negative. “How to deal with x” how to “do y when z has failed”. Some of it technical and some of it interpersonal. Why have we created this sphere around programming? What makes /this/ profession so different from any other? And my believe is: nothing. It’s not hard. It’s not better. It won’t “eat the world”. Heck it probably didn’t make that much of a difference in the grand scheme. It’s just sitting on your ass and either do as you’re told or come up with something better, like 90% of all work. Software is just like any other job, and chances are it is completely stupid like most other desk jobs out there. And if not, the same general skills apply. Stop feeling like it is difficult or even special.
Eh. Most major centers of power have large computing resources changing how they do things. Wal-Mart, for instance, as a basically non-tech company, leveraged computers for stocking and supply chains and became a culture-chaging retail giant. Computers have made their way into cars, and even toasters. We have high frequency trading (done by computers) majorly affecting markets. I could probably go on like this for a while. Eating the world, check.
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.
Most professions have already changed the world. Air conditioning for example dramacily changed how and where people work and play. Plumbing has dramatically reduced the spread of disease. The older professions are so integral to society it’s hard to thing of a world before agriculture or fishing.
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.
High level languages standardized assembly. Tools have increased the amount of knowledge you need to function as a programmer, but they also provide standard solutions to real problems. It’s not like CSS is nessisary for building a website, but it really does both help and replace a lot of custom code.
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.
Salaries have been stagnating because companies refuse to raise the salaries, along with ever increasing inflation. Your 100k job was worth less than a dollar back in 1980, due to inflation.
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
I wouldn’t call Wal-Mart a “center of power”. They’re essentially a market player, and are powerless in the face of market forces. CIA, Kremlin, or even Wall Street (with their ability to extract wealth out of society via laws paid for in bribes) are centers of power, in the way that they really get to impose their will on others.
No other profession has quite the same capacity to transform itself.
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.)
If programming was like blacksmithing there would be a lot of self-built kind-of-working-but-not-really-finished-yet hammer factories, and an inexplicable upsurge in lame horses.
At some level of abstraction all jobs can be made to look similar. It's just not particularly useful to abstract to that degree.
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.
Programming is generally considered more challenging than most professions, and it has a transformative potential that must other fields don't. It's okay to recognize that, whilst also not having an over-inflated view of yourself or elitist stance.
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!
>>Programming is generally considered more challenging than most professions, and it has a transformative potential that must other fields don't.
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.
Software is roughly the way we take ideas that cannot be made in a physical form and put them out there in the world. The idea that 'software' will some day stop transforming the world is just as weird to me as saying physical matter will some day stop transforming the world.
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).
Speaking as a non-programmer, I find computer programming one of the most difficult things I have ever done. In a sense it's a lot like writing. Sure, everybody can write, but few people can write well. Writing a short computer program is easy, but writing a complex program, in a way that it both works and you (and others) understand it, it's the hardest thing.
Programming, in the broadest sense of the word, is hard. Even for the most intelligent people. You don't have to look much around you for crap every day it-solutions, security breaches, million dollar rocket exploding into another planet or medical radiation-equipment killing people instead of curing them.
Programming is special because of the outsized speculation still occurring and the willingness for tech firms to ignore regulations and morality to defeat entrenched players. The amount of money this approach can capture is staggering.
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"
> What makes /this/ profession so different from any other?
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.
Magic does not change the world? I find that difficult to understand. Using obscure incantations to affect the physical world is pretty much mind-blowing, as far as I'm concerned.
It never occurred to me that someone might disagree with that. Obviously sw development is not harder, more complicated or more important than any other trait.
"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.
There are two good reasons for this. First, anyone who needs to see code-level
documentation will in most cases be able to and prefer to read the code anyway
...
More importantly however, is that the code and the documentation
cannot get our of sync if there is no documentation. The source code can at
worst be wrong and confusing. The documentation, if not written perfectly, can
lie, and that is a thousand times worse"
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.
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.
No, you have misunderstood. This statement refers to documentation in the form of comments in source files. You are referring to the documentation of interfaces (e.g. manual pages in Unix) which is definitely required.
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.
I'm not too sure the author means about that, even though you interpretation is possible.
"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.
The idea that this advice means "don't bother documenting APIs" is a straw man which isn't worth arguing about. The "non-programmers" phrasing is misleading, I agree, but the widely held sentiment that the author was expressing is recognizably the one about comments in source files.
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.
Even more importantly, the documentation is the contract. Most languages (and especially C) aren't nearly precise enough to declare a function's complete contract using source code. How would you know if strcmp had a bug, if there were nothing that said what it was supposed to do?
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.
This. Most people who think they write self explanatory code are deluding themselves. While others may see architectural and compile time information, the runtime information especially that concerns with generality of the code, and things it does not do (like the complement of a set) are not at all evident.
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.
I read through some of the Beginner section that I thought seemed inappropriate for beginners and found a number of grammar and punctuation errors. While trying to navigate the file I found that the page numbering shown in the Table of Contents is off by two pages. His advice on "difficult people" sounds like he is talking about a single, specific person but is doing so in a vague way and expects that to function as actionable advice. That seems like a common pattern as I look back on the rest of the section. He talks about what were probably specific events or situations in a very non-specific way and by doing so falls short of providing useful insight. It would be more effective to write about the details than to try to adapt the story to a common experience.
I find the "learn to debug" chapter refreshing. I've seen a lot of new hires on web development area who simply don't interactively debug anything, sometimes even don't log, just because "printing" is enough. IMO we need more bootcamps on fundamentals.
Ehh. A lot of things in the skillset of a capable real-world programmer have little to do with actually writing code, which is the whole point of the book. As can be trivially gleaned by taking a cursory look at the table of contents. And answering the question "how to write better code" with "write more code" is about as helpful as advising a depressed person to just go out and have fun.
My math skills improved the most when I stopped obsessing over studying the right things, or finding the right textbooks, and just constantly solved problems.
Do you have any examples of methods that will get you there more effectively than practice in any discipline? Because I honestly can't think of anything.
