"Programmer" is an Overgeneralization(blackhole12.blogspot.com)
blackhole12.blogspot.com
"Programmer" is an Overgeneralization
http://blackhole12.blogspot.com/2012/02/programmers-are-overgeneralized.html
29 comments
> a PhD, a statistician, and a Risk Management Quantitative Analyst (level II)
As an aside, I really wish that intelligent people would refuse to use their capabilities in the service of evil.
As an aside, I really wish that intelligent people would refuse to use their capabilities in the service of evil.
It's not as boolean as good/evil, but certainly there are ethical challenges to be faced in this particular field. There are many roles to play, so this comment isn't necessarily directed at the parent comment or risk management.
We all know the incredible power of technology. Applying engineering practices and automation to financial markets can be a dangerous game, where the full scope of risk is not yet clear and the repercussions can be disastrous [1][2].
With very few peer-reviewed academic entries and in the wake of the financial crisis of 2008, I would be very uncomfortable applying my skills in this domain. I feel that engineering, if it is to be applied to financial markets, should be centered around bolstering security and reducing risk, not profiteering.
The recession was triggered by a clever system of alleviating risk [3]. When this architecture blew up, financial executives testified before congress citing the "highly complex" nature of the industry as an excuse. I personally do not want to work for this class of people, let alone implement or analyze their trading strategies.
Software is supremely flexible, it can be applied in nearly any industry. We have the ability to wield and program the electromagnetic force of the universe. We can push bits around to genuinely create a better world. That, to me, holds so much more value than a digit in my bank account.
I apologize for the off topic discussion, just wanted to get this out.
[1] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1695041
[2] http://en.wikipedia.org/wiki/2010_Flash_Crash
[3] http://mitworld.mit.edu/video/861
Edit: formatting.
We all know the incredible power of technology. Applying engineering practices and automation to financial markets can be a dangerous game, where the full scope of risk is not yet clear and the repercussions can be disastrous [1][2].
With very few peer-reviewed academic entries and in the wake of the financial crisis of 2008, I would be very uncomfortable applying my skills in this domain. I feel that engineering, if it is to be applied to financial markets, should be centered around bolstering security and reducing risk, not profiteering.
The recession was triggered by a clever system of alleviating risk [3]. When this architecture blew up, financial executives testified before congress citing the "highly complex" nature of the industry as an excuse. I personally do not want to work for this class of people, let alone implement or analyze their trading strategies.
Software is supremely flexible, it can be applied in nearly any industry. We have the ability to wield and program the electromagnetic force of the universe. We can push bits around to genuinely create a better world. That, to me, holds so much more value than a digit in my bank account.
I apologize for the off topic discussion, just wanted to get this out.
[1] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1695041
[2] http://en.wikipedia.org/wiki/2010_Flash_Crash
[3] http://mitworld.mit.edu/video/861
Edit: formatting.
Thnks for the civilized reply.
> I personally do not want to work for this class of people, let alone implement or analyze their trading strategies.
Excellent :p
> I personally do not want to work for this class of people, let alone implement or analyze their trading strategies.
Excellent :p
Unsurprisingly, it appears some people disagree. Maybe they're working for Goldman Sachs.
Unsurprisingly, it appears this community frowns on telling someone they're "in the service of evil" based solely on the fact that they do Risk Management Quantitative Analysis.
Well, W.H. Auden might have considered someone evil based solely on the fact that they were a statistician:
Thou shalt not sit
With statisticians nor commit
A social science.Well, a programmer/statistician/scientist working for "the financial services industry" has only one purpose there: to maximize the amount of money they make, through whatever clever means possible. Who came up with CDOs, for example? High Frequency Trading and their algorithms competing against each other?
In today's world, the financial services industry makes almost all of its money through exploiting the absurdity/loose regulations of our current economic system. Gambling, pretty much. They keep whatever profits they make, and have us pay their losses (bailouts etc). They reap insane profits at the expense of the health of our economies, and they are not the ones to suffer the consequences. It's us little folk.
A "quant" working at Goldman Sachs is just a tool used by the fat cats in charge. Do you think they can work for hedge funds and the like and not have any sense of something being wrong? Going there is a conscious choice. Staying there is another. I bet the unusually big salary helps them rationalize those choices though.
In today's world, the financial services industry makes almost all of its money through exploiting the absurdity/loose regulations of our current economic system. Gambling, pretty much. They keep whatever profits they make, and have us pay their losses (bailouts etc). They reap insane profits at the expense of the health of our economies, and they are not the ones to suffer the consequences. It's us little folk.
A "quant" working at Goldman Sachs is just a tool used by the fat cats in charge. Do you think they can work for hedge funds and the like and not have any sense of something being wrong? Going there is a conscious choice. Staying there is another. I bet the unusually big salary helps them rationalize those choices though.
A lot of times downvotes are for simple disagreement. That doesn't mean it's always the case.
I disagree with the three main points that this article expounds (and I find all three arrogant and patronising).
The first thing I disagree with is the idea that programmers are not all 'programmers'.
My Dad is a civil engineer to everyone except other civil engineers and a guy who drives a truck is a driver as much as a guy who drives a rally car. What's the problem?
Every term, especially those of specialised subjects, has both general and specific forms.
It is neither insulting nor a gross simplification to describe yourself as a programmer to a non-programmer despite the fact that few of us would refer to ourselves with that exact term when discussing our work with another programmer.
Programmer → games programmer → graphics programmer → shader programmer: all programmers.
Programmer → server programmer → database programmer → Non-SQL (Couch DB) specialist: all programmers.
What would the shader programmer call herself when talking to the Couch DB programmer? Would they even know what the other did? Why does it matter that they have to go back up the chain to find the most specific term that they both understand.
Secondly, I disagree with the idea that we are not doing the same fundamental job. The word programmer does not 'cover a stupendously large spectrum of abilities and skill levels' that's a programmer with a superiority complex asserting his own status and the complexity of his career. Both the guy who designs the hardware and the guy who comes out to fix a broken socket at the back of your unit is called a TV Engineer as they are both dealing with the internals of a TV.
Thirdly I disagree that our job is difficult and therefore we are somehow superior—an idea, sadly, that this article reeks of. We deal with data and algorithms that manipulate data. Its not that difficult, which is why so many people do it for a living. If it paid more I'm sure many of us would be dealing with Tar McAdam and telling the world how extremely difficult it was to get it perfectly flat.
The first thing I disagree with is the idea that programmers are not all 'programmers'.
My Dad is a civil engineer to everyone except other civil engineers and a guy who drives a truck is a driver as much as a guy who drives a rally car. What's the problem?
Every term, especially those of specialised subjects, has both general and specific forms.
It is neither insulting nor a gross simplification to describe yourself as a programmer to a non-programmer despite the fact that few of us would refer to ourselves with that exact term when discussing our work with another programmer.
Programmer → games programmer → graphics programmer → shader programmer: all programmers.
Programmer → server programmer → database programmer → Non-SQL (Couch DB) specialist: all programmers.
What would the shader programmer call herself when talking to the Couch DB programmer? Would they even know what the other did? Why does it matter that they have to go back up the chain to find the most specific term that they both understand.
Secondly, I disagree with the idea that we are not doing the same fundamental job. The word programmer does not 'cover a stupendously large spectrum of abilities and skill levels' that's a programmer with a superiority complex asserting his own status and the complexity of his career. Both the guy who designs the hardware and the guy who comes out to fix a broken socket at the back of your unit is called a TV Engineer as they are both dealing with the internals of a TV.
Thirdly I disagree that our job is difficult and therefore we are somehow superior—an idea, sadly, that this article reeks of. We deal with data and algorithms that manipulate data. Its not that difficult, which is why so many people do it for a living. If it paid more I'm sure many of us would be dealing with Tar McAdam and telling the world how extremely difficult it was to get it perfectly flat.
I completely agree and find these comments very accurate.
Plus, I always thought that becoming a programmer meant learning how to make a computer do what you need it to do by learning how to command it in various languages.
Along with that, I always thought that writing this language is a skill required amongst other skills to qualify as a programmer, and another major skill that is required is to be able to walk into many different problem domains, familiarize yourself with them, learn them, understand them, and attempt to fix them with efficiency.
So while there are many specialized types of programming, we are all programmers, just writing our favorable language to speak with a machine, to solve a problem, in domain X.
Plus, I always thought that becoming a programmer meant learning how to make a computer do what you need it to do by learning how to command it in various languages.
Along with that, I always thought that writing this language is a skill required amongst other skills to qualify as a programmer, and another major skill that is required is to be able to walk into many different problem domains, familiarize yourself with them, learn them, understand them, and attempt to fix them with efficiency.
So while there are many specialized types of programming, we are all programmers, just writing our favorable language to speak with a machine, to solve a problem, in domain X.
I don't buy it, perhaps most of all because individual programmers in general aren't as specialized as a botanist vs. a string theorist. The Dijkstra post yesterday remarked on computers representing a radical novelty, I don't think it's too far a stretch to say this applies to programmers as a profession as well.
>On a vertical axis, a programmer … could be writing compilers … On a horizontal axis, they could be experts on databases, or weeding performance out of a GPU, or building concurrent processing libraries, or making physics engines, or doing image processing, or generating 3D models, or writing printer drivers, or using coffeescript, HTML5 and AJAX to build web apps, or using nginx and PHP for writing the LAMP stack the web app is sitting on, or maybe they write networking libraries or do artificial intelligence research. They are all programmers.
"They" could very well mean a single person. What does one call oneself in that case? I don't really like "Full stack developer" but it's the best I can think of, besides "programmer" that is. Perhaps "generalist developer" but that sounds wrong too. I don't do all of those things mentioned but I know how I could learn to do all of them adequately enough to create business value, and the specific things I do actually do are pretty varied. One day I might be writing in C caring about every byte of memory, the next I'm writing in Python and creating and destroying thousands of new objects willy nilly, wasting many megabytes of memory, and not tweaking the GC because the problem doesn't call for those optimizations. Maybe for an hour that evening I'm back in C again but writing a one-off prototype on an embedded system and so I don't bother freeing any of my mallocs or don't bother practicing any decent coding practices that aren't habitual since I know the code will be thrown away after its purpose is served. And the next morning maybe I'm firing up a hundred Amazon instances running NodeJS servers doing stuff with gigabytes of data.
I am a programmer. I program things. What, specifically, changes from day to day, sometimes from minute to minute. Trying to pigeonhole me into a specialty like other fields just doesn't work; programming is my specialty. If I'm at a corporation and the bean counters want to call me "Product X Maintainer" for a job title just so they can associate it with a salary, fine, whatever. My business card still says "Programmer" on it. When people actually want to know what I do, I'd be happy to go into more detail, but it quickly gets verbose and tedious and not very exciting to most people.
>On a vertical axis, a programmer … could be writing compilers … On a horizontal axis, they could be experts on databases, or weeding performance out of a GPU, or building concurrent processing libraries, or making physics engines, or doing image processing, or generating 3D models, or writing printer drivers, or using coffeescript, HTML5 and AJAX to build web apps, or using nginx and PHP for writing the LAMP stack the web app is sitting on, or maybe they write networking libraries or do artificial intelligence research. They are all programmers.
"They" could very well mean a single person. What does one call oneself in that case? I don't really like "Full stack developer" but it's the best I can think of, besides "programmer" that is. Perhaps "generalist developer" but that sounds wrong too. I don't do all of those things mentioned but I know how I could learn to do all of them adequately enough to create business value, and the specific things I do actually do are pretty varied. One day I might be writing in C caring about every byte of memory, the next I'm writing in Python and creating and destroying thousands of new objects willy nilly, wasting many megabytes of memory, and not tweaking the GC because the problem doesn't call for those optimizations. Maybe for an hour that evening I'm back in C again but writing a one-off prototype on an embedded system and so I don't bother freeing any of my mallocs or don't bother practicing any decent coding practices that aren't habitual since I know the code will be thrown away after its purpose is served. And the next morning maybe I'm firing up a hundred Amazon instances running NodeJS servers doing stuff with gigabytes of data.
I am a programmer. I program things. What, specifically, changes from day to day, sometimes from minute to minute. Trying to pigeonhole me into a specialty like other fields just doesn't work; programming is my specialty. If I'm at a corporation and the bean counters want to call me "Product X Maintainer" for a job title just so they can associate it with a salary, fine, whatever. My business card still says "Programmer" on it. When people actually want to know what I do, I'd be happy to go into more detail, but it quickly gets verbose and tedious and not very exciting to most people.
> These jobs are both extremely difficult for completely
> different reasons, and neither person can do the other
> persons job. What is good practice for one is an
> abhorration for the other. We are both programmers.
Stating that "programmer" is too broad a term means drawing an utterly arbitrary line. Because for the all the same reasons and at some level, "AI researcher" is too broad. So is "graphics programmer". So is "HLSL shader coder". Etc.
I don't think he's saying "programmer" isn't accurate; he's saying "programmer" isn't precise enough - and hence, isn't useful in most of the contexts we use it.
As he alludes to, "scientist" is a perfectly sensible word, with a meaning that most people would agree on, but at the same time the divisions within it - from botanist to nuclear physicist - are also very clear. We all understand that those are two very different roles with a fairly small intersection of skill and knowledge.
He argues that the same should be true for programmers, but that we don't acknowledge that.
As he alludes to, "scientist" is a perfectly sensible word, with a meaning that most people would agree on, but at the same time the divisions within it - from botanist to nuclear physicist - are also very clear. We all understand that those are two very different roles with a fairly small intersection of skill and knowledge.
He argues that the same should be true for programmers, but that we don't acknowledge that.
Except that this is comparing apples to carrots.
Scientist includes "computer scientist". At a certain level of competency "programmer" is comparable to "electrical engineer", and while "electrical engineer" does not defined which project you are working on at the moment, it does not need to, and neither does programmer when you are talking about "engineer class" programmers (lot of people are "engineer class" programmers without an engineering degree, but because they learned by themselves; this is fine).
The problem with "programmer" is not the field. It is the level of competency. Only entry/medium level programmers with few theoretical knowledge or only few to medium work experience are unable to work in every areas. That's why you need to precise for them what they are able to do, and implicitly that they are not able to do other things, or that learning how to do those other things would take lot of time. "Engineer class" programmers are generalist programmers, and that is comparable with electrical and other kind of engineers.
Scientist includes "computer scientist". At a certain level of competency "programmer" is comparable to "electrical engineer", and while "electrical engineer" does not defined which project you are working on at the moment, it does not need to, and neither does programmer when you are talking about "engineer class" programmers (lot of people are "engineer class" programmers without an engineering degree, but because they learned by themselves; this is fine).
The problem with "programmer" is not the field. It is the level of competency. Only entry/medium level programmers with few theoretical knowledge or only few to medium work experience are unable to work in every areas. That's why you need to precise for them what they are able to do, and implicitly that they are not able to do other things, or that learning how to do those other things would take lot of time. "Engineer class" programmers are generalist programmers, and that is comparable with electrical and other kind of engineers.
So is "Doctor", "Lawyer", "Mechanic", "Teacher"....
"Programmer" is the term we use to explain to non-technical people what we do. If they respond by letting you know they're a programmer as well, you can go into details about what languages and stacks you deal with. For everyone else: family, co-workers, bosses, etc., they don't care--they have some general idea of you working on a computer and that's sufficient.
Reminds me of a crazy blog post from someone who thought he was explaining the difference between "The Programmer vs The Developer". He was delusional to think that there is some kind of standardization there.
Also, a title does not prove your knowledge or competence. If you're judging people solely on their title and not by the conversation, then you need to reevaluate your classification techniques.
Reminds me of a crazy blog post from someone who thought he was explaining the difference between "The Programmer vs The Developer". He was delusional to think that there is some kind of standardization there.
Also, a title does not prove your knowledge or competence. If you're judging people solely on their title and not by the conversation, then you need to reevaluate your classification techniques.
"Programmer is overgeneralization" is overgeneralization.
It depends on context. Some advices apply to programming in general, some are only true for some fields.
Also - in science there's much talking recently about too strict specialization, and people from different fields not speaking between themselves, not sharing their tools. I guess it's good that in programming we don't have that problem yet. And if it comes with flamewars, so be it.
It depends on context. Some advices apply to programming in general, some are only true for some fields.
Also - in science there's much talking recently about too strict specialization, and people from different fields not speaking between themselves, not sharing their tools. I guess it's good that in programming we don't have that problem yet. And if it comes with flamewars, so be it.
Agreed. The world works fine with all sorts of categories, some overlapping, some with varying degrees of specificity. I see nothing special about the 'programmer' category.
Anyone interested in how categories and language relate to cognition should check out George Lakoff's "Women, Fire, and Dangerous Things".
Anyone interested in how categories and language relate to cognition should check out George Lakoff's "Women, Fire, and Dangerous Things".
So what?
It's like geek, artist, human, Minnesotan or whatever. It isn't a term meant to be precise. In fact you can also program a channel on the radio or on TV.
I don't think it's true that most people will consider themselves programmers, because they learned programming. Everybody learns science, writing or mathematics still only a small fraction of the people call themselves scientists, writers, mathematicians. In the last two cases it is something everyone does every day and be it just to calculate how many minutes you have to wait for the bus.
Also system administrators also use programming skills, still they are not programmers or consider themselves as something like that. Same is true for web designers.
I think it's a bad idea to say someone is a foo programmer, foo being something like "web application".
The author seems somehow mixes up programming, algorithm design and computer science.
Last but not least I don't think studying computer science makes someone a computer scientists, just like you don't become an artist studying arts or a philosopher studying philosophy.
I never heard of anyone having a serious problem with the term. There are occasionally discussions about programming and scripting, but that's usually to boast in one way or the other.
A more serious question usually is how much you need to know to call yourself a programmer, be it in general or be it something like <insert language here> programmer. It's rather funny to see that you can more quickly become a guy "knowing" assembly, javascript or C than for example Perl, Python or Ruby with Perl being interesting for you can easily get into basics, but most likely learn everything in your whole lifetime. Another example is whether you can call someone knowing just Rails or just LÖVE a Ruby or Lua programmer, no matter how much that person is able to achieve using such frameworks.
But for all these things one can usually just talk to people. It doesn't seem like a good idea to limit someone to a small number of terms, no matter how board or specific they are.
It's like geek, artist, human, Minnesotan or whatever. It isn't a term meant to be precise. In fact you can also program a channel on the radio or on TV.
I don't think it's true that most people will consider themselves programmers, because they learned programming. Everybody learns science, writing or mathematics still only a small fraction of the people call themselves scientists, writers, mathematicians. In the last two cases it is something everyone does every day and be it just to calculate how many minutes you have to wait for the bus.
Also system administrators also use programming skills, still they are not programmers or consider themselves as something like that. Same is true for web designers.
I think it's a bad idea to say someone is a foo programmer, foo being something like "web application".
The author seems somehow mixes up programming, algorithm design and computer science.
Last but not least I don't think studying computer science makes someone a computer scientists, just like you don't become an artist studying arts or a philosopher studying philosophy.
I never heard of anyone having a serious problem with the term. There are occasionally discussions about programming and scripting, but that's usually to boast in one way or the other.
A more serious question usually is how much you need to know to call yourself a programmer, be it in general or be it something like <insert language here> programmer. It's rather funny to see that you can more quickly become a guy "knowing" assembly, javascript or C than for example Perl, Python or Ruby with Perl being interesting for you can easily get into basics, but most likely learn everything in your whole lifetime. Another example is whether you can call someone knowing just Rails or just LÖVE a Ruby or Lua programmer, no matter how much that person is able to achieve using such frameworks.
But for all these things one can usually just talk to people. It doesn't seem like a good idea to limit someone to a small number of terms, no matter how board or specific they are.
Saying you're a programmer is like saying you're a writer. It's not an overgeneralization. It's a broad field. There are technical writers, business writers, novelists, journalists, poets and hacks. Some write soaring prose, others mundane workaday text. They write in different languages. They right for different audiences and cultures. There are amateur writers and professional writers. Those who write for love. Or the love of words. Those who write for money. They're all writers.
To me, programming is a lot like writing of other forms. And in more ways than this. So it is an apt comparison.
PS this reminds me of advice I was given leaving school.
"So what makes a true writer?"
"Well, writers write. Plenty of people say they're writers, or want to be writers, or criticize other people's writing and say they could do better. But the thing that sets a true writer apart is that they actually write, rather than talk about writing."
Plenty of people talk about being programmers, or say they know how to program, or critique others' programming and efforts. But the mark of a true programmer is easy to find.
Programmers program.
"So what makes a true writer?"
"Well, writers write. Plenty of people say they're writers, or want to be writers, or criticize other people's writing and say they could do better. But the thing that sets a true writer apart is that they actually write, rather than talk about writing."
Plenty of people talk about being programmers, or say they know how to program, or critique others' programming and efforts. But the mark of a true programmer is easy to find.
Programmers program.
On the other hand, I am a generalist programmer with an engineering degree that right at the moment is working on different project in various fields and in each of this project on various layers of technology => the result is that i'm touching at the same time electronic (yeah this even goes beyond programming), low level (drivers, telecom stack), medium level (application infrastructure), databases, user interface, sysadmin, and so over.
Saying that "programmer" means nothing is not completely false, but not completely true either. The application domain matters, but just as in other professions; you can't pretend that "electronic engineer" means nothing, you can't prented that "neutronic engineer" means nothing, even if you don't know if the first one is currently designing electronic boards for missiles or set-top-box, and if the second one is currently designing nuclear weapons or civilian reactor, or doing some radioprotection work.
In that sense saying "programmer" means nothing because there are lot of different programmers with various background and levels is an implicit depreciation of professional highly competent programmers capable of working on anything related to computer programming (and even in a lot of cases, beyond computer programming).
Having learned mathematics at school does not makes me a mathematician, even when I am using that math knowledge in a project, and not more than commentating about a book with friend makes me a literary critic. Doing dilettante or a little of entry level programming does not makes somebody a "programmer" either.
Saying that "programmer" means nothing is not completely false, but not completely true either. The application domain matters, but just as in other professions; you can't pretend that "electronic engineer" means nothing, you can't prented that "neutronic engineer" means nothing, even if you don't know if the first one is currently designing electronic boards for missiles or set-top-box, and if the second one is currently designing nuclear weapons or civilian reactor, or doing some radioprotection work.
In that sense saying "programmer" means nothing because there are lot of different programmers with various background and levels is an implicit depreciation of professional highly competent programmers capable of working on anything related to computer programming (and even in a lot of cases, beyond computer programming).
Having learned mathematics at school does not makes me a mathematician, even when I am using that math knowledge in a project, and not more than commentating about a book with friend makes me a literary critic. Doing dilettante or a little of entry level programming does not makes somebody a "programmer" either.
The only way not to overgeneralize is to say "I'm an Andy" or "I'm a Kate" or "I'm a Jerry".
Everyone is quite unique. The purpose of titles is to generalize a bit ;)
There is "generalizing", and then there is "over-generalizing". The problem pointed out by the author of the article is that we're often doing the latter instead of the former. Something that is a good practice for a "compiler writer" or a "web developer" (both generalizations) is ofter presented as good "programming practice" over-generalization.
This is true of every field. There are vast differences in training, ability, and focus between practitioners, but you're not aware of them because you don't know enough about most fields to be able to tell the difference.
Yes, "programmer" is very general. So is "doctor", "lawyer", "engineer", "teacher", etc, etc.
Yes, "programmer" is very general. So is "doctor", "lawyer", "engineer", "teacher", etc, etc.
Interesting, this article touches on an internal dispute that has been going on for quite some time within our industry: the fact that software engineering as a profession is rather "loosy-goosey", that is, the lack of any formal accreditation standards that are common in other engineering professions.
Granted, our industry is still very young compared to other engineering professions, so of course we still have kinks to work out. In my opinion, I believe it will benefit our industry in the long run if we can all agree on a base set of knowledge & skills that all self-proclaiming software engineers should have, no matter their specialization.
Because right now, for having an "engineer" slapped at the end of our job title, the only form of standardization we have is a college degree.
Granted, our industry is still very young compared to other engineering professions, so of course we still have kinks to work out. In my opinion, I believe it will benefit our industry in the long run if we can all agree on a base set of knowledge & skills that all self-proclaiming software engineers should have, no matter their specialization.
Because right now, for having an "engineer" slapped at the end of our job title, the only form of standardization we have is a college degree.
I think it's still somewhat useful because the skills that make someone a good X programmer, typically make them a good Y programmer as well. The specific knowledge doesn't translate, but the skill does. I was talking with a friend who does very specific DSP work that requires significant amount of esoteric knowledge, and he said, "With a relatively small amount of training, any good programmer can become a good DSP programmer, and any bad programmer can become a bad DSP programmer."
He went on to clarify that he had worked with people from systems-programming backgrounds, all the way up to programmers who had worked chiefly in VB and this seemed to hold no matter what.
He went on to clarify that he had worked with people from systems-programming backgrounds, all the way up to programmers who had worked chiefly in VB and this seemed to hold no matter what.
[deleted]
[deleted]
[deleted]
[deleted]
As anyone who has finished Philosophy 101 should be able to tell you: definitions aren't important, what you do with the definitions is what matters. The definition of programmer you use when hiring someone to build a web app is going to be rather more specific than what you use when you are hanging out on IRC.
Also, if you are concerned that "programmer" covers both rockstars tinkering with JavaScript and Donald Knuth levels of cleverness, there's a simple solution. Prefix the word programmer with an adjective. I would recommend "competent" and "experienced" (and their antonyms) as good adjectives to start with.
Also, if you are concerned that "programmer" covers both rockstars tinkering with JavaScript and Donald Knuth levels of cleverness, there's a simple solution. Prefix the word programmer with an adjective. I would recommend "competent" and "experienced" (and their antonyms) as good adjectives to start with.
Excellent article, articulate, well written, I completely agree with the content. I see this every time I interview for a new contract or FT position. Now I focus on Java, JEE (or J2EE) or lighter stacks like Tomcat + Spring or GWT. I do the data tier including SQL as well. That's all I have time for. Sometimes I get out to the front, JSP, JSF, GWT, basic JSP + jQuery for AJAX but that's it. Sometimes I do rich client apps using SWT, some AWT and rarely Swing. Then too I write Java console apps for system level work on occasion.
I need a vacation.
I need a vacation.
Hackers love complexity. Others just don't.
Understanding differences between two (especially "difficult") things means at least having a vague idea of what each is about.
And regardless how you find that interesting, almost any non geek/curious/techie will not give anything about both "what (general-purpose) programming is" and "what whatever-complicated-thing-you-do is instead". Unless they have any specific reason to put some effort in it.
Very nice article. To be a "systems programmer" or a "rails web programmer" are two very different things. One is not "better" than the other, only different with different skill sets and knowledge while still sharing some general concepts (looping, variables, etc).
The difference is that it's not uncommon for the same person to be good at both systems programming and rails development, while the elusive quantum physicist-marine biologist is far more rare.
Would these guys count as crossing the quantum physicist - marine biologist divide?
http://www.sciencedaily.com/releases/2010/02/100203131356.ht...
I wouldn't be surprised if there are more people looking at the effects and applications of quantum mechanics in biology than there are people who split their time between systems programming and rails development.
http://www.sciencedaily.com/releases/2010/02/100203131356.ht...
I wouldn't be surprised if there are more people looking at the effects and applications of quantum mechanics in biology than there are people who split their time between systems programming and rails development.
I've not found this to be the case.
SHRDLU stopped with blocks; it'd be interesting to see how other AI projects deal with similar generic / specific terms that the OP mentions.
(http://en.wikipedia.org/wiki/SHRDLU)
(http://en.wikipedia.org/wiki/SHRDLU)
True. It's kind of like saying you're a builder - it could be building anything from building construction to engineering aircraft.
Do you know why we have pointless language wars, and meaningless arguments about what is good in practice?
As a veteran language warrior, I resent the claim that my efforts are "pointless". There's a lot of terrible software out there, and one of the reasons for this is that inappropriate choices were made on the outset.
Now, I'll be the first to say that there isn't "one language to rule them all". I recently got into a debate over C++ (which I dislike) where I learned that there are people making judicious use of this language, which is still inappropriate for 90% of the purposes to which it is put, but seems to suit some needs perfectly in a way that neither a high level language nor C can.
Software engineering is a generalist discipline: how to solve problems and add value to organizations using software. It applies whether you're writing performance-critical weather simulations or web apps. It has rules (such as "prefer immutable data and referentially transparent functions") which you must know to be a decent software engineer but that you will end up breaking 1 to 10 percent of the time, because to break said rule (e.g. using mutable state) will be the most tasteful decision.
I think skill as a software engineer is pretty easy to measure-- increasing scopes of contribution, reliable competence on harder architectural problems. Domain-specific programming skills are much harder to measures, and skill of that variety is n-dimensional without question.
Software engineering, I'd argue, is the liberal arts of programming. You need to know about algorithms, but not necessarily become an expert. Same with AI, programming languages, operating systems and databases. You study all these things to learn how to learn, so that if you find yourself, some years later, needing to tune a NoSQL database, you know how to find the knowledge, autonomously if necessary, and apply it.
As a veteran language warrior, I resent the claim that my efforts are "pointless". There's a lot of terrible software out there, and one of the reasons for this is that inappropriate choices were made on the outset.
Now, I'll be the first to say that there isn't "one language to rule them all". I recently got into a debate over C++ (which I dislike) where I learned that there are people making judicious use of this language, which is still inappropriate for 90% of the purposes to which it is put, but seems to suit some needs perfectly in a way that neither a high level language nor C can.
Software engineering is a generalist discipline: how to solve problems and add value to organizations using software. It applies whether you're writing performance-critical weather simulations or web apps. It has rules (such as "prefer immutable data and referentially transparent functions") which you must know to be a decent software engineer but that you will end up breaking 1 to 10 percent of the time, because to break said rule (e.g. using mutable state) will be the most tasteful decision.
I think skill as a software engineer is pretty easy to measure-- increasing scopes of contribution, reliable competence on harder architectural problems. Domain-specific programming skills are much harder to measures, and skill of that variety is n-dimensional without question.
Software engineering, I'd argue, is the liberal arts of programming. You need to know about algorithms, but not necessarily become an expert. Same with AI, programming languages, operating systems and databases. You study all these things to learn how to learn, so that if you find yourself, some years later, needing to tune a NoSQL database, you know how to find the knowledge, autonomously if necessary, and apply it.
Software engineering is a generalist discipline: how to solve problems and add value to organizations using software. It applies whether you're writing performance-critical weather simulations or web apps.
I agree absolutely. I've done jobs in scientific computing (whoops! knew nothing about interfacing with hardware, had to learn) networking (whoops! knew nothing about SNMP, had to learn) and stock trading (wtf is an intermarket sweep order? time to learn again.) There's a role for specialists, and I like the fact that I become more valuable and more independent as my domain knowledge increases, but even more I like that my skills transfer from one vastly different domain to another.
Someday maybe programming will be specialized. Like medicine: there's no way we would let a chimpanzee doctor operate on a human or even prescribe drugs to one. Right now there are natural areas of specialization, but specialization just isn't what it's cracked up to be. Anyone who has dealt with hired guns in software knows that specialists can't compete with smart generalists who are close to a problem. It's as if botanists performing surgery on close friends and family members always achieved better medical results than surgeons operating on people they didn't know. What's the use of specialization in a field like that?
I agree absolutely. I've done jobs in scientific computing (whoops! knew nothing about interfacing with hardware, had to learn) networking (whoops! knew nothing about SNMP, had to learn) and stock trading (wtf is an intermarket sweep order? time to learn again.) There's a role for specialists, and I like the fact that I become more valuable and more independent as my domain knowledge increases, but even more I like that my skills transfer from one vastly different domain to another.
Someday maybe programming will be specialized. Like medicine: there's no way we would let a chimpanzee doctor operate on a human or even prescribe drugs to one. Right now there are natural areas of specialization, but specialization just isn't what it's cracked up to be. Anyone who has dealt with hired guns in software knows that specialists can't compete with smart generalists who are close to a problem. It's as if botanists performing surgery on close friends and family members always achieved better medical results than surgeons operating on people they didn't know. What's the use of specialization in a field like that?
> I recently got into a debate over C++ (which I dislike) where I learned that there are people making judicious use of this language, which is still inappropriate for 90% of the purposes to which it is put, but seems to suit some needs perfectly in a way that neither a high level language nor C can.
You just learned that?
You just learned that?
n-dimensional without question huh?
Boy did you miss the point of that article.
Although I do know of a great position which might interest you, it's called a 'software architect', just let me take you round the back here, ignore the guys with guns...
Boy did you miss the point of that article.
Although I do know of a great position which might interest you, it's called a 'software architect', just let me take you round the back here, ignore the guys with guns...
[deleted]
This makes a nice follow-up to the article I wrote last week: http://news.ycombinator.com/item?id=3528940
EDIT: Reading the comments here (and over there) reaffirms the correctness of my decision not to get into definitions about "what is a programmer" with technical folks! Lots of great ideas, very little organization.
The funny thing is, it's possible to do a post about what really makes a programmer -- but nobody would read it. People would happily read articles about the importance of programming, the importance of programmers, etc, Emotional, take-a-stand articles are fun to read and comment on, even (or especially) if the definition of the thing discussed is so vague!
I'm not sure if that is a bug of human nature or a feature.
EDIT: Reading the comments here (and over there) reaffirms the correctness of my decision not to get into definitions about "what is a programmer" with technical folks! Lots of great ideas, very little organization.
The funny thing is, it's possible to do a post about what really makes a programmer -- but nobody would read it. People would happily read articles about the importance of programming, the importance of programmers, etc, Emotional, take-a-stand articles are fun to read and comment on, even (or especially) if the definition of the thing discussed is so vague!
I'm not sure if that is a bug of human nature or a feature.
This is going to sound flip but I mean it in all seriousness: It is simply not worth worrying about this.
We use the term "programmer" as a simple way to classify. People are typically able to quickly determine whether an article/job/discussion is appropriate for their programming skills, so I don't see any particular problem with the continued use of the word.