Our Job Titles: Developer, Programmer or Software Engineer?
If I look at the desired length of blog posts across the sites of customers for whom I’d write, it’s around 1,000 words. Given the length of Monday’s wildly popular post, that means I’ve got about 500 words left for the week. So today’s will be relatively short and sweet, lest I deplete the world’s word reserves. This is a reader question about what I think the difference is between “programmer,” “software engineer” and “software developer.” (I won’t block quote because that was pretty much all there was to the question).
My take is simple: the difference is a Rorschach test of what the terms mean to you. If you google around a bit, you’ll find articles like this one, that’s pretty well written or this one, by Scott Hanselman, with an awesome Venn Diagram. But all such posts that I’ve seen and conversations that I’ve heard seem to make the a priori assumption that since there are different words, they must have distinct meanings. After all, we try to keep things DRY in this line of work; if they weren’t different things, why would there be different words? There are then quests to establish a taxonomy that seems to vary for everyone establishing it.
I was once responsible for creating a software department’s org chart, both in terms of titles and reporting responsibility. This meant that I had an utterly blank slate from which to choose. Anything was in play, and the folks working there could thus have become developers, programmers, software engineers, or code magicians at my whim. I made the base position title “software engineer,” and do you want to know why? I didn’t do a careful assessment of their exact roles and responsibilities and create a taxonomy. Instead, I researched which title commanded the highest average market pay in the area at the time, and gave them that advantage, hoping that it would bring them a little compound salary interest throughout their careers.
I ignored the notion of a perfect, descriptive taxonomy and gave them titles based on market considerations. I have no doubt that other organizations do similar things, motivated by economic concerns of some form or another. Perhaps some take the opposite tack as me, naming their folks the comparably less glorious sounding, “programmer” in the hopes that it will deter them from securing competitive offers. In any case, a decent argument could be made that the title distinctions are significant only inasmuch as they are predictive of different pay brackets. Chris Lema’s article seems to go into this, effectively stack ranking in order of “programmer, developer, software engineer,” which I’d wager, corresponds to the stack ranking of their market values. But this is necessarily fluid and somewhat tautological, like saying that Programmer I is less experienced and lower paid than Programmer IV.
I don’t have a particularly high opinion of job titles, and I’d say it’s their wild variance across organizations that make any meaningful taxonomy a Rorschach test. The difference among these titles is really in the eye of the beholder. But I will leave with a final point — I’m fine with “programmer” and “software developer,” but I’m not really a fan of “software engineer.” Perhaps this makes me a hypocrite, but my goal in handing out that title was to make people more marketable, not to pick the title that I liked best. And the reason I don’t like the title “software engineer” might actually surprise you a bit.
I don’t like “software engineer” for the same reason that I don’t like “architect” as a title. I’m also not really big on the set of titles that link software development to the Medieval guild model. The reason for all of this is the same. Writing software isn’t like civil or electrical engineering. Writing software isn’t like building construction. Writing software isn’t like blacksmithing or making soap in 12th century France. Writing software is really kind of unlike anything humanity has done before, and so I prefer titles like “software developer” and “programmer,” that don’t carry the baggage that comes along with their analogy-oriented counterparts.
My standards for what we call ourselves are thus pretty low. I’ll settle for “anything that doesn’t create confusion.” I’m personally partial to “technologist,” and “problem solver.”By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.