The other day I saw a tweet that said something like, “to a designer, HTML is programming and to a programmer, HTML is design.” That cracked me up. If you don't recall, I call this dynamic the invasion of the lightweights.
That's not a negative thing. In fact, I find it useful and valuable to the overall market. The nature of the dynamic is that as technology gets easier and easier, more and more people will be able to “program.”
Programmer, Developer, Engineer?
Now before I get into this topic of a name, and what's in a name, I want you to read the next lines very carefully.
I don't care what you call yourself. There's nothing special in a name.
I don't care about your education either. I use these conceptual levels to help people positively with their career development. Not to be a jerk.
Ok, with that said, today on our WPwatercooler show, and last week in tweet discussion, the topic of programmers, developers and engineers has come up. And some people have looked on curiously, I'm sure—wondering what's in a name?
So, what's in a name?
With all the caveats out the way, let me walk you thru my definition. Again, these are meant to help people in career development—to help them step into a new role, not to push people out of an existing role (or tell them they're not worthy). See, caveat again.
Programmer
When I talk about a programmer, I mean someone who can code. They know at least one programming language and know it well enough that they can make things happen by typing the code into their computer.
Some programmers graduate from a university with a computer science degree and know how to code. They would qualify. Others pick up a book and teach themselves to code on their own. They would qualify too.
Developer
When I talk about a developer, I use the term to mean something more than programmer. A programmer asks me, “what should I code?” or “how do you want me to do it?” In those cases, I'm making the bigger decisions and the programmer is implementing things.
Developers have enough experience to have seen problems before and to know what worked and what didn't. With developers I normally describe a destination, and they design the route they'll take. I give them more freedom because they have deeper experience.
So for me, the difference between a programmer and a developer is one of degree. One is more resourceful than the other. Moving from one to the other requires time, effort, and experience.
Programmers can accelerate this by doing more in shorter amounts of time, but they won't get there by doing the same thing 20 times over. Additionally, I make no assumption about how they develop their experience (college or on the job), nor do I make any about the number of languages they know. One is fine.
Software Engineer
Software engineers are a different dynamic altogether, for me. It's because of the “engineering” part of the term, for me.
To remind you, I don't care how software engineers gain their knowledge. I'm not suggesting they must have a degree. But I am suggesting that they can't just pick up a language, hack their way around a bit and expect me to call them a software engineer—regardless of what they call themselves.
Engineering is a discipline. It requires that you know a set of knowledge. I would say education but people will punt to schooling, and I'm not saying that. I am saying you can't just learn a language. There's a history to the discipline.
Engineering requires a level of abstract thinking. I'm not just talking about creating a plan before you write code. I'm talking about creating mental models of how the parts of a system will work. Models that help you refine your designs.
Engineering requires an ability to communicate with others. I don't care if it's in user stories or diagrams, engineers need to be able to communicate with other engineers to design solutions and to debate the merits of different approaches—often calling for complex depictions of abstract dynamics.
Can you be a self-taught software engineer? Yes. I think you can. But it's not fast or easy.
Software engineers may focus on a single discipline (like design, testing, or performance tuning) or more, but those disciplines often are apart from programming languages. That translates to being able to move a software engineer from one platform to another and see them pick it up in no time.
A conversation I had the other day
I was in an advisory meeting the other day when the director of engineering told me they were trying to find a Ruby developer and it was not only really hard, but also really expensive.
He'd been to networking events and these Ruby developers were coming up to him and highlighting how awesome they were in Ruby, and how much they were worth.
My recommendation was to look elsewhere. My words were something like, “if you find a software engineer, you'll be happy regardless of what language they've been programing in the last couple years.”
Different projects and teams need different staff
Is there a good reason to categorize people? I find that they're very few. But when it comes to recruiting and when it comes to career development, I find these categories / labels helpful.
But is there a right answer? Or a wrong answer?
I don't think so. It really depends on your business model, the kinds of projects you do, and more. So don't use this article to give your next employee review and cut their pay because they're only a programmer or developer.
But at the same time, if you hire a software engineer, and they're stepping into a new platform, give them a break. They may not know the “inside-speak” and they may make a mistake like not capitalizing a P. If they build you the next GravityForms, I guarantee you, you won't care.
So, what's your take?