I’ve heard this re-framed again and again by many different programmers from @wycats at Ruby conf to @dhh in his parlay letter:

I consider this [the ease of getting started], like maintainability, to be a side effect of good, simple design.

I think this is a great way of looking at the “beginner” problem, but it doesn’t give much guidance. What exactly is good design for advanced developers? Why is it also good for beginners? Who counts as a beginner? Is a .NET dev with 5 years of industry experience learning rails lumped into the same category as a someone who had never previously viewed-source on a webpage?

In the Beginning

Let’s take it back a bit, to the era before one click purchases, and github signup buttons. The realm was ruled by the textbox and it’s mighty accomplices radio buttons, text areas, and submit buttons. Signing up for a new web app was a lesson in finger cramps. Eventually some people were clever enough to figure out that fewer fields meant fewer interactions, and less fatigue. This of course lead to fewer people dropping off and higher sign-up numbers. Good for the business, who now has more users. Good for you, who now has to type. In the end all they needed was a password and an email, the rest was just details.

What do web forms have to do with advanced programming? Everything. It doesn’t matter if you were browsing the BBS on a 28.8k or you just got your first taste of the Internet over AOL, you had to go through the same interaction. Experience was irrelevant. There was no “click here if you understand the internet” signup option. So when the pain of signing up for many many services by the elite trickled down to help the newbs signing up for their first service: every won.

Anectdotes aside, this is how coding for interaction should be. Build for the pros, don’t forget the nos. What can we as developers take away from the signup form? Treat each user interaction as a barrier to entry and productivity, slash cut and simplify until you can’t be simpler, and treat the interface as a tool to reduce activation energy.

PROTIP: Look for heavy process and cut it down to size

Sometimes the simplicity can come from an internal structure, let’s take a look at how re-thinking how routes are groked led us to a more productive programmer and eventually a smarter “beginner”.

Simplicity in Action: Sextant

A Sextant is an ancient tool for finding your route via the stars. My program Sextant is a tool for finding your rails routes via your browser. I started the project to save me from the pain of rake routes to slash my waiting time (counted in agonies per command, of course) from 20 to 0.

What started as a simple tool for saving time has since ballooned into a new way to visualize and think about a core part of our Rails coding experience, with over 39 thousand downloads. The key to it’s success was identifying that extra step that wasn’t needed, the boot time of the rails app. Now that sextant is shipping with Rails 4 we can start the process over again. What else isn’t needed, or what is missing?

The Evolution of an Interface

Once we got the routes into the browser we’ve now got a powerful set of interaction tools to work with, namely html and javascript. I was able to clean up the visuals of the routes a bit, but it always bothers me when the computer knows the answer to something and yet makes me do the work. Named routes which are a commonly used element in the views, are listed not as they are intended to be used, but instead only have their prefixes in the output. So instead of new_users_path I’ll often type new_users into a view by accident when I’m tired or distracted. When I hit refresh the page I see my problem, I forgot to do my mental math and add the _path suffix. When you’re already tired, already frustrated, just trying to ship a feature these seemingly small hoops to jump through grow ever larger with each mistake made. Why not remove them entirely?

The solution is to add this info into the view by displaying the full named route helper:

I think this is great. But why, what makes this a good idea?

'Don't make me think'

Rails is famously convention over configuration. This saves you, the developer, countless hours debating where to put your files or and what to name your folders. While this eliminating these extra steps is a great thing, something can get lost in the translation:

The first thing this current class of students asked me is “Where can I find the document that describes all of the Rails conventions.” - @steveklabnik

As you’re removing steps, if you miss some, then you’re secretly adding a hidden step to Google for for awhile. This Google tax only comes to: the new, the uninformed, the tired, and the overworked programmer trying to ship at the last minute. It’s easy to forget once you know the missing step by heart. This is why being explicit with route helpers in Sextant makes an impact. We took the hidden step “add _path to the end of these” and made it explicit without losing any information (you can still see that _url is an option):

PROTIP: Mental math leads to errors, where can we be more specific?

While you’re refining and iterating and slashing steps, don’t forget to keep context front and center. If you’re looking for places where you might need better docs, or more accessible information. I recommend you keep a …

Cheat Sheet

I use Evernote to keep track of the text snippets and docs links I end up finding useful. Not only does it help to organize my thoughts while I’m having issues, I can search it later if I run into the same problem, and even better when I’m bored or looking for something to productively procrastinate with, these notes are great places to see if we could add more docs, take away steps, or remove some mental math.

Design for All

If I can make my interface so simple it only needs one step, maybe one day we can eliminate the need entirely. This is exactly how automation is born and thrives. While it’s obvious saving developer time is a good thing, why had no one done this before, and how can you build better software for all levels?

  • Keep a cheat sheet
  • Look for duplicate or un-needed steps
  • Look for long complicated processes
  • Look for missing docs or implied information

Get up and make a difference, work with more beginners, contribute to open source and help close the gaps.

Richard “@schneems" (pronounced like Schnapps) Schneeman writes Ruby code for @heroku and teaches Rails at the University of Texas.