What’s The Difference Between a Developer and an Engineer?

What’s The Difference Between a Developer and an Engineer?

Image painted in seconds by AI.
Try AI stories for employer branding

In the industry, the terms ‘software developer’ and ‘software engineer’ are used interchangeably.

If you go for a role that is advertised as a developer role,  the reality is, you could be interviewing for either.

The confusion seems to lie in a few key areas; when the title is used, who writes the code, who builds, whether it’s the best way to distinguish between the two roles and if software engineers are ‘real’ engineers. Then ultimately, whether any of it even matters.  

Why does a title matter?

Well for starters, it can make the job search lines blurry. And it’s a big pool of jobs – at the time of this writing, there are over 1200 listings for ‘Software Developer’ and 1500 ‘Software Engineer across Australia.

If you’re in a position already and trying to head up the ladder or make a career out of code, then surely it also matters a lot when evaluating what next steps are available..

There’s no doubt a lot of confusion and debate, this post on Reddit varies in response from ‘no difference’ to the more direct actions of creating your own title change with one user stating;  

“My acceptance letter said “Software Developer”, but one day, I decided to change my job title on our website to “Engineer”. That was like 2 years ago and nobody has noticed and/or cared.”

On top of that, this won’t change anytime soon. With the advance of software, the number of technology and engineering roles will only grow. The Department of Employment forecasts 14,600 new roles in the information and communications technology (ICT) industry for software and applications programmers by 2019, so we thought it was time to seek some answers.

What the employers say

We decided to talk to two leaders to tackle the topic head-on and get a little insight from two sides of the fences. We caught up with Aaron Sempf, Head of Tech at Tribal Melbourne and Brett Raven, CTO at the Big Red Group.

Aaron is a trained engineer with a background in structured systems and software development. Recently, he’s been building up his own team and when looking for new hires, researched what roles other organisations are advertising. In talking with industry recruiters and counterparts in other organisations, he found a lack of understanding between Developer and Engineer roles. His perspective is also framed as an engineer having worked in a structured systems and software development environment.

Brett joined RedBalloon in early 2017 to help drive a product re-build and move the technical roadmap forward. Since then he has moved to across the Big Red Group, providing technical guidance to Redii & other group companies.
Brett studied Computer Science at University (so is not an “Engineer” himself) but has led strong engineering teams in companies such as Lux Group and RedBalloon

Developer OR Engineer

“There is a fundamental difference between the roles of developer and engineer.”

Aaron: While I typically agree that “titles don’t matter”, there is a fundamental difference between the roles of developer and engineer.

The Engineer

The difference between both is easily distinguishable by their role and the tasks they perform in the development life-cycle.

However in the constantly evolving, user-centric, creative communications environment; and with all the JS frameworks, Markup Pre-Processors, languages and application frameworks pushing the boundaries of what’s achievable in the browser and mobile devices, the difference between Engineer and Developer is a little harder to distinguish.

Traditionally an Engineer, no matter the stream of engineering, is a person who is competent by virtue of their fundamental education and training to apply scientific methods and interpretation to the analysis and solution of engineering problems.

What this means in simple terms, is that an engineer has a fundamental grounding through education in engineering principals, and through the application of engineering concepts they create solutions.

The Developer

A Developer on the other hand, tends to be more creatively minded applying patterns and practices learned through self-discovery, on the job, reading books and blogs, or courses focused on specific aspects of the development life-cycle without the fundamentals of scientific method and engineering principles.

While so far I’ve only implied the educational differences and applied methods and patterns between engineer and developer, their role within the team also serves a different purpose.

The traits I look for in individuals when filling either an engineer role or a developer role can be quite different, however, the tasks or tests I give to both are the same, but evaluated in different ways.

Running through technical knowledge questions is a simple way of getting a basic indicator as to level and area of expertise, but it’s the technical assignments and obscure questions that really set apart developer from an engineer.

My favourite of the obscure questions would be the simple math test 6÷2(1+2)=? … The individual must provide an answer and an explanation as to how they achieved their answer.

This test demonstrates the individuals educational foundation. The two most common answers I get from this are 1 and 9, but it’s the explanation of how the candidate came to this answer which is most telling. But what really sets someone with a mathematical or scientific foundation apart from someone without, is the third, more uncommon answer.

“The equation is unsolvable due to ambiguity”. A discussion with an individual who provides this answer will show that they are looking at more than just solving the immediate answer, but looking at understanding the equation from a higher level. In engineering and high-level math, there can be no ambiguity, so as to understand the intent of the equation and the potential effect it may have down the line.

A developers true creativity is demonstrated more in the technical assessments, such as a given input and expected output test, where the candidate must write the logic to accept the given input and provide the expected output. In such a test, the developers ‘Code Personality’ shines through with their use of patterns in applying their logic.

There is no right or wrong answer, as long as the desired output is achieved, the solution very much comes down to the individuals ability to turn instruction into a solution within the given framework.

At the end of the day, if I were wanting to demonstrate that I can think creatively, and develop logical solutions to modular problems, which is very much what Web Development in the creative communications industry is all about, I would much rather be called a developer.

On the other hand, if I want to demonstrate that I can apply scientific and engineering principals to create an overarching solution at a higher level than describing the workings of the many modules that make up the whole, then I would want to be called an Engineer.

Developer AS Engineer

“I have preferred to use the categorisation of ‘Junior’, ‘Mid’ and ‘Senior’ as qualifiers, treating Developer and Engineer as interchangeable .”

Brett: I too feel that “titles don’t matter” and that the lines blur very easily between many roles these days in the tech space. Everyone has heard the terms developer, programmer (/analyst), engineer, coder and more, interchangeably, for at least the last decade.

Traditional definitions seem to blur and fade with the latest trends. The number of people either writing code or paying for code to be written has exploded in the last five or more years – to a point where we’re all probably less than six degrees of separation away from a ‘developer’.

A different type of category

The only real separation I can see justifying a distinction between ‘Developer’ and ‘Engineer’, is the breadth of lateral thought across the tasks, goals or business problem at hand. In my career I have preferred to use the categorisation of ‘Junior’, ‘Mid’ and ‘Senior’ as qualifiers, treating Developer and Engineer as interchangeable.

What I mean by this is, I expect a Senior Developer to behave and think holistically. They should be applying what is essentially the scientific or engineering method with everything they do and consider the architecture and collateral effects of their work every minute. I expect a Junior developer to perform the tasks and implementations given to them, focusing in on what they need to know, rather than knowing everything. I expect Mid-level developers to start considering their wider code impact, still perform assigned tasks and start thinking in terms of architecture and the business requirements in more depth. For me it’s a question of professional development that dictates the breadth and detail (or conversely the strategic impact) of the task at hand, not the granular meaning that sits behind the title of that role. It’s about the person and their capabilities, versus what a traditional job description might dictate.

On the comparatives

Aaron sums up his theory in the terms, “a developer implements. Focusing their talents often on a single area, a specific task, or within a specific environment, without looking at the “bigger picture”. While an engineer architects, always looking at the “bigger picture”. An engineer can assume the developer role, but an engineer’s core focus lies within the architecture, designing and planning.

To put it into a simple analogy; working in a mechanic does not make one a mechanical engineer, and so writing code does not make one a software engineer.”

However, Brett argues, “The analogy of mechanic vs mechanical engineer may be better posited for software development, by comparing journalists to editors. The latter are able to learn their broader skills on the job with years of experience and solid performance. Mechanics would not usually have a chance to learn the necessary disciplines (e.g. maths, physics, materials etc.) required to actually build the machines they know how to fix.”

In Conclusion

To be honest, it’s a difficult one to sum up. You can see why it’s challenging to instantly identify what role means what, without seeing context from the person who is posting.

The commonality among all answers is that titles don’t seem to matter.

The best advice can possibly be summed up by Jason Roos, Software Engineer at Sony Interactive Entertainment,  who says it comes down to what you believe in yourself:

“The term “engineer” typically connotes a “builder” of some sort whose design process is methodical, involving a deliberate application of established patterns and principles.

Certainly there exist developers who satisfy this sense of the term; however, in practice, the formal title means nothing. Software engineering is not a licensed profession, and companies often exploit this fact and the value of the title by offering it as a fringe benefit to their employees—irrespective of personal methodologies.

Having said that, I don’t refer to myself as a “software engineer” because my employer tells me I can (even if that is, in fact, my title). I do it because I believe myself to be one. I do it because I respect the connotative meaning of the term and because I strive each day to live up to that meaning.

If anyone feels the same, then in my book, he too is a software engineer (no matter what appears on his business card).”

So, If you’re thinking your current title is incorrect, the employers seem to agree that they don’t hire on title. But if it’s something important to you then speak to your boss,  and put your case forward – it doesn’t seem a deal breaker to change.

If you’re looking for a new role, make sure you’re clear on which category you want to fall into, and then, quite simply, ask questions to the person who posted the ad about the core components you’d be required to do in the role.

If all else fails, and you’re still at a loss, don’t worry – some say Software Engineers will be obsolete by 2060 anyway…

Try AI-powered Employer Branding to attract & retain talent

72 AI-powered languages

Trusted by the world’s top brands

Dedicated Customer Success

What is Employer Branding?
Employer Branding is essential for any company looking to recruit or retain talent. Your employees now have the same expectation as customers - in other words they want to know 'why' they should work for you, not just 'what' they are doing.

What is your company story and what do you stand for as an employer? Employer Branding content builds trust with your employees, increases your marketplace reputation and turns you into an employer of choice.

In today's environment employers need to work hard to stay relevant and create environments where employees are engaged and motivated. A strong Employer Branding strategy -projecting a positive brand identity - can help attact and retain the right people.

Especially in times of recession it is important for companies to set themselves apart from the competition and create strong bonds with their existing and future employees.

The Martec's AI-powered Employer Branding content tool is the most powerful platform on the planet for Employer Branding strategy, content creation, distribution and reporting. Used by many of the worlds' top Employer Brands for scale, impact and precision.

And 100+ other world class employer brands across 30 countries