I don’t know exactly when it was that I started to resent the people I was writing code for, but it was a sure sign that I was feeling burned out. For ten years, I’d been working as a development resource in design and marketing agencies, then at Yahoo, and finally within my own client-services company. At some point along the way, I’d lost touch with the people using the software I was creating — and it sucked.
One of the great joys of creating software is solving problems. Not just academically solving problems, but really fixing things for people. Making other people’s lives better by enabling them to achieve more with less. The satisfaction gained by having another human being pleased to be using what you’ve created is what makes it all worthwhile. If that feedback loop is broken, you end up releasing code into a void like a machine churning out functionality to spec.
One thing you quickly find when you’ve reduced your role simply to one of coding to spec is that your default position for any request is “no.” To keep the project on time, on budget, and to prevent treading water, you have to stand firm against what could be seen as unnecessary changes and stupid requests from users who don’t really know what they’re talking about. It’s tiring saying “no,” and resentment toward those asking the questions quickly builds up.
Before you know it, work is not fun like it used to be.
The solution is easy. Stop coding for the spec, and start coding for the users again.
Functionality Is Not Enough
I think we’ve probably all been in a situation where users ask for something that already exists. With our small CMS, Perch, users often asked for the ability to reorder content items.
Now, of course, it was already perfectly possible to reorder items — there were options to set the content to order on any field, and in either direction. If the user needed an arbitrary order, they could add a new field, add a number to their items, and order by that. On paper, it was quite a powerful and flexible system.
Yet, users were still asking for a way to order content. The functionality was there, but users were either not finding it, not understanding it, or both. The spec was met, but the functionality was failing the users.
Remember, the spec is a bare minimum requirement. To do a really great job, it’s sometimes necessary to go beyond what the spec says and make something that really works for the people who have to use it.
Accept When Users Are Having Trouble
A big part of this is learning to accept when working code is broken. Sometimes the wet problems are the most difficult to solve, and as with all wet problems, the first step to solving them is admitting you have a problem. As a developer, it’s a really tough lesson to learn that a perfectly functioning, bug-free feature is broken if users don’t understand it.
What you’ve developed may meet the spec’s requirements enough to get sign-off, but we’re not working for the spec anymore. How do we go about getting user sign-off?
Sometimes the issue can be resolved with better user messaging, or by rethinking the interface, but other times you just have to accept that users are having trouble, and you need to go back to the drawing board — and that’s okay. If what’s there doesn’t work for users, then it doesn’t work.
My number one recommendation in this situation is to simply listen to your users. Ask them what they’re trying to achieve. Much like Henry Ford’s debated “faster horses” quote, your users may come up with the wrong solutions, but their core requirement can often been distilled from those solutions. So ask them, and then listen carefully to the answer.
Really Great Developers Solve Problems
I went back to the drawing board with my content ordering and implemented a JavaScript drag and drop reordering interface. The core of what my users were asking for was a quick way to set an arbitrary content order. I’m not one to throw masses of JavaScript at every problem, but in this case, it seemed that drag and drop was a good way to achieve that goal.
Now, users can pick up a bit of content and easily drop it where they want it. Is the end result any different to the functionality we provided before? Absolutely not, but the process of getting there is more closely aligned to how users want to use the software.
Not only does this mean they’re not bugging me with requests for features that exist, it means that they’re able to achieve more with the software.
FAQs Are Bugs You Haven’t Fixed Yet
We have a policy of having no frequently asked questions. If users are asking about something with regularity, then it means we’re either not explaining things clearly, or the product can be improved.
With Perch, users needs to add their site’s domain and corresponding license key before they can log in to a new installation. If they missed all the instructions and failed to do so, they were presented with the following message:
“Sorry, your license key isn’t valid for this domain.”
While accurate, this message very rarely resulted in the user taking the correct course of action to resolve the problem. What they’d actually do is raise a support ticket saying that they couldn’t log in.
One way of addressing this would be to add an FAQ to our site that explains what to do when encountering the message. That would be a bandage on the wound — it would stem the bleeding but not alleviate the pain. The real solution was much simpler. We changed the error message:
“Sorry, your license key isn’t valid for this domain. Log into your Perch account and add the following as your live or testing domain: example.com”
With example.com being the domain the installation is running at. Following this simple change, nobody asks us this question anymore. I’m sure plenty of people still miss the setup instructions and see the error, but it’s no longer a problem for them — they just make the change and carry on without incident.
The very worst thing you can do with frequently asked questions is make a list of them on your web site. Frequently asked questions are bugs, and the only satisfactory answer to them is to fix the problem so the questions don’t get asked again.
Being a developer isn’t about providing tools; it’s about solving problems. If we want to enjoy what we do, make awesome things, and not feel burned out, then we need to find ways to solve problems that work really well for users. If you make great software, users will appreciate your work and you’ll feel proud about what you’ve achieved. That sounds like a good recipe for being happy in your work to me.
Developer Gift
Did you ever program a robotic turtle back in the 80s? Remember the fun of having code on the screen translate to movements of a physical device on the floor? Drawing lines on a big sheet of paper only has limited appeal, but there’s a grown-up equivalent with an open source electronics kit from Arduino. Give the gift of hardware hacking!
