I’ve noticed in a lot of my past writings, I use the term, “software developer” and “software engineer”, interchangeably, as if there’s really no difference between the two.
But I stumbled across this article that begs to differ and contends there’s a HUGE difference between the two terms.
Are they on to something, or are they just nitpicking? After reading, the article, I’m sure they’re definitely on to something.
[bctt tweet=”In a nutshell, the primary difference between a software developer and software engineer is one of holistics. ” username=”profocustech”]
A software developer is given a set of specs or requirements to implement something.
Perhaps the requirement is to “build an internal web service that takes in a stock symbol, and returns the current value of the stock symbol being traded on the New York Stock Exchange”.
The specs are pretty clearcut and straightforward. The spec even tells you where the NYSE REST endpoint address is, which your internal web service will call and return the results back to your own internal service.
If I was writing this service in .NET, I might write it like this:
[[Route(“/api/stock/{{tickerSymbol}}”)]]
public decimal GetStockValue(string tickerSymbol)
{
// implementation code here…
}
Or if I were writing it in NodeJS, perhaps something like this:
(function (apiController) {
apiController.init = function (app) {
app.get(‘/api/stock/:tickerSymbol’, function (req, res) {
// implementation code here …
});
};
})(module.exports);
And as a software developer, I’d test out my code against the real NYSE external web service with lots of different stock symbols, and ensure I was getting the correct stock value being traded that day.
And once I got to that point, I’d call it done, mosey over to the coffee station for a fresh cup of coffee, and listen to the rest of my “Best of the BeeGees” playlist for the rest of the day (don’t you judge me!)
A software developer is really operating on the front lines, boots on the ground, and pretty much thinking about what code to write to implement the software requirement or functional spec is given to them.
It’s important to note the requirements, and the way to implement them, are usually all pre-decided before the software developer even receives them. By the time the software developer gets the requirements, the only thing the developer really has to think about is what specific code they will need to write, to complete the requirements.
And when I think about it, that’s pretty much how I wrote software when I was first starting out my programming career.
The senior software engineer on the team would decide what I was to work on and parcel out the work needed on a particular project.
I really didn’t have to think about making any major decisions about the technology, the overall architecture, or much in the way of any sort of analysis.
And I imagine it’s pretty much how every software programmer starts out their career… as a software developer.
It makes plenty of sense. Before you can run, you need to learn how to stand and walk.
The software developer needs to know how to write code. Period. LOTS and LOTS of code.
Just like a novelist’s primary toolbox are words, a programmer’s toolbox is full of computer code.
The software developer has plenty of things to learn and worry about just by concentrating on the act of writing code. They must learn the ins and outs of the capabilities of whatever programming language and technical stack they choose to use as their primary digital tools of choice.
And it’s definitely not going to be a quick overnight process.
I’ve been writing code primarily on the Microsoft stack for twenty years, and I can confidently say I could go for another twenty years, and still discover lots of new things and capabilities I had no idea it was capable of. It’s most definitely a lifelong journey of learning, and it will never stop.
So it goes without saying a software developer needs to hone their coding skills and that’s just going to take plenty of time, experimentation, making mistakes, learning from mistakes, and lots more trial & error.
For some, being a software developer is enough. Some people like the pure act of writing code. They’re completely happy with someone else taking the time to think about all the analysis and decision-making that needs to happen before the final coding requirements are finalized.
But for many others, including myself, I needed to grow beyond the needs of a software developer.
What’s the Difference Between a Software Engineer and a Software Developer?
If the software developer is the “boots on the ground” soldier who gets their orders from someone above them in the chain of command and acts on those instructions, the software engineer is the person who has a broader, more holistic view of the overall situation. That old saying about seeing the “forest for the trees” is pretty applicable here.
The software engineer needs to think about and analyze all the things that need to happen before a single line of code is written.
Program requirements just don’t come out of thin air. Someone has to take the time and effort to think and analyze the problem at hand.
Of course, the software engineer needs to possess the same sort of coding skills and expertise as the software developer, that goes without saying.
But beyond that, the software engineer needs to possess 3 key skills beyond that of coding:
1. Analytical skills
The ability to analyze a problem and figure out what it’s going to take to solve that problem… that is the true essence of software programming.
The actual act of writing code is the last thing that happens when writing software. And it’s really the smallest part of the overall act of creating software.
To this day, I’m still constantly amazed at how little emphasis is put on the act of analysis.
But in a way, it’s not surprising… we live in the age of agile development. The very name implies FAST, FAST FAST. Like Vin Diesel Fast & Furious.
We developers hear this mantra all the time. Agile is the new black. It’s all about delivering software on faster and faster iterations and cycles.
Yet at the same time, I don’t really hear much emphasis placed on the act of analysis.
In fact, in the agile world, there’s this phrase referred to as “analysis paralysis”. Analysis paralysis is the implication that spending too much time thinking about program requirements is a bad thing.
I find this concept utterly ridiculous. Insulting, actually. The implication that it’s better to deliver code that was completed on time, but is either riddled with bugs or does not solve the actual problem it’s supposed to address.
Yet, so many managers and executives absolutely ADORE the agile way of doing things, and I think I know why. It’s the allure and promise of getting your software deliverables faster, but without the extra cost in terms of time and money, that you need to tack onto the “butcher’s bill”.
And that means, not spending the time and effort to analyze the problem and do the proper research.
The software engineer needs to hone their analytical skills. Thinking about the business problem. Truly understanding what the problem is.
And more importantly, figuring out how to solve that problem with all the technical tools and knowledge you have at your disposal.
2. Communication skills
In addition to analytical skills, there’s communication skills. Believe it or not, the ability to communicate is as, if not more, important than coding.
A software engineer needs to interact with a lot of people within their own team and potentially anyone else in the organization they work for. Sometimes you’ll need information out of others and they will need information from you.
The ability to clearly communicate, either verbally or in written form, is crucial if you have any hope of getting what you need.
Writing functional requirements, specs, or e-mailing your needs to others is clearly an important and desired skill.
Which leads us to the last quality every successful software engineer needs to hone…soft skills.
3. Soft skills
Sure, a software engineer absolutely needs to possess the technical chops, so to speak, to get the job done.
But it’s not always about technical skills and knowledge.
The successful software engineer needs to know how to work well with others. To lead from the front. To be able to work well within a team environment. To collaborate.
I can tell you that “team fit” is an absolute requirement for technical job candidates these days.
I’ve been on the interviewer side of job panels, and I’ve seen plenty of more technically astute job candidates get passed over, in lieu of candidates who may not have the exact technical skills the job requires, but who clearly demonstrates they can work well with others and value team collaboration.
Believe me, the “lone wolf” developer, while once revered, doesn’t really work in today’s software development world.
The successful software engineer is constantly asking the question, “is this the best way to go about solving this problem”?
Just because something was implemented in the past, in a particular way, with a particular programming language and technical stack, doesn’t mean it should be the way a new business problem needs to get solved.
I’ve definitely reached a point in my career where being a software developer isn’t enough.
In fact, these days, I find I spend the majority of my time engaged in analysis, interacting with others, and thinking about the business problem, more than the actual act of writing the software.
So I suppose I need to be clearer about using the term ‘software engineer’ and not mixing it up with ‘software developer’.
Potato, potahto, tomato, tomahto.
