{"id":8412,"date":"2017-04-12T11:49:37","date_gmt":"2017-04-12T10:49:37","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=8412"},"modified":"2017-04-12T11:53:42","modified_gmt":"2017-04-12T10:53:42","slug":"dont-forget-developers","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/dont-forget-developers\/","title":{"rendered":"Don’t Forget the Developers"},"content":{"rendered":"

Software is meant to be, above all things, useful.<\/p>\n

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

\"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.\"<\/span><\/p>\n

Don\u2019t forget the developers.<\/p>\n

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.<\/em><\/p>\n

<\/div>
<\/svg><\/div>

\"We have to think about developers just as much as we think about our customers.\"<\/p><\/span><\/blockquote>\n

We developers are users of a system because we interact<\/em> with it, and just like any other user we have to understand it, <\/em>and be able to use it.<\/em><\/p>\n

So, if we are going to consider that developers are just another kind of users, shouldn\u2019t we try to improve the experience they have when interacting with our system? Shouldn\u2019t we try to build a Developer Experience too?<\/strong><\/p>\n

Building the Developer Experience. What is this?<\/strong><\/p>\n

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.<\/p>\n

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:<\/p>\n

<\/p>\n

How do developers interact with the system? What is the interface between the two of them? It\u2019s code.<\/p>\n

<\/strong><\/p>\n

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.<\/p>\n

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\u2019s take some principles from this field, and try to apply them to the work developers do.<\/p>\n

Less words<\/h2>\n

The end user.<\/strong> Most people don\u2019t read the contents of a page, they scan it to find the information they are looking for.\u00a0
Steve Krug has made this clear in his book Don\u2019t Make me Think<\/a>:<\/p>\n

\u201cWhen we\u2019re 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\u2019ve organized things, and weighing their options before deciding which link to click. (\u2026). We\u2019re thinking \u2018great literature\u2019, while the user\u2019s reality is much closer to \u2018billboard going by at 60 miles an hour\u2019\u201d<\/span><\/p>\n

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

The developers.<\/strong> It\u2019s 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<\/a> components with defined responsibilities.<\/p>\n

<\/div>
<\/svg><\/div>

\"Try to keep things simple, writing small, cohesive, components with defined responsibilities.\"<\/p><\/span><\/blockquote>\n

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<\/em> the component being tested does, without having to worry much about the how<\/em>.<\/p>\n

Respect conventions<\/h2>\n

The end user.<\/strong> 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\u2019s happening.<\/p>\n

The developers.<\/strong> 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.<\/p>\n

<\/div>
<\/svg><\/div>

\"If you are using a framework, respect its conventions.\"<\/p><\/span><\/blockquote>\n

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.<\/p>\n

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.<\/p>\n

Be consistent<\/h2>\n

The end user.<\/strong> It\u2019s 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.<\/p>\n

The developers.<\/strong> 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)?\u2014?pick one and stick to it. Are you using promises to deal with asynchronous code? Don\u2019t mix them with continuations<\/a>, by using sometimes promises, and other times continuations.<\/p>\n

These are just some (maybe obvious) examples. What I\u2019m 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.<\/span><\/p>\n

Sure, there might be a time when you are between styles, and that\u2019s 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.<\/p>\n

Don\u2019t do\u00a0crazy<\/h2>\n

The end user.<\/strong> 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.<\/p>\n

The developers. <\/strong>Over-designing is like over-using CSS animations. Keep things simple<\/a>.<\/p>\n

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: <\/p>\n

\"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.\"<\/span><\/p>\n

Conclusion: Go the extra\u00a0mile<\/h2>\n

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.<\/p>\n

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\u2019s code, asking for help, or being receptive to peer reviews about our work, pride aside.<\/p>\n

Either way, we all want to keep building great stuff. Let\u2019s not forget the developers along the way, and we\u2019ll be able to do this work we love \u2014 and keep loving it.<\/p>\n

Special thanks to <\/em>Ariel Umansky<\/em><\/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 \u2018DX\u2019, I think it\u2019s pretty catchy.<\/em><\/p>\n

Thanks to <\/em>Tom\u00e1s Duhourq<\/em><\/a> for the early feedback on this post.<\/em><\/p>\n

And thanks to <\/em>Graeme Fulton<\/em><\/a> for helping me take this post to the next level.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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\u2019t). 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… Read More ￫<\/a><\/p>\n","protected":false},"author":120,"featured_media":8420,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-8412","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-viewpoint"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n