Photo by Photoholgic on Unsplash
3 min read
I’ve read an article in Time magazine about Bill Gates finally getting his degree after 30 years. Say what you will about Bill, but the man must’ve done something right. One interesting paragraph that struck me as very interesting was the following:
For all his drive and intelligence, Gates doesn’t see things with an artist’s eye for those human intangibles. In May, Gates made a rare and instructive public appearance with his longtime frenemy Steve Jobs. An audience member asked each of them what he had learned from the other. "Well, I’d give a lot to have Steve’s taste," Gates said. "You know, we sat in Mac product reviews where there were questions about software choices, how things would be done, that I viewed as an engineering question. That’s just how my mind works. And I’d see Steve make the decision based on a sense of people and product that is even hard for me to explain. The way he does things is just different, and you know, I think it’s magical." The audience cracked up. But Gates wasn’t joking.
This got me thinking that most of us in the IT industry always take to user problems from an engineering viewpoint and hardly ever from the human/user viewpoint. This more often than not leads to frustrated users. For example, I wrote an ACCPAC customization a few years ago, that the users still use today.
Almost 3 years later I’m back looking at a rare but very frustrating bug with this application. In very specific scenarios, the app loses some of its logic, overwriting values and then refusing to post and order. The result is the user having to recapture the order and to make things worse this almost always happens on big orders.
Even though this is a rare occurrence, when it happens it causes a lot of frustration….Now, from an IT perspective, what will the developer do?
- There is a work around so no big rush to fix it.
- Fix it, sort of, just to make the client happy for now.
- Sit with the user that has to try and get the order posted, feel their pain, even help getting it done…and then after a good understanding of the problem and the frustration it causes, fix it and test it thoroughly.
The point I’m trying to make is, that we as developers, must start to understand the implications of our work. It’s not the data that will be wrong or orders not completed on time. It will be the people having to do these tasks that will suffer.
Think of it as Code Karma, do good coding and good things will come of it.
You will at least not be the reason a poor clerk has to work late yet again.