There is a clear behavioral difference between software developers and software engineers, though the terms are often, incorrectly interchanged. Through my own experience and observations, I hope to not only shed some light on the difference, but encourage developers (my target reader) to strive to become engineers. If you find this post helpful, feel free to tweet at me: @mrjoelkemp
Note: I establish a few differences between the terms engineer and developer; however, I use programmer as a generic term to refer to both.
The bottom line
Engineers keep asking why, how, and under which constraints a system/library/snippet works. The other, perhaps more important part, of this is having enough confidence in your abilities as a problem solver and learner to dig into the source code of said system/library/snippet.
Too many developers are content with just tinkering with an api, adding that api/library to their resume, and moving on to the next thing – where they achieve only a shallow knowledge of that new tech as well. The industry definitely has a need for programmers like this; developers code simple features, they don’t build complex systems.
Here are a few reasons why, as a developer, you should start tweaking your behavior and asking ‘why?’
There’s a heavy supply of developers
Programming has definitely been commoditized. All of these online and offline education programs are really only setting you up to become a developer – to not really understand what you’re doing, but have enough knowledge to produce something that works. Every day/week/month, these learn-to-code services churn out dozens of developers – like you, but with a few months/years less experience.
Becoming more skilled (more invaluable) gives you a leg up over all of these newcomers. Ever heard that there’s a supply shortage of skilled programming labor? They’re really talking about engineers.
You’ll make less money as a developer
As with the previous point, an increased supply of developers lowers the price (salary) at which companies are willing to pay for your talents. In today’s market, a new developer will make anywhere from 40k to 80k at best. Engineers make in the six figures.
Let’s say you’re making more than 40k to 80k at the moment. Ask yourself: do the problems that you solve (i.e., features you build) require your services? Or are the tasks so easy that some neo-coder could just sloppily put something functional together at half of your salary?
You’ll look really bad when something breaks
You pushed for using the new hottness to build your current feature; you also already have it on your resume. But, again, you only have a shallow knowledge of that tool/api. When that piece of code breaks down in production, would you feel comfortable fixing it? Or would you just shrug your shoulders and say “I don’t know what’s going on”?
I’ve seen it the shrugging happen and it’s the tell-tale sign of a developer. From experience, those shruggers don’t make the cut in very small software teams (like early-stage internet startups).
Don’t get me wrong, modern day software development is based on abstractions. It’s impractical for a programmer to understand absolutely every piece of code that they write, down to the machine code that’s generated. That’s not what I’m saying. You should at least understand some of the implementation details of the tools that you immediately work with.
A personal story
Backbone.js was scary. I could set up a large pub/sub based architecture consisting of views/models/collections, but I had a shallow understanding of the api. I had no real idea what was going on beyond the documentation and my observations poking-and-prodding the black box that was the library.
It was a daunting task to read through source code that wasn’t mine. The Backbone authors styled their code differently, didn’t comment much, knew way more about javascript idioms, and wrote a fair amount of code for this library (meaning it would take time to look through). You begin to realize that these points are a given with any software project that you didn’t write. The biggest obstacle is knowing that you’ll have to really hunker down and go line by line to understand the implementation details.
Of course, going from top to bottom, through every line of code, is boring and not a focused approach. Instead, take a particular item/feature and look for its implementation. For example, I wanted to understand what was really behind the get/set methods of a Backbone model. So I just opened up the source code and did a search for ‘set’ and eventually found the set function for a model. I sat there, read through it (momentarily puzzled at times), learned some new things, and walked away with a better understanding of what was really going on.
That’s all it took, for me! From then on, I had no fear going to the source code to look things up. I had no fear monkeypatching parts of the library and building plugins/abstractions for it. The one courageous move was to just ask why/how this feature worked.
We all started out the same
Some of us went to school for Computer Science – to get exposed to algorithms, data structures, and more advanced fields/applications of those basic concepts; learn the math behind analyzing/comparing our solutions; and get a piece of paper that put us ahead of many of the self-taught programmers.
But look, we all start out as developers. We all start out tinkering with libraries and mashing lines of code together. When the code works, we raise our fists in glory. When the code breaks, we debug through our abstractions. We all start out as developers. Many of us stay there. Some of us strive to be better: to tackle harder problems, not only to avoid the aforementioned (bolded) reasons, but to make our marks on society through engineering software.
Discuss this article
Reddit: http://www.reddit.com/r/programming/comments/1sbmat/developers_vs_engineers/
Hacker News: https://news.ycombinator.com/item?id=6866747