Don’t Forget the Developers

Software is meant to be, above all things, useful.

When we think about something useful we cannot help but think about the users (good thing we can’t). What if we were to build the best application ever but no one ever used it? So much for the usefulness of it, right?

"There are multiple kinds of users implicated on a single software solution, we know that. But we often forget that developers are users of the system too."

Don’t forget the developers.

A faster and better work can be done if we get into this mindset: We have to think about developers just as much as we think about our customers.

"We have to think about developers just as much as we think about our customers."

We developers are users of a system because we interact with it, and just like any other user we have to understand it, and be able to use it.

So, if we are going to consider that developers are just another kind of users, shouldn’t we try to improve the experience they have when interacting with our system? Shouldn’t we try to build a Developer Experience too?

Building the Developer Experience. What is this?

User Experience (UX) is about improving the interactions that users have with our system, making them more understandable, intuitive, fun, seamless, etc. Developer Experience is about the same things, but applied to this another kind of user, the developer.

To improve the User Experience we focus mainly on the interface between the user and the system. So, if we would like to improve the interactions of this narrower group of users, the developers, we would have to answer this question:

Almost every task developers do implicate coding (at least when they are in that role). Improving the system, understanding it, modifying it, are all actions that developers do through code. If we want to improve the experience they have, we have to improve the quality of this code.

I find that different principles from the UX world can be applied to make the Developer Experience (or may we say DX?) a better one. Let’s take some principles from this field, and try to apply them to the work developers do.

Less words

The end user. Most people don’t read the contents of a page, they scan it to find the information they are looking for. 
Steve Krug has made this clear in his book Don’t Make me Think:

“When we’re creating sites, we act as though people are going to pore over each page, reading all of our carefully crafted text, figuring out how we’ve organized things, and weighing their options before deciding which link to click. (…). We’re thinking ‘great literature’, while the user’s reality is much closer to ‘billboard going by at 60 miles an hour’”

The book then goes in depth about why people do this, it is a good read. But to the purpose of this point, let’s focus on the fact that if your content is too lengthy, or if it lacks structure, most users won’t read it completely. And this often means that they will fail to understand the message the page is trying to convey. That’s why the (simplified) advice in this subject is to keep things short.

The developers. It’s a lot harder to find the implicated piece of code for a given requirement in a large file or method than in a shorter one. Besides, too many words can be overwhelming. This can lead to poor understanding of code, which will likely lead to bugs. Try to keep things simple, writing small, cohesive components with defined responsibilities.

"Try to keep things simple, writing small, cohesive, components with defined responsibilities."

Additionally, cohesive components mean cohesive tests. These are also easier to read, understand and maintain than large tests. Tests play an important role in the comprehension of code because they are the most up to date documentation about what the component being tested does, without having to worry much about the how.

Respect conventions

The end user. People rely on certain things to behave the same way in every site they visit. For example, we all expect that by clicking the logo in the left upper corner of a web application, we will be lead to the home page. Not respecting this conventions leads to frustration and, on the contrary, doing so, makes the user feel in control and secure about what’s happening.

The developers. If you are using a framework, respect its conventions. Just as the end users expect certain functionality to work in a certain way, developers familiarized with the framework you are using, will have assumptions about how it is supposed to be used, based on their past experience and the information available online.

"If you are using a framework, respect its conventions."

Even when arriving from other projects, they will understand the code more easily if the framework in question is being used the way it was designed to. Another advantage of following this advice, is that it will be easier for someone new in the project to find help online.

The analogy can be extended beyond frameworks, we could even say that language conventions should be respected too. For example, in most object oriented programming languages, classes begin with an up-case, not doing so would be at least confusing. Another example: in Ruby, a question mark at the end of the method name, indicates that the method will return a boolean value. This is just a convention, a weak contract, but by respecting it you are one step closer to a more expressive and predictable code.

Be consistent

The end user. It’s good advice to avoid inconsistency in your platform. For example, if notifications are shown in the upper right corner of the screen, it would be a bad idea to make them occasionally pop from the left bottom corner.

The developers. Similar problems have to be dealt with in similar ways. Do you need access to a database? Maybe you have the freedom to choose between different patterns to access it (e.g. Data Mapper or the Active Record pattern)?—?pick one and stick to it. Are you using promises to deal with asynchronous code? Don’t mix them with continuations, by using sometimes promises, and other times continuations.

These are just some (maybe obvious) examples. What I’m trying to say is that if a certain problem has already been solved, it is expected that when it arises again, a similar decision is taken.

Sure, there might be a time when you are between styles, and that’s an awkward place to be. But in an ideal world, solving a problem that has already been solved, should be a no brainer. No one working on a mature software should waste their time figuring out whether to use promises or continuations. Nor should anyone have a hard time figuring out where the code to persist a certain model is. That time is better spent focusing on solving new stuff.

Don’t do crazy

The end user. CSS animations are great. They can play an important role in the usability of a site. But unnecessary animations can get in the way of doing things.

The developers. Over-designing is like over-using CSS animations. Keep things simple.

This is a tricky advice because simplicity is so subjective. We could spend hours talking about what simplicity means and never get anywhere. Maybe the most naive approach to simplicity I can think of is the following:

"Try to explain the decisions you took when designing a solution, and if no substantial benefit can be drawn from it, then that design is not simple enough."

Conclusion: Go the extra mile

Building software in collaboration with others can be especially challenging. The reality is that sometimes is difficult to merge coding styles, and it can be difficult to understand something someone else wrote. Moreover, some aspects of software quality, such as simplicity, are hard to measure in an objective way.

I think that humbleness is essential to keep the project best interests in mind. Going the extra mile can mean trying hard to understand someone else’s code, asking for help, or being receptive to peer reviews about our work, pride aside.

Either way, we all want to keep building great stuff. Let’s not forget the developers along the way, and we’ll be able to do this work we love — and keep loving it.

Special thanks to Ariel Umansky for helping me with the edition of this post, for always encouraging me to do my best, and for coming up with the term ‘DX’, I think it’s pretty catchy.

Thanks to Tomás Duhourq for the early feedback on this post.

And thanks to Graeme Fulton for helping me take this post to the next level.