Earlier this week a question was posed to myself and a colleague which encapsulated one of the core understandings of my journey within Software Engineering.

I may have mentioned before that when I first left school I spent 5 years training and working as a mechanical engineer, specialising in the design and installation of heating and ventillation systems in schools, hospitals, shopping centres and other commercial buildings around the Lancashire and Greater Manchester area where I grew up.

Of course, me being me and all, well I love my analogies, whether it relates to describing features by cross referencing Lord of the Rings or explaining the different types of software project by comparing them to genres of literature.

Within this post, what I want to explore is how the different types of “code monkey” relate to the different trades which are utilised within the building industry.

My own view of software is it’s all about data logistics. The pipe fitter in me relates this very closely to fluid dynamics. It’s all about how we move data from one part of the system to another in the most efficient manner, and yet we are building infrastructures which couples software engineering very closely with building architecture.

Both industries contain differing crafts, be it a plumber or a plasterer, a bricklayer or a carpenter and within these crafts there are different levels of experience. It is on this which I wish to draw the comparison, for whatever the discipline, the journey is the same.


Software Role Construction role
Programmer Apprentice
Developer Craftsman
Engineer Engineer
Architect Architect


The Programmer

First up is the programmer. A programmer is the very core of all software disciplines. Not one engineer has started their life as an engineer, at some point in time they were a programmer, churning out code to meet a particular function without any real understanding of what that function is actually meant to achieve. Programmers generally follow api documentation to the letter without being able to see the bigger picture or understand how things really fit together. Programmers are at the very start of the career ladder and are just learning the trade. They know how to code in the same way an apprentice craftsman knows when to use a hammer but isn’t as refined as to know the exact type of hammer to use and will occasionally pick up a ball-pein hammer to drive in a small tack. It might do the job if wielded correctly but is most likely to bend the nail or damage the frame. Programmers haven’t learned the finess of their craft at this stage, they just know there are tools to do a job and a screwdriver is as good as a chisel for knocking holes in a wall.

Don’t get me wrong on this, I have been there, I’ve made those mistakes both as an apprentice mechanical engineer (OK, I might have drilled holes in the wrong wall once or twice), and as a programmer. These aren’t things to be ashamed of, these are the learning curves and building blocks of our trade.

The architect this discussion started out with highlighted, that to his mind, a programmer was very much like a labourer. They are very much of the mindset of “Here is a solution, here is a language, implement solution in language”. I’m not completely bought into this mentality because it describes “Monkey see, Monkey do”. Within the building trade labourers are used to heft equipment from one place to the next, to clean up ahead of the skilled trades entering, to do the grunt preparation so the craftsmen can work. To do a comparison of programmer to labourer may seem a little unfair, it implies that there is a lack of skill in place but that’s the crux of it. Labourers have no specific skill to speak of, or if they have, their skills are absorbed and mis-used.

Instead, the way I see it is a programmer is very much an apprentice. They’re learning their trade. The only thing that differentiates them from a labourer is ambition.


The next rung on the ladder is the developer position. To my mind, a developer is a programmer who has started to spread his wings a bit. He’s branched out and reached that next level of understanding. His code is clean and well tested, he understands the principles of Test driven development, Object oriented programming and the fundamental principle of model, view, controller. A developer can write clean code and install it on a system where it will run fine and not cause any major problems. A developer understands the basic principles and how they are applied, they are the craftsmen of the building trade, they are the joiners, the pipe fitters and the electricians. Each developer has a specific skill to apply and in the same way that you don’t call a carpenter to fix a leaking tap, a python developer will take it as an insult if you ask him to write a program in c-sharp. He probably could do it but it would be a hatchet-job because he’s never branched out that far.


An engineer within the building trade is a cross-over between a designer and a craftsman. He is someone who understands the intricacies of a problem just by looking at it and can formulate a solution to resolve the issue at hand. When I think of engineers, I make a mental nod back to the age of steam and the men who designed and built the engines, bridges and railways in cast iron and steel. I think of software engineers as being the modern day equivalent. Engineers don’t care what language it’s in, they care about the problem and they want to find a solution to it. They design their way around the intricacies and find a way to make it work. True engineers look at a problem and see the solution by understanding what lies in place already and can see how to build on top in order to ensure their solution stands the test of time. They are masters of their craft and will pick up a problem, formulate a solution and choose the right tools to build it. It doesn’t matter to them that its’ origin is in an archaic version of COBOL or PASCAL, they’ll dust it off if needs be and if they don’t recognise the nuances they go and learn. They are language agnostic because the problem isn’t a language driven problem it’s a mathematical driven problem, and this equates in both industries.


For me, architecture is the dream I’ve been waiting for. Ever since I was a young boy I wanted to be an architect. I didn’t care what form of architecture I did although when I was a kid it was very much about buildings. Now though I see architecture in a different light. When I was growing up the concept of software architect didn’t really exist, this is a relatively new role defined by the changing times we live in. Within the construction industry architecture is about designing buildings which fit in with the landscape, coming up with new and innovative ideas to solve common problems. Software architecture is very much the same in this, the two roles are equatable at an abstract level. It’s all about designing systems which fit within the landscape, choosing the right components to suit the requirements and working out how they fit together without tarnishing the external facade.

4 thoughts on “Comparing Roles

  1. Raju Grandhi

    Good article Martin. Explained the thin differences between Programmer, Developer and Engineer in well manner. However I think all the three roles would be done by single person now a days and should be aware of what the exact role and responsibilities while performing in day to day routine isn’t it?

    1. Absolutely. I see this as a transition from programmer to architect within the confines of one person learning a craft but at the same time they are roles fulfilled by many people. There are those who never make it beyond the level of programmer and some who are happy to sit at developer or engineer level without ever aspiring to become something more but the full path for any aspiring architect is to move through these different phases. A programmer will become a developer after a couple of years, then move on to engineer and finally move into architecture. What level a person stays at is simply a matter of ambition 🙂

  2. Phil Marsey

    Interesting read. Good comparisons of Programmer and Apprentice, specifically about aspiration being a differentiator between Labourer and Apprentice.

    With regards to “it’s a mathematically driven problem”, something feels wrong here. An Algorithm and a Mathematical Method, share similarities in terms of logic and correctness, but when it comes to Software Engineering, isn’t there more to it? Where do all the Software Engineering/Design best practises of Single Responsibility Principle, Encapsulation, Abstractions, Loose Coupling, etc, fit in? Is the construction comparison here, the experience/knowledge of the multitude of different building materials and technics and when to apply them.

    1. You raise a number of very interesting questions here but overall I think the basic principle remains the same. Within my mind, I see all the principles of Software Engineering as stemming from mathematical driven concepts. Think of it this way, the concept of single responsibility either does one thing or it doesn’t, it’s a logical statement. If it does more than one thing then it’s not single responsibility. Encapsulation can be described in a similar manner, this is set theory whereby you are either restricting access or grouping components and by doing so saying “This is the set of accessible functionality provided by this particular set of objects” or you are bundling data with functionality and saying “This set of data belongs with this set of functionality”.

      Which ever way you choose to look at it, the principles of software engineering can be found clearly stated within various different disciplines of mathematics, primarily to set theory, in particular when dealing with OOP.

      With regards to the construction comparison, there is easily a comparison of system architecture to be made here. I prefer to use Lighthouses for this comparison though.

      The best built lighthouses have stood the test of time and the ferocity of nature. Why? Because they are built to blend in with their surroundings instead of on top of them. Their foundations are bedrock, their outer shells are dovetailed together, every joint precisely cut so that it slots together seamlessly. Lighthouses last because they work with their surroundings instead of against them and the same can be said of system architecture. We should work with the systems and not hack at them to achieve a particular goal.

      In order to build a system that will stand the test of time it is absolutely reliant on the understanding of the different tools and techniques required to serve a particular purpose and that can only be achieved with experience. The path which I have described here is the journey of a craftsman. Why? Because every craft contains the same journey. Whilst the components may change (pipe, wire, wood, brick), the tools are often shared between crafts (hammer, chisel, screwdriver, etc.) and all crafts may move through the same set of roles, apprentice to architect.

      Going back to the statement relating to mathematics for a moment, regardless of the discipline I would always argue that once you strip away the layers of abstraction we have built on top, the underlying principles are always mathematically driven, even though it may be easy to lose sight of this on occasion. Algorithms are, at the end of the day derived from propositional calculus and our code is essentially a mix of algebra and logical decisions.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.