How to Get Started Designing for Developers

4 things you have to know

Tim Sheiner
Dec 31, 2019 · 8 min read
Man and woman working with IBM type 704 electronic data processing machine.
Man and woman working with IBM type 704 electronic data processing machine.
State of the art developer experience (DX) design circa 1957

So, you want to design developer experiences?

Awesome! Your timing is great. The employment picture is bright for folks who know how to create products for programmatic or declarative developers. Your first step is to develop empathy for these people by learning what it is like to spend your working life inside a computer.

Inside a computer is an odd place. Everything is literal, nothing is implied. A thousand words are worth more than a picture and being creative means following strict rules perfectly. Not only this but actually getting stuff done means working alone, staring at a screen, while at the very same time actively collaborating with other developers who are themselves working alone, staring at a screen!

Bottom line is that the only way to understand this way of working is to experience it personally— at least a little bit. I’ve mentored a few non-technical designers through this learning process and what I am sharing in this post is a roadmap I’ve worked out for getting there in the shortest amount of time possible.

Now, don’t expect magic; working through this 4 step plan will take you at least a day, probably more like two. However, your return on this investment will be high: you’ll get a feel for how it is to work as a developer and insight about what these people expect from their tools.


1. Programming Model

A critical epiphany to understanding developers is understanding that they are actually writers. They spend their day in a text editor, turning ideas into symbols, words, and expressions, just as does a novelist, screenwriter or poet. The difference, of course, is that instead of a book, movie or poem, the developer’s output is code: the hyper-literal instructions a computer can read.

The grammar of code is made up of concepts that are consistent across all programming languages:

  • values & variables
  • operators & statements
  • objects & arrays
  • loops & functions

You have to understand this programming model because it is central to how developers think.

I recommend you learn this model by reading the introduction and the first four chapters of Eloquent Javascript by Marijn Haverbeke. The book is available online for free but my preference is the nicely made print version.

This book will teach you the programming concepts that are part of every developer’s experience, but only if read the chapters and play with the code. Do this using the inline code editors or the associated interactive playground.

The going gets rougher after chapter 4; you can worry about the later material some other time. ;-)

Excercise 3.1 from Eloquent Javascript in Haverbeke’s online sandbox environment
Excercise 3.1 from Eloquent Javascript in Haverbeke’s online sandbox environment
Exercise 3.1 from Eloquent Javascript in Haverbeke’s online sandbox environment
Exercise 3.1 from Eloquent Javascript in VSCode with Code Runner extension on Mac with Node installed.
Exercise 3.1 from Eloquent Javascript in VSCode with Code Runner extension on Mac with Node installed.
GET YOUR NERD ON: Exercise 3.1 from Eloquent Javascript in VSCode on Mac with Code Runner extension and Node installed.

2. UNIX

UNIX is a computer operating system invented at Bell Labs fifty years ago that remains central to computing today and for the foreseeable future. The relevance to you is that UNIX is — by a large margin — the most common environment in which professional coders operate.

UNIX is incredibly broad and stunningly complex. But don’t worry, all you need to know is how to talk to it and navigate around in it using a command-line interface (CLI).

On a Mac, you get a CLI for talking to UNIX just by opening the Terminal application. PC users have to work harder: first, install some kind of UNIX distribution like this one, and then a terminal emulator like this one.

I like to think about the terminal experience as a kind of chat — similar to Slack, iMessage or Whatsapp — except that I’m chatting with a machine instead of a person. And, just like with any group chat you are on, you have to use a special kind of slang. The best way to learn how to do this is by reading the short and sweet Learning the UNIX Operating System. I honestly believe this will turn out to be some of the most interesting two or three hours you will ever spend in front of a computer!

Once you’ve got a basic familiarity with the command line, you need to practice with it. A good habit is to use a terminal to do the kind of file management task you’d usually do with the Mac Finder or the Windows File Explorer.

Mac Finder app showing files on a computer desktop
Mac Finder app showing files on a computer desktop
Mac Finder app showing folders & files on a computer desktop
Mac Terminal app running tcsh shell showing files on computer desktop
Mac Terminal app running tcsh shell showing files on computer desktop
Terminal app running tcsh shell showing same folders & files on same Mac desktop

3. Git

Another great way to practice speaking command line is to use Git, the version control system developers rely upon to enable that odd way of working that involves being alone and collaborating at the same time.

Git was invented by Linus Torvalds, the same genius who made open-source possible by giving the world LINUX, a free version of the UNIX operating system.

Because developers spend time in Git (or something similar) every single day, being comfortable joining them there has a huge upside for growing your understanding of their experience. The downside is that Git has a very steep learning curve. You can get started with this gentle introduction but getting comfortable with Git means time in the saddle using it to manage files that actually matter to you. If you can, use it on a real project with your developer partners, but if that’s not available to you then fake it by:

  1. running Git locally (for Mac users Git is there by default, Windows people will need to install it),
  2. getting a Github account,
  3. making a repository for your design files,
  4. backing up your work locally and to the remote throughout your workday.

This not only gives you an online back up for your work — always a good thing— it will also get you comfortable with Git, Github and the difference between them.

Be patient. Git is complicated to learn because it is solving a very hard problem very thoroughly. When you get stuck, and you will, ask a developer for help. Everyone who uses Git has been stuck plenty of times and will be happy to help.

Finally — friendly reminder — use Git from a CLI, not a GUI. That’s what developers do, so you should too.

Github repository I use to back up my home improvement drawings
Github repository I use to back up my home improvement drawings
Github repository I use to back up my home improvement drawings
Git command line view of local version of same House-dwgs repoGit command line view of local version of same House-dwgs repo
Git command line view of local version of same House-dwgs repoGit command line view of local version of same House-dwgs repo
Git command line view of a local version of same House-dwgs repo
Mac Finder view of the same local version of same House-dwgs repo
Mac Finder view of the same local version of same House-dwgs repo
Mac Finder view of the same local version of same House-dwgs repo

4. Developer Workflows

The Programming Model, UNIX, & Git are the three systems that underlie the modern developer experience.

This experience also has 3 essential workflows:

  1. Programming
  2. Debugging
  3. Deployment

Understanding the programming workflow is easy for a designer because it is just a coding-specific version of the creative process you already know: make-test-iterate.

As far as the deployment workflow goes, all you need to understand to get started with DX design is the taste of it you get from grasping the local-remote concept in Git.

That leaves the debugging workflow, which you do need to pay special attention to for one simple reason:

This is so because of how super awful it feels to be stuck with a bad debugging experience. Let’s do a quick exercise to help you understand this pain: first, call to mind a time when you got so angry with your computer that you had to shout out loud. Got a memory of how that feels? OK, now imagine having (and having to work through) that feeling daily, maybe even several times a day. Tough right? Now, the last thing, imagine having that feeling while working against a deadline with your team not only counting on you to get done, but themselves stuck, dead in the water until you do. Yuck.

Unfortunately, every developer has to deal with this experience from time to time; it’s just part of the job. The point you need to internalize here is that even though developers accept this pain, they will value absolutely everything you can do to make those frustrating debugging experiences happen a little less frequently and feel a little less awful.

Doing this well is a hard design problem. I’ve got no magic bullet reference to share for how to design great debugging experiences, but I do have a framework for thinking about the problem that I find very helpful: design time vs run time.

Design time refers to whenever the developer is writing instructions that are being saved (explicitly or implicitly) as one or more static text files. Eliminating errors at this stage produces huge time savings later so a great design time debugging experience prevents bugs from happening in the first place. Standard design patterns here include syntax highlighting, autocomplete, linting, and validation.

Run time, on the other hand, refers to whenever the computer is running the code and executing the instructions for transforming inputs into outputs. Because this process is invisible to the naked eye, a great run time debugging experience helps a developer notice, find, understand and fix the bugs already in the code. There are two main standards. The first is the idea of test-driven development and the second is about exposing, as explicitly as possible, a step by step story of what the computer is doing as it runs the code.

Programmatic debugger showing method calls, call stack, breakpoint & unit test results
Programmatic debugger showing method calls, call stack, breakpoint & unit test results
Programmatic debugger showing the code, a breakpoint, method calls, call stack & unit test results
Declarative debugger showing control flow, acceptance test results & test log
Declarative debugger showing control flow, acceptance test results & test log
Declarative debugger showing control flow, acceptance test results & test log

Know Enough to Ask Questions

OK, that’s a wrap, all you need to know to get started designing developer experiences.

You might be thinking, hold on Tim, all you’ve done here is point me at four topics that are each, separately, on their own, a ton of stuff to learn. That’s true but what I’ve found as a DX designer is that I don’t need to be an expert in any of these things, I just need to know enough to be able to ask questions about them. Because — end of the day — asking developers questions about their work, and their tools, is what really teaches you how to be great at designing developer experiences.


Follow us at @SalesforceUX.
Want to work with us? Contact
uxcareers@salesforce.com
Check out the
Salesforce Lightning Design System

Salesforce Experience and Design

A collection of stories, case studies, and ideas from Salesforce design teams

Tim Sheiner

Written by

System thinker, story teller, designer, husband, father of 3, San Franciscan, Bernal Heights neighbor

Salesforce Experience and Design

A collection of stories, case studies, and ideas from Salesforce design teams

More From Medium

More from Salesforce Experience and Design

More from Salesforce Experience and Design

More from Salesforce Experience and Design

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade