The Difference Between Programmers and Coders (2013)(workfunc.com)
workfunc.com
The Difference Between Programmers and Coders (2013)
http://workfunc.com/differences-between-programmers-and-coders/
13 comments
First, the terms don't mean different things, despite the authors intention to make it so.
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...
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...
No, this isn't really the case. What I see, as the guy who wrote the book that tells people that learning to code is hard but possible, what people are realizing is that programming is hard, but possible.
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.
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.
Indeed. A little out of reach from where is sit is Jon Bentley's More Programming Pearls: Confessions of a Coder. Bentley certainly did not take it as derogatory term.
> 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,
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.
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.
If anyone can apparently do it with a few weeks of training, why should they be paid $80-100+k?
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.
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.
This is exactly the sort of thing I'm talking about! Doctors in the US are the highest paid in the world because of protectionist laws that don't allow foreign doctors to practice (no H-1B competition), that prevent new medical schools from opening, and that make them the only legal source of many health services like prescriptions (in many states), and yet people like you continue to defend them:
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...
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 difference is a matter of arbitrary semantics. The quote in the beginning is nothing more than a setup of an argument from authority (http://en.wikipedia.org/wiki/Argument_from_authority).
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."
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 German we use a different terminology for the whole field. It's called 'Informatik', as in the science of processing information. The people doing this are thus called 'Informatiker'. This alone helps, I feel, in making people understand that there is some degree of formal training behind it, that 'Informatiker' aren't just code monkeys. Granted, many still use the term Software Engineer today, simply because Engineer degrees have a higher entry barrier and thus have a better sound to them (you can get 'Informatiker' degrees without a higher education by doing an 3-4y apprenticeship at 16, a very common way of how education works in Germany and Switzerland).
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.
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.
> ... 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'.
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.
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.
[deleted]
I believe the author merged the responsibilities of a "programmer" with an "Technical architect". To become a good programmer, all you need to do is enjoy reading books, enjoy coding, and work at a moderately sized company.
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.
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.
I like this distinction, because to me almost every coder is a programmer, but there are still more theoretical positions such as technical architects who don't necessarily even touch the code.
Oh, come on.) btw, the first chapter of The Programmers Stone explained almost everything about two decades(?) ago.
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.
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.
I remember The Programmer's Stone.
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.
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.
I think that you somehow did an analysis of writing style instead of the meaning. The distinction is quite simple, some people are interested in how things work and why, others just use them (usually in a wrong way). I suggest you to read Zen and Art of Motorcycle Maintenance, it is about exactly the same segregation, but in a much more poetical wording. And then at least a half of Atlas Shrugged, to complete enlightenment.)
The distinction is quite simple, some people are interested in how things work and why, others just use them (usually in a wrong way).
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.
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.
As a polymath, your linked post was hardly enlightening.
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.
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.
My point in the linked post was to show for one common technology how no individual person can really understand it. At some point we have to switch from understanding to just using.
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.
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.
I sense lack of familiarity with suggested readings, so I doubt that "otherwise intelligent people" stuff.
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.
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.
Actually I have read the suggested readings. I still think the world view that you have on this is a poor match for reality.
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.
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.
Of course! It is up to a reader to decide what is right and wrong, good book are just beautiful artistic artifacts, much like some violin concerts or very few painting. Sorry for too banal sentiments.)
Here is a fun exercise for you.
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.
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.
It is murderously hard to find a real, no-nonsense competence. Usually all you got are narcissistic types like patio11 and talking heads.
I studying good old CS books and AIMs or watching some online courses this way.
I studying good old CS books and AIMs or watching some online courses this way.
It really looks to me like you flip the bozo bit where you shouldn't. It is really hard to find a person whose interests and competence match that which you are interested in. But it is easy to find someone you can learn useful stuff from whose interests don't so align.
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.
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.
The main character of the book is not mechanically inclined, he is inclined, so to speak, with necessity to understand and explain, to find out the meaning of things and phenomena he observed. The quest for the Truth (only to find Quality instead, or a "perfect" Balance as it called on the East) is a state of mind, which is roughly a mix of curiosity, logical reasoning, imagination and persistence. Some call such set of traits the scientific mind, and some call it our Buddha nature. The book is about minds, not motorcycles.
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.
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.
I like your analogy, and will take it a step further.
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.
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.
Lengthening "code" to "encode" then coding is "encoding something". What you mention as the next level is being able to distinctly invent things worth encoding.
The difference is hubris.
I would consider most of the points as the difference between a senior "Programmer" and a junior "Programmer" rather than "Coder".
Potato - Potahto.
It's from the same side of the argument as the "Software Engineer is not really an Engineer" phrase.
Google cache text version: http://bit.ly/1gZj3kQ
I think it is important to distinguish between the two.
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 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.
coding is a synonym for programming. No need to distinguish the two. If you can program you can code, if you can code you can program. Talking about software design or architecture is something different.
> If you can program you can code, if you can code you can program.
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.
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.
Why do you think that it's important to distinguish between the two? The fact that it sometimes possible to program a computer without coding does not relay the "importance" of distinguishing, since it's not done on a regular basis and usually is called "configuring", or "defining workflow" but not "programming".
> Why do you think that it's important to distinguish between the two?
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.
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.
It's good for us, developers, to know the difference between you :).
Hmm, The site takes too long to load.
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?