'Programmer' is an Overgeneralization
*"Beware of bugs in the above code; I have only proved it correct, not tried it."* - Donald Knuth
Earlier today, I came across a post during a google-fu session that claimed that no one should use the C++ standard library function make_heap, because almost nobody uses it correctly. I immediately started mentally ranting about how utterly ridiculous this claim is, because anyone whose gone to a basic algorithm class would know how to properly use make_heap. Then I started thinking about all the programmers who don’t know what a heap is, and furthermore probably don’t even need to know.
Then I realized that both of these groups are still called programmers.
When I was a wee little lad, I was given a lot of very bad advice on proper programming techniques. Over the years, I have observed that most of the advice wasn’t actually bad advice in-of-itself, but rather it was being given without context. The current startup wave has had an interesting effect of causing a lot of hackers to realize that “performance doesn’t matter” is a piece of advice riddled with caveats and subtle context, especially when dealing with complex architectures that can interact in unexpected ways. While this broken telephone effect arising from the lack of context is a widespread problem on its own, in reality it is simply a symptom of an even deeper problem.
The word programmer covers a stupendously large spectrum of abilities and skill levels. On a vertical axis, a programmer could barely know how to use vbscript, or they could be writing compilers for Intel and developing scientific computation software for aviation companies. 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.
This is insane.
Our world is being eaten by software. In the future, programming will be a basic course alongside reading and math. You’ll have four R’s - Reading, ‘Riting, ‘Rithematic, and Recursion. Saying that one is a programmer will become meaningless because 10% or more of the population will be a programmer on some level. Already the word “programmer” has so many possible meanings it’s like calling yourself a “scientist” instead of a physicist. Yet, what other choices do we have? The only current attempt at fixing this gave a paltry 3 options that are just incapable of conveying the differences between me and someone who graduated from college with a PhD in artificial intelligence. They do multidimensional mathematical analysis and evaluation using functional languages I will never understand without years of research. I’m supposed to write incredibly fast, clever C++ and HLSL assembly while juggling complex transformation matrices to draw pretty pictures on the screen. 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. Even within our own field, we are simply graphics programmers or AI programmers or [x] programmers.
Do you know why we have pointless language wars, and meaningless arguments about what is good in practice? Do you know why nobody ever comes to a consensus on these views except in certain circles where “practice” means the same thing to everyone? Because we are overgeneralizing ourselves. We view ourselves as a bunch of programmers who happen to specialize in certain things, and we are making the mistake of thinking that our viewpoint applies outside of our area of expertise. We are industrial engineers trying to tell chemists how to run their experiments. We are architects trying to tell English majors how to design an essay because we both use lots of paper.
This attitude is deeply ingrained in the core of computer science. The entire point of computer science is that a bunch of basic data structures can do everything you will ever need to do. It is a fallacy to try and extend this to programming in general, because it simply is not true. We are forgetting that these data structures only do everything we need to do in the magical perfect land of mathematics, and ignore all the different implementations that are built for different areas of programming, for completely different uses. Donald Knuth understood the difference between theory and implementation - we should strive to recognize the difference between theoretical and implementation-specific advice.
It is no longer enough to simply ask someone if they are a programmer. Saying a programmer writes programs is like saying a scientist does science. The difference is that botanists don’t design nuclear reactors.
Very well written. I especially like your comparisons with other fields.
I like this article its almost a summary of the entire of philosophy ;)
Great analysis!
This reminds me of the "programmer archaeologist" from Vernor Vinge's novel "A Deepness in the sky" -- great book, btw.
"The Programmer-Archaeologist searches for useful code in the archives of software on the Internet and modifies it for current needs."
(from http://www.hpcf.upr.edu/~humberto/programmer-archaeologist.html )
If I remember correctly the main character is working as a "battle programmer"; reprogramming battle systems in a conflict. More in line with your article, one could imagine a "master programmer", "scholar programmer" although that sounds very pretentious.
See also:
http://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture
Nice article. Just one thought. To follow the pattern, the four R's should have been - Reading, 'Riting, 'Rithematic, and 'Rogramming. But very good points.
If you think that's bad, my friends and family sometimes find it hard enough to understand the difference between programming and IT support.
"It's all computers, right?"
ಠ_ಠ
Ace. I get this too.
I once told a friend that I didn't want to work IT. They asked "Why are you studying computer science?". I said I'm going to be an engineer not a mechanic. That got a frown, hehe.
Haha,IT,now there is another broad term ,if calling yourself a programmer is like saying you are a scientist,then saying you are in IT is like saying you "do stuff".
http://en.wikipedia.org/wiki/Information_technology
Philosophy programmer OR Programming Philosopher
It's very common (and easy) to mix up computer science and programming. The two are related, certainly, but they are not the same thing. Programming is writing computer programs. The definition of a programmer is an individual who writes computer programs. No more, and no less.
Computer science is the theory of writing computer programs. And a background in CS can aid a programmer, but it is neither necessary nor required a successful or skillful computer programmer. Most programmers don't need to concern themselves with the details of all but the most basic algorithms and data types they use. They just need to know they exist and when they are appropriate. Actually implementing them themselves is usually re-inventing the wheel.
Now I have to write a rant about programmers refusing to re-invent the wheel even when they need a completely different wheel for their project :)
Holy crap I started writing an article about exactly that last night. People try so hard to avoid re-inventing the wheel that they will use monster truck wheels on a wagon and it drives me nuts. And since the wheel has been around for so long and must have been invented by someone really smart, people get it in their heads that creating your own wheel must be an epic project requiring a team of PhD's when really, creating your own "wheel" may not be that difficult. And guess what, you are allowed to use your existing knowledge of wheels to build your own version conforming to the wheel spec! So you are not re-inventing it from scratch, just re-implementing it with specializations.
I definitely see your point, but I'm not sure I agree with your conclusions. There is definitely a distinct difference between an applications programmer and a systems programmer, both in what they are creating and also in the amount of rigor required to get their work correct. But I think it's not a good idea to break these differences down along domain lines, or by technology. That is, an AI programmer is working with sophisticated algorithms that happen to relate back to the world in the context of artificial intelligence. The underlying thing is the sophistication of the data-structures/algorithms, but there are many other areas in programming where that type of knowledge is applicable. If we fracture on domain or technology distinctions then we tend to silo ourselves away from each other. What I think would be better in the long run is for us to split along our own internal natural boundaries. For instance, a programmer could specialize in modeling and persistent technologies. The issues in both these areas tend to run vertically, you get the same basic problems with Relational Databases, that you get with NoSQL ones. The latter are more complex and require deeper thought, but all the issues with both are related.
Paul.
Peter Denning wrote some great articles about the "profession of IT", you can find them here:
https://docs.google.com/open?id=0B47_wC01E6EQN2M3YTliNzQtMDUzMy00M2U2LWFiZDYtNmViOTdmNTdmYzNm
He felt that IT professionals should be licensed like Doctors, Lawyers and Electrical Engineers. He has some interesting thoughts on careers in IT overall. I think that everyone in the profession should read this series of articles.
This is kind of silly. You sound like a statistician arguing that because he's working for a pharmacological company and another statistician is doing modeling for an environmental bureau, it's 'insane' for them to both be considered to be in the same field.
It's a pretty big world, and programming, even if we take 'programming' to mean every kind of programming possible, is a very small part of it.
I really don't have time to write a proper rebuttal (since you know, programmers actually need to work), but in my line of work, one month I'm writing an embedded network stack for a legacy protocol, the next month I'm doing deferred rendering in our OpenGL engine, the next month I'm writing a Qt tool to allow live modification of assets in our engine, the next month I'm writing an observer/notification framework to handle state, the next month I'm doing a device driver etc. Really good programmers work on a diverse range of products / solutions, and using their vast experience hammer away at the problem at hand.
If as a programmer you work in a single domain, then you really don't have the experience needed to grow professionally.
PS - I work in a startup (games for custom built embedded systems), so I have to tackle a lot of unrelated domains in order to get stuff out.
I have done graphics, audio, tool, cross-platform GUI, database, server-side web, client-side web, networking, and many other things. I call myself a graphics programmer because that is the only field where I have actually invented new techniques, and hence it is by a large factor my area of specialty and expertise. I also run a startup, its called Black Sphere Studios, and it makes games too! Luckily for you, I'm focusing on traditional PC games, so I'm not a competitor... yet :)
Sadly most programmers still think that being pretty good at implementing an existing solution for something like networking makes them a network programmer, or because they can use XNA they're a graphics programmer. There is no end to the insane, misguided advice I get from people insisting that C# is just as fast as C++ and therefore I shouldn't be using C++, without actually knowing why I'm using C++ or the problems with the garbage collector in C# and other latency issues. They just assume what works for them works for everyone else, and judging by the reaction to this post, this is a majority viewpoint that is deeply ingrained and unlikely to go away, so I am not optimistic about receiving less stupid advice in the future.
Good luck with your startup!
I wrote about this a month or so ago : http://schmantics.blogspot.in/2011/12/reinventing-wheel-for-fun-and-profit.html
I happened to do this and write about it recently : http://schmantics.blogspot.in/2011/12/reinventing-wheel-for-fun-and-profit.html
This article (rant) is similar to my favorite rant on the profession. I tell people I'm a "programmer" or worse "software engineer" and the clever ones who think they know something immediately ask me "What language do you use?" Since they will never have heard of several of the languages I'm familiar with (Jovial J/73 anyone?) or understand the differences between PHP and Prolog, what useful answer can I give them? These days I usually just sigh, or smile, depending on my mood, and tell them I know more than 20, and use the one that makes the most sense.
Of course, that answer completely belies the fact that programming language choice is most often a matter of religious dogma, not a selection process. The same is true of my current day job, where after serious consideration we concluded that the only platform that makes sense to create v2.0 of our current Linux/C++ application server is... Wait for it... Linux and C++! Please allow me to point out that this a database-driven micropayment platform (primarily) that remains a PERFECT candidate for being implemented as Java EE Servlets. But never mind, we're going to re-implement it in C++ so we can load/unload code modules (built into JEE) because the C++ version "will be faster" and "the garbage collector would kill us."
And I am NOT a Java fanboy. I'm a working programmer who's done everything from embedded work in C, C++, and assemblers even YOU educated readers have never heard of, to BSD kernel work, to lots and lots and lots of application code in Fortran, C, C++, Perl, and PHP. Oh, and a little bit in Java. The Java code was some of the best I've ever written, or managed (because Tim actually wrote most of it.)
Never ever ever confuse "programmers"
Great post.
I'm slowly realizing this problem as I'm pursuing my PhD. The amount of math my friends need to know for their machine learning research projects is absolutely insane, yet even they will describe their work as "just coding".
Arizona State University president Michael Crow said this about 2006-2007, and began to redesign the curriculum around it. 'Computer Science' was made part of every course.
Naturally, that was too forward-looking, and it didn't go through. Then someone accidentally the economy.
One day.
Programmer, developer, software engineer, code monkey, all apply at various times, sometimes in the same day.
I do wonder what insights a botanist could bring to nuclear reactor design... energy management, environmental awareness...
Being an APL developer, the scope of my work has spanned what a soccer team of programmers would be doing. No single definition suffices any more, that is for sure.
I think you could basically say the opposite thing and make an equally compelling argument. Back when I started programming, most programmers really were doing the same things as everyone else, because we were limited in what we could do. You either programmed in assembly language, or you suffered with BASIC, or you spent a lot of money on a Mini or Mainframe so you could do Fortran - wooo hooo! Back then, we were making programs out of raw(er) materials, and today we are making applications by putting together pre-packaged widgets. So, you could make the point that today, almost nobody is a programmer - we are assemblers of parts. We used to be farmers, now we are chefs.
I agree with you wholeheartedly. The CIO at a large computer company that contains the letters H and P made an internal statement at the end of 2010 that the employees are 'fungible resources' and should be able and ready to move from one project/team to another as needed for the good of the company. This seems like a good idea when you consider that everyone writing code was labeled as a programmer/Engineer I,II,III,IV,V or whatever. This may make sense when labeling for payscales in HR, but when there is a person with 10+ years of web coding experience being asked to use C after those many years, that fungibility tends to not apply.
The big question is how do we define the different 'practices' or 'specialties', and if we do that, how do we handle those who work for a smaller company where they actually DO get to work with many different technologies?
Read another related blog, there division was between computer scientist (good title), programmer and developer. Separation between developer and programmer sort of seemed arbitrary though. I see the last class as "not that much about creating awesome things but composing applications using awesome stuff created by others". Code composer?
I had a teacher on grads that made a comparison with medicine specilaties. It was around 8 years ago. He talked about the programming evolution in general, everything becoming faster and easier, and then told us that like medicine, computer science might be divided into specific areas and specialties [Medice e.g.: neurology, cardiology, paediatrics, ophthalmology, etc]. And I think this is happening.
It needs to happen FASTER >C
What it boils down to is "horses for courses". We all have to deliver what the client wants so we choose the most appropriate language(s) and methodology and just get on with it.
I guess that even when any disciplinary definition is arbitrary, most of the existing fields of knowledge-practise can make the same claim you make just to feel special... physics has many -almost independent- domains; medicin, and so on. HTML, AJAX or C++, you usually saying a computer what to do. It's the same kind of generality for a physic, a medical doctor, etc.
I like your argument but no matter what kind of programmer one is some things will always apply across the whole industry,eg well commented code,clear syntax,standards compliant code etc etc infact the more complex the code the more one needs to adhere to acceptable standards and style to avoid those who will inherit that code banging their heads on their keyboards trying to maintain that code
Still wrong. Games often have situation specific code that will be written, tested, and then never looked at again by another soul, because the game will be released and the code archived. Being standards complaint in that case isn't really helpful, because the code will very rarely need to be maintained for more than a few months, and almost always by the same programmers. It's more important to finish the game.
Once again, programmers keep insisting that [x] applies to all programmers, and forgetting the age old adage "never say never". Or in this case, never say always. Ever.