Programmer, Developer & Engineer, differences

 



A programmer, developer, and engineer walk into a bar. The bartender is confused why one person has their legs across 3 bar stools.

If you’ve ever looked at job descriptions for people in the occupation of writing code, you’ll often see a lack of correspondence in how the post are created across companies. Most of the time you will see a job title stating the company is looking to hire a ‘programmer’, ‘developer’ or ‘engineer’. More often then not: these post are made by someone in HR who often would not deal with any of the technical aspects of the job and doesn’t really think about the connotation each word provides.

At the end of the day, for the people in this profession; as long as you’re proving to be effective in your position, the label designated to you by HR has very little meaning and you can use these words interchangeably as well. But as a technical professional, maybe the connotation behind these words do have meaning to you!

So what is the difference between these three closesly related terminologies? This is a topic that has been in debate for years. There’s a bit of nuance in everyone’s self-described definition however, the core behavior of these three roles has been fairly stable when compared to everyone’s perspective. I’m a very visual learner so I think the best way to communicate how I interpret the differences is with this diagram:


You’re probably wondering, “why is there a triangle that’s upside down.” For a while I was wondering why I kept seeing visions of an upside down triangle. The clarity of this diagram will come as we explore each layer of the triangle, starting with the programmer layer.


The Programmer


You’ll find the typical behaviors of a programmer are related to seeing a menial or repetive task and trying to automate them.


Programmers typically work with one language and create software that will accomplish simple task. The code of the software itself is usually heavily bloated and can be littered with anti-patterns, but it still gets the job done. A programmer is usually able to write code with their choice of language, but not truly understand the most effective way to write their code. It also may be missing many of the semantics needed to collaborate in an environment where there are multiple people contributing to the same codebase.

However this doesn’t mean programmers are ‘incompetent’. Sometimes you don’t need a highly scalable, extremely extensible solution — you might just need something that simply works. The solution might fail to work after maybe 6 months, but a solution that took 10–20 minutes to make and improved productivity or saved time for 6 months is still an invaluable feat; and being able to create that is an impressive skill.

Programmers are quite literally, just a tip of the iceberg (or upside down triangle) and ‘programming’ is an effective skill that doesn’t require any intense training or studying to learn. If you’re a non-technical who feels like you could write simple scripts to automate some of your daily task, I highly encourage you to put programming as one of the skills in your back pocket.


The Developer

It’s somewhat common for a developer to spend hours or days writing code then finally emerge from isolation to get ready to submit their work. They’re then told its gonna need some changes…

Software developers typically work fast. They usually know their stack well, have a good understanding of their langauge(s) of choice — and they know how to implement designs and ideas with code. If you need software; a developer will get you results, and even be ready to iterate on those results for the life of the software.


SDLC: Software Development Lifecycle

Software developers are very well rounded and typically keep up to date with current trends like new language features, frameworks, or development tools. Just like a programmer, they often look to automate their own behavior through tools and libraries so they can develop even faster.

So why would you even want an engineer when you can just get a developer? The answer is simple, developer’s need consistent technical direction. Often times you need to be explicit about what you want from the software. For example lets say you want to build a website to sell DVD’s to people across the globe. They’ll tell you “no problem” create a react app, connect/make some backend and get you a website that lets people click the DVD they want then have it sent to them. Then you’ll look at it on the phone and go, “why does it look like this.” Well that’s because you didn’t say you wanted it to be mobile friendly.


Developers are very capable; but unless you’re with them every step of the development process, they’re often developing at such a quick pace they don’t think about any edge cases. Their code will often need a lot of refactoring and if their code goes unchecked for too long, you’ll be left with mountains of technical debt. You might look at a developers code and go, “but why did you put all of this here?” or “why did you start using camel case, then switch to kebab case mid function?”. Developers often don’t concern themselves with the future, and are mainly focused on providing results for the present.


The Engineer

When you come to an engineer with a problem, they sometimes will not give you an immediate answer. They’ll give you 3 — 4 different solutions with pro’s and cons to each strategy and even help you make the best decision out of the choices.

The scope of the software engineer is the entirety of the upside down triangle. They’re expected to have the same capabilities of a programmer and developer; on top of needing to bring in their own unique skillset. You might think a software engineer is an absolute expert with programming languages, but often an engineer will spend more time looking at documentation than a developer would.

Software engineers do not avoid problems they dissect them. They take a problem, then create sub-problems and more sub-problems, then solve every one of them using their wealth of experience and arsenal of Computer Science theories, like the much loathed topic of ‘Data Structures and Algorithms’.

Software engineers love the idea of scalability. If you ever listen to a software engineer pitch an idea and ask them “but is it scalable?” you will very likely see them pause for a moment, then give you several ways it can scale, and to what extent. They do not need to memorize the functions and methods of a language because they know exactly how they would need to manipulate the data structure they're working with, and they know exactly how to find that method in a languages docs.

Software engineers often collaborate heavily and work to define any possible edge-case, and try to anticipate every possible error they could face before even writing any code. To take it a step further, software engineers will write code that tests the code they’re writing. This ensures they can immediately isolate an issue and push code more safely.


The system design skills of a software engineer can be frighteningly good. They’re often able to translate simple systems we can communicate to each other as humans (like a pacman game), to a translation that can be understood by a computer. If you didn’t know, computers can only speak in binary (01001000 01001001). We’re not going to discuss how somewhat legible looking code is transformed into binary because that is an extremely extensive discussion.

I can go on and on about the breadth and depth of a software engineers talents and responsibilities, but I’d rather talk about the downside of working with a software engineer, which is: They’re expensive! As they should be; these are people that can execute ideas into an infinitely scalable and extensible infrastructure. Development with a software engineer can be much slower, especially at the start. Overtime, a software engineer can build you such a solid technical infrastructure, it can ramp up the speed of development to speeds that will shock even shareholders.

Becoming a software engineer is difficult, because their is much more too it then learning the ins and outs of a language. There are concepts that need to be understood and applied appropriately in every scenario. You need to prove you can handle the designing of systems independently and be able to communicate your solutions well through documentation and direct communication when collaborating. Software engineers know they don’t know everything, but also know they can learn anything.


Wrapping Up

Weird upside down triangle aside, I hope I was able to communicate effectively my thoughts on the differences between these roles. Although HR might have you as a job code that doesn’t reflect your ability, you can hopefully use this triangle to determine where you are and where you would want to be. I also hope this article can give a good perspective to help anyone looking to find someone to ‘write some code’. There are definitely effective use-cases for every layer of the triangle. We also really don’t need to start PC shaming people if they don’t know the difference.


No comments:

Post a Comment