Engineer vs. Coder

Seeing as I have been fairly sick with flu the last week (over my birthday) and busy with various other things besides coding, I have no new demo to put up on the site. I considered expanding on my presentation around RESTful services, but thought that I should put up my understanding of what a software engineer does vs. what a coder / programmer is expected to do.

There seems to be a lack of understanding around these terms when people approach me to do work for them or when I have to hire staff. Let us start off by summarizing some of the information around the web…

Coder / Programmer

… Programmer: Coder. Code Monkey. Clickity-Clack, Clickity-Clack … stackoverflow

For me, a critical distinction has always come with Software Patterns. I’ve never met someone who was “just” a programmer who had a grasp on what they are, and why they’re good. Conversely, most (albeit not all) Software Engineers that I’ve known and respected have had a good grasp on Software Patterns, and understand why they’re such a good idea. stackoverflow

… programmer probably means person who knows how to write code … stackoverflow

Programming is often associated with the coding phase, although the term is sometimes used more loosely, but you can have software engineers who don’t do any programming at all, because they specialise in one of the other development phases. Often, a software developer will be involved in more than one development phase depending on the size and nature of the organisation, the size and nature of the programme, and the development approach applied. absolutewrite

Software Engineer

… software engineer may mean a person who has studied software engineering or computer science … stackoverflow

… Engineer: Designs and implements components and frameworks for Developers and Programmers to use … stackoverflow

… Software Engineer is more qualified in the software development lifecycle as a whole (requirements, analysis, design, testing, team management etc etc) … stackoverflow

While programming requires a knowledge of computer languages and algorithms and data structures, all of which are very important, software engineering also involves knowledge of projects, maintenance requirements, documentation standards, software design, etc. The things that are involved in successful software projects that are NOT actual programming. stackoverflow


Traditional Software Engineering encompasses several development phases, including requirements analysis, design (sometimes broken into architectural or high level design and detailed design), coding/implementation, test and integration. As a software engineer on a large development programme you could end up in a team specialising on one development phase, for example the architectural design or the testing, or the coding. absolutewrite

Here is a video that I do not fully agree with, that you might find interesting.

Why is this important?

The reason I felt I should write about this, is that I always viewed myself as someone who develops software, until recently however. After dealing a bit with people who either want to hire me or when I want to hire someone else, I have had to make the distinction between the two to effectively get what I want from each scenario.

When hiring, I often try to get someone who is more inclined towards the software engineering side of things. They generally think along a different wave-length to a coder and try to develop a solution that will be stable, maintainable, scalable, easily transferred, and mostly complete. Coders seem to just see a single obstacle in front of them and get the job done, effectively getting the obstacle out of their way. They rarely see the bigger picture or even want to.

What is important is the fact that you need both people on your team. The different ways in thinking bring diversity to your team. The effectiveness of the coder to pump out code and get things done quickly is great for pressure situations and other menial tasks. However, core issues that require more thought and design, the coder rarely wants to be involved with and generally sees as abstract. This is where the engineer tends to shine.

What I have found is that the software engineer gets bored doing only a programmers work and the coder avoids getting involved in what he sees as an “abstract” discussion. To get the most out of a hire, you need to identify what type of person you are hiring and allocate them the correct type of work to keep them stimulated and satisfied. You will be amazed to find how many companies end up hiring software engineers for only programmer type work and wonder why they feel frustrated and leave shortly after the hiring process.

When someone wants to hire me for a position with their company, I usually have to spend a significant amount of time with them to try and figure out what it actually is they envision me doing and how I will fit into their structure. It is important for me to do this so that I know whether I will be a good hire for the company and add value to their business. Which is further important, because if I add value then I build on my respect, reputation, and personally feel satisfied. I encourage job seekers to spend more time evaluating the position they are applying for more thoroughly for fit than just accepting the package. How sustainable is working in a position you do not want to be in, just for the package?


To make this short and sweet, a coder codes and a engineer builds solutions. Determine what position you want to [fill / fulfill] and do your homework on the [hire / position] to make the most out of your effort. Here is an added tip, if a potential employee’s past experience is involved with consulting, solution design, architect or analyst type work and their interest is clearly around business, they are more likely a software engineer or something other than a programmer. Just because someone knows how to code… does not mean they are necessarily a coder!

  • Fision

    Well said! And I agree with your summary completely!