The Difference Between Programmers and Coders (2013)
workfunc.com
workfunc.com
Either coders=programmers and we should expect increasing competition and decreasing wages, or self-described programmers need to somehow distinguish themselves from the unskilled "coder" masses.
Yet in these very comments, every response I've seen is essentially endorsing the "coding is easy and anyone can do it" message.
It's strange to see so many otherwise intelligent people advocating for their own marginalization. Doctors would never say things like "everyone should learn medicine" or "anyone can be a doctor." Instead they erect barriers to entry to eliminate competition and force you to pay for their services, driving up the cost of health care, and the stupid general public loves them for it.
What is wrong with programmers? Are we simply too egalitarian for our own good?
Programmers are simply confusing the fact that people are attempting to learn it and succeeding in greater numbers than before with the idea that all these new entrants all think it's easy. The truth is I see them all say it's damn hard, but if they put the work in they can learn it.
Another thing they realize after getting through my book is just how long it'll take to get good. They don't take what they've learned lightly, and they don't think it was trivial to learn. What this ends up doing is giving everyone who attempted it a healthy dose of respect for what we do.
I'm a coder. I've been a coder a huge chunk of my life. This attempt to label "coder" as some kind of idiot is really pissing me off, especially when I see it coming from programmers who don't realize that more people learning an introduction to code means more people will appreciate and understand what they do.
Now, the site is down so I haven't read the article, so take my comment as only replying to what you said, not the article.
If you want to call yourself a coder, fine. However, there is still a difference between Linus Torvalds and someone who, for example, has at most hacked a few things together in JavaScript, and I think the terminology should reflect that in more ways than just "beginner" and "expert."
I also think calling ourselves "coders" and calling what we do "coding" isn't going to gain us the respect or prestige that terms like "software developer" or even "programmer" would. If you're happy being called a "coder," in the sense of "Zed Shaw is a great coder," that's fine, but personally, I'm not.
> Now, the site is down so I haven't read the article
It was down for me too. I was responding to the comments that seemed to take great offense at the apparently horrible, elitist idea that maybe, just maybe, it might be worthwhile to have a term that distinguishes professional developers from people who've done some exercises on code.org.
Second, the idea he presents as coder is actually a basic operation done by programmers at many different levels. A good analogy would be to liken it to a carpenter hammering nails. A good carpenter might spend many hours planning a project on paper, but at some point someone has to hammer the nails. It might be him, it might be an apprentice (read: junior programmer).
Finally, I may be reading the comments in a different light than you, but I don't think anyone is using this forum to claim that programming, or even "coding", is an easy task. It is a skill that takes training and practice. As you get more skilled, you might find yourself doing less of the implementation or not, depending on your career. However, it is exactly that experience and increased skill that warrants the high salary.
You wouldn't pay an apprentice carpenter a lot of money for those cabinets, but for a master...
For certain values of do it.
Doctors would never say things like "everyone should learn medicine" or "anyone can be a doctor." Instead they erect barriers to entry to eliminate competition and force you to pay for their services, driving up the cost of health care, and the stupid general public loves them for it.
Doctors, like real Architects (i.e. not software or information ones!), and real Engineers, are a regulated and certified profession because when they make mistakes, someone dies, not because it is an economic advantage for them to be so. What you are describing is something more akin to the guilds system for craftsmen, which is not something I think you should aspire to or want to return to.
I imagine some part of software production will become codified and regulated in the same way in time - that part which deals with life or death situations or produces medical equipment for example. As software grows to eat the world this might start to encompass more of the profession, but probably there will always be a large area of software which just doesn't matter enough to be codified and regulated (I'd include in that most of the work that companies like Apple, Amazon, Google, and web startups do - advertising or most websites can lose money when they go down, but it doesn't risk lives). I'm sure you can think of a case where software risks lives, but the vast majority does not. So I don't think this comparison is helpful.
As to driving up the cost of healthcare, try comparing countries and you'll see costs are more related to the system of insurance and breadth of coverage than how much doctors are paid.
What is wrong with programmers? Are we simply too egalitarian for our own good?
Perhaps it is enlightened self-interest. The more people who know how useful software can be (if only in a small way), the more willing they will be to commission it. Monopolies of knowledge are easily undermined anyway, and why not try to improve the lives of others in a small way by encouraging them to automate filling in their spreadsheet or other daily tasks with a little scripting for example?
If you have sufficient experience or talent, lots of other people learning to code/program/engineer/whatever label you prefer should be the last of your concerns.
http://www.slate.com/blogs/moneybox/2013/11/20/doctors_pay_u...
http://www.washingtonpost.com/blogs/wonkblog/wp/2014/01/13/w...
http://www.slate.com/blogs/moneybox/2013/02/19/nurse_practit...
The only takeaway of value is that, yes, there can be a functional difference between designing logic and implementing it. This in no way means you can only do one or the other, or that any specific job or title dictates that you'll do one or the other.
This might as well have been titled, "The difference between a senior developer and a junior one."
In any case I think that the English speaking CS pioneers have failed to coin a good term for their field - CS just isn't right, especially regarding the English definition of 'Science'. It also leaves non-CS-degree holders who practice this job in a sort of vacuum about what to call themselves.
Definitely. And even the "Computer" part causes confusion. I'm a C.S. professor. The man on the street thinks I teach people to use MS Word. Alas, so do many textbook publisher reps, along with the occasional prospective student.
An architect is different. You have to understand the picture as a whole. You have to understand that one stupid decision can affect the entire product or company's future.
Hurrying to implement excellent code (as a programmer) won't could cost the company many weeks or months or effort to redo.
All this could be summarized in one sentence: Programmer is a writer, like Orhan Pamuk, coder is a translator from Turkish.
Or, according to the classic - programmers are "mappers", they are inveting abstractions. Coders are "packers", they are writing piles of Java classes for a paycheck.
Even simpler. Coders are Georges. (Those who have seen SICP lectures would understand instantly).
Update: my two cents to what it is to be a writer.
Look, there are a standard qwerty keyboard in front of you. All required symbols (letters and digits) are here. You know the rules how to compose them into words of English, and how to chain words info sentences. So, go ahead, open a notepad, or even Emacs, and write, say, 1984. It will be much better than any silly startup, you don't have "to Java", you need no AWS and Docker, you don't have to hide the fact that you cannot grasp Design Patters, etc.
All you need is in front of you, all the knowledge is available since secondary school. You could even apply some agile practices.
It also could be that you are esthetically sophisticated person, so you may would like to use a fountain pen and paper, or a pencil and a notebook - just go ahead. We are not asking about poetry or, god forbid, classic music composition, which is even closer to what programming is.
It fell into that dubious genre of essays that draws a false dichotomy that there is no particular reason to believe is real, then puts all of the positive characteristics on one side, so that readers have a new label to apply to themselves so that they feel good, and a corresponding label to apply to everyone they don't like.
I wasn't impressed by that addition to the genre at the time, and I've seen nothing since to make me think that I should have been.
If you truly believe that, and believe that people can be so divided, then I suggest that you read https://plus.google.com/+JeanBaptisteQueru/posts/dfydM2Cnepe and discover that for all you think you understand about how things work and why, there are things you just use.
Indeed I can give you dozens of examples of important things that impact your life, ranging from the reason why fertilizer makes good high explosives to how airplane wings work, and you'll find that for all that you pat yourself on the back for being such an intelligent and curious person, you're far more someone who just uses that which you find around you than someone who understands your world.
If you can accept that, then you might get beyond your naive belief that you bring enlightenment that I have failed to grasp, and you may come to see why I think that the purported distinction is BS.
After that, you might realize why I became curious about how a theory that is so obviously BS would appeal to otherwise intelligent people. And then you might find my theory about it to be enlightening.
Hint: the distinction is not between so-called technologist and non-technologist, not even between engineering and liberal arts education, so the link is irrelevant.
If one choosed to be a software engineer, note the word "engineer" one have to have understanding of underlying principles, general ideas upon which design of this or that component is based, and implementation strategy which was used. One cannot just ignore complexity and treat everything as black boxes and someone else problems. But so many do. This is the distinction.
You you got a motorcycle you better have to understand how it works and why important design decision has been made, based on what line of reasoning. Then you will be able to have real confidence, based on understanding, not that anxious one which is based on a belief and hope. With this you will be able to do maintenance, fix problems, and complete your journey, instead of praying that nothing will go wrong. It is that simple.
Lots of people are very comfortable with beliefs and hope instead of knowing the details. They emphasize the "getting shit done" approach and usually become quite irritated when asked questions beginning with words "why" or "how". We call them "packers".
You better read the books.
Btw, when MIT guys like Abelson and Sussman are saying "ignore everything below this level of abstraction" or "use the black box abstraction" they doesn't mean being ignorant and literally having no idea what's going on down below. They do have understanding of CS theory, EE and Physics. So no, no country for ignorant.
Just because someone writes something flowery and nice doesn't mean that they are right, or that their distinctions are a useful way to understand the world.
Take professionals around you who seem uninterested in what you care about. Assume that they are interested in something that they can teach you. Find out what it might be. Learn it from them.
If you're like me, you'll quickly find that the mapper/packer dichotomy only served as a fancy intellectual justification for flipping the bozo bit on people whose curiosity about the world happened to be about things other than what you paid attention to. You might also learn something interesting about anything from negotiation to accounting to local laws.
I studying good old CS books and AIMs or watching some online courses this way.
Don't believe me? Consider Zen and the Art of Motorcycle Maintenance for a second. The main character of that book is mechanically inclined. But are you? Could you, for instance, explain how a simple mechanical device like a differential works? Probably not. Therefore in some sense you fail to be the kind of person that Prisig was describing. Not because you lack interest, but because your interest is in a different area.
(BTW if you're curious, http://www.youtube.com/watch?v=yYAw79386WI has an excellent explanation of how a differential works.)
When you start doing this, you may find something interesting. You'll notice that people like tptacek, whose actual skills should properly impress you, have great respect for people like patio11. Why? Because tptacek recognizes what patio11 is better at than he is, and can respect patio11 for that, at the same time as patio11 is very clear on what he is and isn't good at.
So what is patio11 good at? It is very simple. He's good at figuring out how tech people can market themselves. This may not be a skill you care about. Not one you wish to learn. But one that tptacek sees value in.
And that is how life goes. We each specialize. Some things we choose to learn. Other things we need to know who is good so we can know who to go to to do it. And the whole is bigger than the sum of the parts.
Just make the transition from looking down on people who choose to be good at things you don't, to accepting and respecting them for what they are. You may be surprised at how much of your life smooths out.
Or you can choose to sit in your little corner, on top of your mountain of specialized knowledge, sneering at the world to make up for the fact that others don't respect you in the way you think you deserve to be respected. And then wonder why people don't enjoy being around you.
As for attitude towards other people, it is really difficult problem, because lots of our attitudes are based on social conditioning and effects of environment which heavily influences what experience we had and most importantly how do we interpret and consolidate them, a bunch of feedback loops between different "agencies" of the brain.
In other words, culturally I am lower class Russian, which means I am treating other people in a different way you do. For me, for example, so called respect never to be taken for granted, but to be earned or to be a consequence of other person actions. So called "cultures of honor" are too much concerned with how others behave, it is silly, but it is what we are.
So, I do respect guys like Hickey or rtm or antirez (there are few more) because not only I could appreciate what they have done, but I know what it takes to be able to perform like that. It is like a person could really have a respect for those who is capable to run 15km non-stop only when he himself could run at least 10. Then you know what it takes.
So I cannot respect any talking heads or so called consultants simply because I know what it takes. Not very much.
Another example is books. As long as you progress as a reader you possibly could realize how very very few really good books are here (it is not a matter of popularity or cover annotations, of course) and the general amount of nonsense around you.
You're like a person who can run 10 km nonstop and therefore respects someone who can run 15 km. But since you've never tried riding a bike a long way or swimming, you don't respect people in those professions.
If, instead of turning your nose up at them, you were to try those other professions, then you might find yourself developing some respect for what it takes.
That's kind of where I am. I have learned some things in depth. But I've learned enough about enough things that I have come to expect there to be something real to learn to be good at pretty much anything I don't already know. Since I'm smarter than most, I can learn a lot of things relatively quickly. But I still can find ways to treat people who know things that I don't with respect.
Additionally, the repeated line "no single company can deal with that entire complexity" is misleading. I can provide examples of companies that deal extensively with most if not all aspects of each individual layer presented.
The truth, though, is that thinking about all the layers together can and likely will make most people dizzy. As for companies? I would propose that a hypothetical company, let's name them "IBM" for convenience, could theoretically deal with each and every layer presented, and I'd estimate they could do so successfully for 50 years or more.
That said, there is no company that does deal with each layer in all complexity. Even IBM outsources. But the reason does not have to do with it being too complex as much as too standardized.
The economic theory of the firm says that firms divide when the internal stupidity of a large firm exceeds transaction costs between several. But as an area standardizes, stupidity remains unchanged and transaction costs reduce - meaning that you get more smaller firms. There is an excellent chart that I think I saw in The Innovator's Solution which shows the resulting fragmentation of the semi-conductor industry over the decades.
It is possible to program a computer without coding. Currently, the tools to do this are very domain specific.
I think, in the future, there will be domain agnostic development tools that will let people program software without the need to write code.
It is important because programming doesn't always involve coding.
It is important because language can limit or expand our thinking and definitions play a role in that.
I think it is important to strive for moving away from coding as the primary means of programming a computer so we can democratize software development. So, we should not redefine the definition of programming to be "coding a computer".
> since it's not done on a regular basis
I don't think this is a very good litmus test.
> usually is called "configuring", or "defining workflow" but not "programming"
We used to say "program a VCR".
The word is even defined as "the action or process of writing computer programs." There is no mention of coding as being a required aspect of the programming process.
If you consider people who use scratch (http://scratch.mit.edu/) as coders, then I would agree with you.
But, to me, it doesn't look like they are coding. It looks like programming using something other than coding.