Here at Futureheads, we pride ourselves on market and subject knowledge. This helps us understand our clients and candidates better, and keep ahead of the ever-changing tech market.
Last week, we invited a long-term contact of ours in for a Q&A session, so we could deepen our understanding of architecture. Ian Brayshaw @denormal an open source Product Architect, was happy to come in and answer some of our questions, and discuss some of his thoughts on this.
One of the key takeaways from this meeting was the question: What is the difference between development and engineering?
It is not a question I have thought about in a lot of detail. Generally, job titles count for very little and it is the detail and responsibilities of the role and skills that really establish what the position involves and the kind of developer it is suited to. In some cases a Software Developer and a Software Engineer are synonymous terms.
What Ian proposed, and what I am going to elaborate on, is that this is simply not true. In this article, I have set out 3 takeaways I have from this session that establish what the key differences are between a developer and an engineer.
Developers code; engineers know why they are coding
Developers code; engineers know why they are coding.
The key difference we discussed with Ian is that a developer can write code. Hardly a surprise. The key difference is that an engineer knows why that code has been written; they are involved in the bigger picture and they understand that they are creating a solution. Hence, an engineer is a solution finder.
They can see the bigger picture of what is trying to be achieved, and will make a decision on what are the best actions to achieve that; whether that is deciding which language is best to use, and who they will need to hire on the team in 6 months’ time.
Ian suggested the best way to achieve that was to design your software. You wouldn't ask a team of bricklayers to start building without telling what the house needed to look like in the end, would you? Through a detailed design, it is clear to all involved what their contribution will add to the overall project and will ensure that the architecture and system built will last.
Engineers have an Agile mind-set.
This is not to be confused with agile methodology, but the meaning everyone outside of the digital world would assume!
By an agile mind, Ian means that engineers look beyond their coding abilities and have business sensibilities. They are able to recognise where the business needs to go next, and how they can help them. Can’t be an engineer unless you are able to talk to non-technical people and help them understand what you are trying to achieve, and how you are going about that. At the moment, there is disconnect between the people making the decisions and the people who are building the solutions, and this is at the detriment of the quality and sustainability of the product/system.
An agile mind also recognises that there are multiple clients in any given project. Not only must you consider the end user, you must consider each person who has an influence on the project. From the CEO, through to the Finance department, to the Project Manager to the Junior Developer who is going to be hired in 6 months’ time to maintain the project – an engineer can communicate with each person on that team effectively and has the foresight to understand when each one is needed.
Ian was keen to stress that an agile mind-set is taught, and often it comes down to the environment you work in. The conclusion was that for a developer to be an engineer, they must concern themselves with how the business operates.
Engineering is an art and a science.
Ian posed this question to us, and asked us to consider what we thought Software Engineering is. Essentially, engineering is both. Although it is solution driven and has one output, an engineer can recognise that there are multiple ways that that solution can be reached and this is entirely subjective. Ian suggested that the only time engineers talk about their work, is when they disagree – because each engineer likes doing it in a certain way. They can sell you a story about why things should work, because they are passionate that the way they do it is right.
Good architects are good artists, because they understand that good architecture has been designed with precision.
The main conclusion I took away from our talk, is that Engineers see the bigger picture. They recognise the importance of understanding how a business works, as well as knowing why they are building something. They will insist upon designing software first so that they know what the final outcome should be.
The good news, is that this skill is taught. An engineer is not necessarily a better coder than a developer, but they do make sure that they are involved in every step of the process and they will question what they are doing before doing it. It is not the case that one is better than the other, as we are all aware that good developers are worth their weight in gold. The key idea is that as a person in technology, it is important to understand the differences so that you can decide which direction you want to take your career.
As recruiters it is our responsibility to help you understand which one you want to be, so we can introduce you to opportunities that will help you achieve that long term goal – whether that is as a developer or an engineer.