Software Developer vs Software Engineer

In my career I have noticed that there seem to be a lot more Software Developers than Software Engineers by several orders of magnitude. I will define the difference shortly.

Why should you care that there may be a distinction? If you are potentially a developer or an engineer knowing which you are can inform you of where you might be happy to work, what your strengths are or, if you are unhappy about where you fall, allow you the opportunity to strive for change. If you are concerned about the cost of running your department confusing software developers with engineers wastes time and money. Having developers is not a problem, the waste is introduced when you expect one to be the other.

The Difference

These are my own definitions. They may be similar to others you have read. Personally, I haven’t read much on the topic or seen the difference pointed out. This is the reason I am writing this article.

Software Developer: someone who produces software to meet the requirements they are given.
Software Engineer: a software developer who is also concerned with the cost of producing and maintaining the software they produce.

The difference may seem small at first glance. Software Engineers are all Software Developers but not all Software Developers are Software Engineers. In reality this is a continuum; you will find people on both polar ends and everywhere in between. In general I have found that people tend to be closer to one or the other and less likely to be in between.

Let’s examine some of the ways that developers differ from engineers when that small difference in definition matters.

Requirements

Engineers and Developers expect and require different kinds of requirements.

The requirements you give to a developer should be more precise. You should be giving them requirements that are immediately actionable. You should be telling a developer what software to build and leave them to figure out how to build it.

When you give requirements to an engineer you should be giving them a problem to solve and parameters that the solution must fall within. An engineer will first be concerned with what to build that will best solve the problem without undue cost. They will produce the requirements that lead into their own development when they start writing code.

One key, potentially surprising, result of this difference is that a Software Engineer might not produce software as a solution or they present results that show that the problem is not worth solving.

If you give a Developer the kinds of requirements you would give to an Engineer they are likely not to produce the kinds of results you want. Perhaps they will flounder, maybe they won’t produce what you were looking for, or they might need intervention from someone else to produce anything at all. When you give an Engineer the kinds of requirements you should give to a Developer they will feel frustrated and constrained.

Hiring

One result of the difference that arises from the way problems are approached between Engineers and Developers is that a group of engineers tends to accelerate their output over time where developers will stay roughly constant.

There is, of course, the commonality of gained experience so either type of software creator will produce more output over time due to increased experience. The dominating factor in this comparison is in the pursuit of lowered cost for production and maintenance by Engineers, not in experience gains. A group of Engineers will automate repetitive or tedious tasks, they will take on practices that prevent rework, and they will try to optimize their own time. The more tasks completed by this group the less time future tasks will take over time.

How does this relate to hiring? Any time someone new is brought into a team or department there is an initial cost in onboarding and acclimation as well as an ongoing cost of additional communication and coordination. One person, working on a project alone only needs to communicate their results. When two people start to work together you won’t get double the work done because some effort is lost into the communication and coordination of both people at least between each other. Under normal circumstances you should still expect to get more work done with two than with one after the initial acclimation period.

This is the case with Developers. Hiring more Developers will scale linearly. Output will increase in correlation with staff size. As more software is produced the cost of maintaining it increases so that, over time, you will need to continue hiring staff in order to continue producing software.

Hiring Engineers, on the other hand, scales better than linearly. Remember that the more tasks a group of engineers complete the less time subsequent tasks will take. It’s true that the basic equation will hold and adding one person will add a little less than one additional person’s worth of output. At the same time one of the qualities of an Engineer is that as they complete more work they should be accelerating future work. Engineers will all be doing this so hiring additional engineers “accelerates the acceleration” so to speak. Hopefully your Engineers are automating much of the maintenance tasks meaning that you are not required to keep hiring additional staff to continue producing software.

Agile or Waterfall

Waterfall has become something of a dirty word around software. Set this aside, waterfall is often the most appropriate way to get something done. Sure, there are plenty of examples of how it can go wrong. There are also plenty of examples of where agile is a big waste of time. Waterfall is characterized by “projects” and agile by “ongoing work.”

I find that most of what I read and hear about successful practice of agile is rooted in Software Engineering. In one way or another the goal is to produce a result with the smallest amount of cost possible, measure the return on that effort, then do it again; practice Engineering, inspect what happened, and use that knowledge to practice Engineering again.

Projects go a little differently. Someone (usually outside the team doing the work) has already arrived at a conclusion. They need someone to make their solution a reality. They are looking to give a set of requirements and, after some time, receive what they asked for the way they asked for it.

How often I have seen a project, with deadlines defined before work begins and predetermined results, be called “agile” is worthy of an article itself. Suffice it to say that project thinking aligns with a Developer mindset and agile aligns with an Engineering mindset.

I am not making the claim that good practices from one cannot be good for the other; Engineers can work in projects and Developers can work in agile. I am, however, making the claim that some of the worst experiences I have had were when projects were disguised as agile because someone was commanded that work be agile and done by Engineers regardless of all else. Someone thinking like a developer was put in charge of a team or teams containing at least some engineers, lined up a bunch of work as a project, then called it agile with a bunch of buzzwords that did not mean to the speaker what those words mean when used in that context. This produced waste and friction. In the worst of these the project that wasn’t a project took twice as long as was initially estimated, produced an inferior result, and left everyone unhappy.

How Can You Tell the Difference?

The only way to tell the difference, that I have found, is examining carefully how someone approaches their work.

If this person is already working with you this should be easy to observe. If you’re interviewing someone then you are left to ask them questions about their past work in hopes of uncovering what you’re looking for or looking for indicators in their resume.

“Tell me about a time when you handled a production outage” could be a good way to determine whether they handled it like an engineer or like a developer. Either type of candidate would likely start by returning their production environment to working order. An engineer would, likely, take some kind of extra steps. Perhaps they would try to ensure that the problem was caught and stopped with an automated test, automatically remedied if it were to happen again, or something else.

A resume indicator may be seeing reports of measurements. Measuring improvements is commonly an engineering practice and uncommonly (but not never) a development practice.

Should you go Developer or Engineer?

It is my firm belief that a mix of both Engineers and Developers working together will produce the best results.

It may have seemed like I was saying that Engineers are more valuable than Developers. This would, in turn, make it seem like being or hiring an Engineer is automatically the better choice. This is not so. I will stress again that the best thing is to know the difference and act accordingly, using each to their strengths. There will be times when something just needs to be done the way someone is told to do it, when a project is more appropriate than ongoing agile, or when an individual task needs to get done without the additional overhead of improving future tasks. There will also be plenty of times when engineering a solution is a better use of time and money than developing someone else’s solution. In most cases a team probably needs both sets of skills to accomplish the goals set before them.

I have found throughout my career that there are many more Developers than there are Engineers. Ignore job title when considering this statement, I have seen more “Software Engineer” positions than I have “Software Developer” despite nearly every software producer I have worked with having been a developer. This has several implications. One is that if you want to have a software team you are almost guaranteed to be unable to hire only Engineers, even if you wanted to despite my advice to hire both. Another is that the expectation does not match reality in most companies. This could be because they don’t define the difference the same way I have. I have found it more common that companies want Engineers, hire anyone who appears competent as a Developer in an interview, then expect them to act like Engineers.

You can mix Developers and Engineers. This is likely an optimal scenario given the availability of each type of person and the real circumstances of software production. You should expect that Developers will continue to be Developers and Engineers will continue to be Engineers. The Developers may have their output enhanced by their Engineer team mates and reap the benefits. Knowing the difference and not expecting Developers to be Engineers or vice versa will help to keep everyone happy whether you are a member of the team or a manager of a team.

Play to your strengths

If you think you are a Developer then be a great Developer, don’t waste your time being a mediocre Engineer.

If you think you are an Engineer then be a great engineer, recognize that not everyone thinks like you do, and use your different perspective to enhance the work of your entire team.

If you are a manager of either or both use the knowledge that Engineers and Developers are different to make the most of your team and bring job satisfaction to both types of person.

The world needs Software Developers and Software Engineers. We all will get more done by working together and using our differences as strengths and we will be happier doing it. More often than not I see and experience an inability or refusal to discern the difference I have tried to outline here. Disappointment and dissatisfaction are the result of trying to force everyone to be either a Developer or an Engineer.