If you want to be a better programmer, join your users for a day.
Or, put another way, spend time with the people who use the software you write. Learn what they do in the daily tasks, and pay attention. You’ll find things computers can’t analyze and users say — either they don’t notice, or they feel embarrassed or self-conscious.
Asking questions is the best way to get someone to tell you what they want. Most people don’t know what they want because they don’t ask themselves quality questions. You, as a programmer, are in a position to ask questions with the mind to build a better product — so you have the perspective of asking quality questions already.
While people can tell you what they want, there are other things to pay attention to. Among them are:
- What’s tedious?
- What’s annoying?
- What’s fun and enjoyable?
- What’s irritating?
- What’s time consuming?
- What’s wasting their time?
- What is inefficient in their process?
These questions can be answered by paying attention to the user’s response to their tasks. Notice their tone of voice, if they talk faster or slower, if they take more time or work quickly. These signs are subtle, but they do help to address solving all the little, built up problems, that may hinder a user’s productivity.
The purpose of developing software is to improve efficiency by reducing errors and time spent on work. We can write all the fancy code we want, make it as quick and sleek as possible… but if it does nothing to improve the work and lives of our users, then what good is it?
In nearly every job I’ve had, I’ve spent time around the other workers, to get a feel and understanding for what they’re doing. Sometimes my boss would tell me not to, but I did it anyway — and eventually they learned why. I’ve always been in a role to support others, either the customer directly, or the other workers. It was only natural that I knew what they did.
I worked at a dealership, as the dispatcher – the guy who sent jobs around the shop to the technicians. I was sure to make friends with the techs, and it worked: I transitioned an shop that had been around since the 1920’s, from using pen and paper, to using computers. All of that, and I was only 19.
I did it by spending time with the techs, and learning what was important to them. I spent time with the service advisers, and learned what was important to them. The lot attendants, the salespeople, the office support staff, the managers, and more. All the while asking questions, and observing their daily tasks. How many 19 yr olds do you know who could take a group of 30+, 50-60 yr old men, set in their ways, and get them to use computers for the first time, with their incomes on the line?
I continue this behavior, even today, with myself, and others. I seek out what is important to them, and observe their routines. Spending a day with the user helps me to understand what they want, and why they want it. It’s up to me to deliver it to them. And that, makes me, a better programmer.