I am a designer who happens to use code

There are many ways to look at programming. Some people do it to make a living. Others want to see things working fast and hack it away. Others believe in building a profession from programming and thus seek practices and submit themselves to challenges that expand their views.

It’s very easy to pass judgement on some of these attitudes. I will not do that.  People need to live, to support their families, to feel good while working. If anything, we should be happy that we, programmers, have opportunities other people don’t.

Instead, I will present my view on programming. A view shaped by a 40 years love story and a few key events. A view that I feel is shared by a very small minority of the community. I am encouraged to present this view by tweets from the recent DDD Europe conference.

Here’s my view:

I am a designer who happens to use code

Learning from other designers

I am a designer because I build upon the tradition, the practices, the techniques and the principles of design, a discipline that’s thousands of years old. I do this by reading, analysing and adapting techniques used by other designers.

The area that I studied the most until now was UX. Along with a group of interested people, we worked on understanding and adapting UX to software design. We realized that one of the main users of software design, the programmer, is rarely taken into account when designing software. And we built a set of principles and techniques called Usable Software Design.

But there’s so much more to study, so much more to analyse and so much more to try and adapt.

For example, Antoni Gaudí’s way of working. The famous architect used innovative techniques, and favoured an architectural style called “naturalistic design” because it resembles nature. Software design also evolves in an organic style, due to the human and social factors that are involved. Comparing software and trees evolution for example might lead to interesting insights. Could we benefit from fractals into our designs, to make them infinitely expandable?

On the other side of the spectrum, IKEA and LEGO show how to build complex and sometimes custom solutions from clear, standard modules. I know that this comparison comes up from time to time, but we’re far from realizing its potential – or proving it doesn’t work.

There’s also the potential to approach software design from a completely different perspective. Generative techniques for design could be developed, fundamentally changing the way we produce software. For example, encoding the changes in behaviour and / or in code, instead of encoding the actual behaviour, like we’re doing now.

One last example. Just analysing the general principles of design and trying to apply them to code leads us to interesting ideas. Minimizing the distance between where we are and where we want to go is one such principle, which translates in software design in navigability and in changeability (same principle, applied on the time axis). Grouping related elements is a core principle in UX and UI design, and corresponds to the software design principle of high cohesion. But there’s one question that bugs me: what does white space from UI design translate into software design? Music has silence, text has paragraphs. What is the equivalent in code?

I could go on, but I think I have made my point. Building upon principles, practices and techniques from other design disciplines can only enrich our view of software design.

Design as a humanistic activity

We consider too often programming as a technical type of work. I believe programming has a strong humanistic side.

I’ve been a humanist my whole life. I always felt the need to see my fellow programmers feel better at their jobs. I empathise with users, and feel bad when something happens that annoys them or blocks them from doing their work.

In the end, all software products are used by people. Those people deserve a product that helps them, that makes their life easier.

The code is also used by people. Those people deserve a code base that allows them to like their work, instead of generating countless WTFs per minute.

All designers know that design is a humanistic activity. All except most of the people who design code. We’ve created a wall between us and the rest of the design world. We often diminish the other designers work and joke about it. To me, that’s just a sign we don’t understand yet our own work.

I decided to break this wall. I learned graphical design, UI design, UX design and marketing (which is mostly design). It’s the right thing to do, because it’s the thing that helps most people.

Design as a multidisciplinary activity

I was always fascinated by people like Leonardo da Vinci, who could paint, engineer, design, write and build things. I wanted to be like them.

Design involves many disciplines. It involves understanding people’s needs and behaviours. It involves aesthetics. It involves mastering techniques and crafts. It involves problem solving, critical thinking, risk management. It involves communicating through diagrams, text and models.

So I read books on psychology, philosophy, technical topics, cognitive biology, project management, risk management, communication. I practised and continue practising writing, sketching, coding, facilitating.

And I know it never ends. I will do this for as long as I can. Not only because it helps me, but also because it’s fascinating.

Closing

I tried in this article to give a glimpse of what it means to be a designer first and a programmer second. I will continue on this road, despite the feeling that I’m part of a very small minority.

I discussed extensively ways in which other design disciplines help me and guide me in my path. This does not exclude however building upon the principles, practices and techniques of software designers who created before us. In this industry we forget too quickly the lessons of the previous generation, and keep making the same mistakes. I have hope that the software craftsmanship movement will eventually fix this problem by creating a clear definition of our profession.

It’s important to read this article as in “how Alex thinks and does programming” and not  “Alex said this is the only right way to do things”.  My hope is that you will take something useful out of it. Maybe the drive to read more. Maybe a wider view on programming. Maybe an idea that will sparkle the next time you go to IKEA or play with LEGO.

I am applying these techniques and this way of thinking in the development of eventrix.co. The best description of my job in any other field would be designer, as in: helping structure the design elements that we use in UI, UX and code, with the help of a team. I’m certain this experience will teach me much more about these topics. If you’re interested, let me know!