Code for the Users, Not for the Spec
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 creatinga-aand 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 aono.a 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 aono,a 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 itemsa-athere 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 boarda-aand 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 aofaster horsesa 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
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&
Truncated by Planet PHP, read more at the original (another 2840 bytes)