Published on <a href="http://ift.tt/2n91OKL">| Prototyping: From UX to Front End &mdash; Medium</a> Aldana L Quintana Munilla 
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 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. But the way we do this is through code, and if we want to improve the Developer Experience, we have to improve the quality of it.
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 the this field, and try to apply them to the work developers do.
<h3>Less words</h3>
The end user. Most people don’t read the contents of a page, they scan it to find the information they are looking for. If your content is too lengthy, or if it lacks structure, most of them might 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, <a href="http://ift.tt/1HjUXlz">cohesive</a> 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.
<h3>Respect conventions</h3>
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.
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.
<h3>Be consistent</h3>
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 whether to use Data Mapper or the Active Record pattern, pick one and stick to it. Are you using promises? Don’t mix them with CPS, 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.
<h3>Don’t do crazy</h3>
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. <a href="http://ift.tt/155bOC7">Keep things simple</a>.
This is a tricky advice because simplicity is so subjective. We could be 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.
<h3>Go the extra mile</h3>
Building software in collaboration with others can be specially 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 <a href="http://ift.tt/2n91xre">Ariel Umansky</a> 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.
I also want to thank <a href="http://ift.tt/2nDFTrG">Tomás Duhourq</a> for the early feedback on this post.
<img src="http://ift.tt/2n93q79" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2nDGvh6">Don’t forget the developers</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Don’t forget the developers

Top Stories