"Programmer" is an Overgeneralization

  > 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.

This applies to pretty much any job description in the world. You're always generalizing at some level; that's a fairly straightforward necessity. Depending on the requirements, you adjust your description. No two accountants do the exact same thing; doesn't mean they're not accountants. Neither does the fact that everybody's doing some accounting make them anything other than accountants.

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 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.

I disagree.

my point is, that after 15+ years of software development in various languages and environments I could take on any programming task in any language (even having to learn it). the task could require either specific domain knowledge that I already posess or that I have to learn to the extent that allows me to do the job.

if I get interested in AI and spend 3 years experimenting with it, I'm still a programmer... and an AI pro.

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.