Skip to main content

Front-end development responsibilities as a (back-end) software engineer

What seems to be predominant in the industry today is a fixation on a software engineer simply creating (yes creating, maybe we'll discuss the importance of this verb for another blog post) products that solve a specific business problem (or requirement). While this is good from the outset. It raises several questions of the responsibility of a software engineer to begin with.

Before I get into the real content of this blog post, I would like to share with you my current working environment, so you can analyse any predisposed prejudices I may or may not have. My responsibilities at work are primarily of a back-end nature. That is, I do not do much front-end development. Although I have done front-end development in the past, my time and concentration has now focused on social media engineering. Nevertheless, I still maintain that a back-end software engineer should be able to provide the front-end developer with the flexibility, robustness and confidence to create the sexiest and most enjoyable product to use on the market. Let's face it. We can have a product that employes the latest of technologies. Whether it be voice recognition, deep machine learning, social media integration or QR Codes. And solves the most complicated business problems in the world. But if this product is not enjoyable for the user, that is, if it does not provide the best user experience. Then the product simply wont sell in the market.

So what does this, so-called responsibility of a software engineer entail? Let me explain by suggesting a term. Let's call it - programmer experience. And I think this is pretty self explanatory. It (programmer experience) can be basically summed up with the question.
How enjoyable is it to develop with this specific back-end API (or technology)?

My belief is, if a back-end API is developed in such a way that it is enjoyable to integrate. Then the front-end developer has no excuse to create the best looking, sexiest and most enjoyable product to use on the market.

What makes a back-end API enjoyable to use?
1. Proper defined error messages
Having no surprises for the caller. Using predefined error messages for everything.

2. A quick API
Yes, this is cliched, but if a front-end developer is waiting to long for the response from an API, then he/she will think something is wrong. The experience in this situation is instantly negative.

3. Using the latest technologies
I'm not saying let's use an Alpha version of a programming languages. But let's not get into the attitude of if it aint broke don't try to fix it rather let's have the mind-set if it aint broke, here's my opportunity to make it bigger, better, faster and stronger. The use of latest technologies on the back-end also allows the front-end developer to use the latest technologies on the front-end with confidence.

In summary. One of the most important things in the creation of a software product is user experience. And the responsibility to ensure the best user experience does not only sit with the front-end developer alone. It sits with the whole team. The user experience team, the back-end software engineering team, the project manager and the CEO. This even includes the non-technical staff of a team who must test and evaluate the user experience in an honest manner.

Thanks for reading


  1. As a front end developer I agree with this. Good back-end development and use of new technologies make the work for the front end developer easier, faster and better.


Post a Comment

Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?