In technology, we typically associate ‘design’ with front-end developers and visual aesthetics – a beautiful website or a visually appealing user interface. But, backend developers are designers too. They are masters of System Design, meticulously crafting the architecture, dependencies, and data structures that influence user experiences. This post will explore the hidden artistry in their work.

The internet is overflowing with memes of “dev vs designer”, and it’s undeniable that it’s a collaboration that can yield both spectacular and hilarious results. “Designer” is a term we often – and sometimes exclusively – associate with roles related to “interface design” like Web Designer, UI/UX Designer, Product Designer, etc. Maybe, even unconsciously, we associate it with someone artistic, creative and with a focus on building beautiful and intuitive products with carefully cultivated aesthetics.

However, the focus on the artistry of “design” often leads us to forget the pragmatic side of it. Designing ultimately means making decisions about how things should look, function, and operate to meet specific objectives. That’s why backend software engineers are designers too and “system design” is also a category of design.

Beyond the fact that backend engineers can contribute to the design of a product with feedback and ideas – which is a whole conversation in itself – they also have to consistently decide on and shape the design of software. From the whole architecture of a system, to its individual dependencies and data structure, developers need to make hundreds of decisions that impact the end-user experience and the usability and maintainability of software.

Although they are often pitted against each other in hilarious memes, they are actually more similar than people think.
The Pragmatic Side of Design
Design is a two-sided coin with aesthetics and creativity on one side and pragmatism on the other. Both coexist and are essential to delivering a product that meets user expectations and requirements, but the artistic side is often more visible: it prioritizes things like an appealing and intuitive interface, which is what users immediately notice and appreciate.

The pragmatic side is just as important in steering choices toward solutions that are performant, scalable, and maintainable … however these aspects are not always as visibly evident to users.

A software engineer’s design choices permeate every layer of the tech stack and both frontend and backend engineers grapple with them daily. They include things like:

Defining the system architecture
Adding a new microservices
Bringing on a new SaaS provider
Changing an API
Editing the data structure
It’s a misconception to think that backend developers just “churn out code”: the design decisions made in building the backend of an application shape the user experience indirectly and they matter as much as the front-end decisions. For example, think of the loading time of an application, how fast you can search the data, how seamless the user experience is in any location, etc.

Reliability, scalability, performance, and efficiency are aspects of an application that we take for granted most of the time, but it is painfully obvious when they are missing and something has gone wrong – i.e. when we make poor backend system design decisions.

The Artistry of Backend Engineers
Calling Backend Engineers “artists” seems to be an exaggeration until you realize the amount of creativity, intuition, adaptability, and problem solving needed to build the backend of a complex distributed system. Among the many possible approaches to achieve any given objective, the backend engineer needs to select the design that perfectly meets the requirements while also being able to gracefully evolve over time.

From a macro perspective, backend engineers need to evolve their approach based on industry-wide shifts in technology.

Think, for example, of how programming used to require writing code from scratch, line by line. Now it’s an assembly-like approach, where backend engineers need to meticulously select and combine components, libraries, and frameworks to create a complete system where each piece fits seamlessly.

Or, consider having to embrace new types of software architectures, programming paradigms, etc. to meet the requirements imposed with the shift toward distributed systems and cloud-native applications.

At the business level, they may need to craft designs that deliberately change over time (i.e. succession design and evolutionary architecture) because of known or unknown future product requirements. Or they may need to revisit their technology choices and evolve their tech stack choices to leverage new technologies (e.g. LLMs)

On a personal side note, throughout my years in tech I’ve met a large number of engineers who are also talented visual artists or musicians. While I couldn’t find any official study to corroborate this observation, I wouldn’t be surprised to learn that there is a correlation between being a great developer and being a great musician or artist.

It’s also worth pointing out that many engineers perform logical/functional design implicitly, without realizing it (for example when they break down a User Story). However, fully embracing the need for System Design and applying it in your daily work becomes a huge competitive advantage, even just for its ability to prevent technical debt -i.e. identifying “high-cohesion” areas and highlighting potentially “high-coupling” dependencies which should be avoided.

In the ever-evolving landscape of software development, the lines between the roles of ‘dev’ and ‘designer’ will only continue to get blurrier.