User-centric development

Do you know what our main job, as developers or engineers, is? Think of it for a moment. I can bet that every answer you come up with leads to “to make our users happy”. Check this out:

My main job as a developer or engineer is:

• To build APIs… so that my users get the information they need.
• To build a server infrastructure… so that my users get the information they need quickly and reliably.
• To build websites… so that my users get the information they need clearly and concisely.

See? Any answer you think of will end on users benefitting from your work.

“Our main job as developers and engineers is to make our users happy.”

Moreover, we are users too. Think of a time when you were using an app that got you frustrated. Maybe it was a bank app, or a delivery app, or a social media app. Didn’t you wish that the developers did this or that? You might have said: “why didn’t they use this technology or technique? It’s easy!”. There are millions of users experiencing the same feelings.

Us and them

From a simple perspective, this story has two groups with a symbiotic relationship: Us (developers, architects, Engineers, The IT Crowd, etc.) and Them (users). We build sites and apps that our users use. And they pay for those, keeping us employed.

But, as you know, the Us group has many players whose job is making life easier for the next player. Let me explain:

We can divide the players into 4 groups:

• IT Engineers
• Backend Engineers
• Frontend Engineers

The fourth is a special group comprised of architects, heads, managers, directors, and the sort, whose job is to guide and help the former 3 groups.

Now, as I said earlier, one player’s job is to make life easier for another player. Here’s what I mean:

• The IT engineer’s job is to make the backend engineer’s work easier. A backend engineer needs a robust, always available, secure, and easy-to-use infrastructure to deploy his stuff on. The backend engineer needs to have everything configured, just like plug and play, so they can concentrate on building databases, fast APIs, and services. IT engineers also help frontend engineers by giving them a place in which to store the pages, for instance, an AWS S3 bucket.
• The backend engineer’s job is to make the front-end engineer’s work easier. A frontend engineer needs fast APIs and services to consume. They need all the information parsed and all calculations done, so they can concentrate on building fast websites and apps.
• The frontend engineer’s job is to make the user happy. The user needs an app or website that is easy to navigate, accessible in every way, and that gives them the information they need, right away.

Thinking this way we can see that, ultimately, each player’s job is to make the user happy. Every step of the process is crucial in achieving this. We can’t omit any. They are all important.

Why should a user have to click too many times or jump through hoops when using a website? Why should a user be not able to use a website because of a disability? Why should a user wait an eternity for a page to load or a table to fill?

Why should a frontend engineer have to bloat and block the Javascript execution by performing expensive calculations or ordering lists of data if the API can perform those? Why should a frontend engineer make several requests to the API if the backend engineers can combine those and allow for a single request?

Why should a backend engineer need to wait in line for IT to give them assets if IT can provide access to resources, databases, reload procedures, among others, with the level of security that’s expected?

Conclusion

My intention with this article is not to stir up engineers and developers. On the contrary, we need to keep in mind that our job is to help someone else. It’s easy to ignore keyboard navigation and concentrate just on mouse usage but that affects users with certain kinds of disabilities. It’s easy to make simple endpoints and avoid building complex ones but that pushes the Frontend engineer to make more requests, making the site slower. It’s easy to avoid building an API that lets you reload services or make complex queries, or using a limited logging tool but that makes backend engineers wait longer after making requests, putting the Sprint in danger.

Let’s all think about how our job is helping others and be proud of a super simple to use infrastructure, API, or website we built. At the end of the day, everything we do (good or bad) will affect the user experience and that is our main goal as developers and engineers: to do good so our users feel good.

Thank you for reading!