Who are We Coding for?
(The below is an account based on facts, but the details are modified to protect the innocent.)
It was a while back. My team at work had started on a new project, and many of us were excited about being able to try out the latest frameworks and tools available. Myself, I was busy with another project at the time, so it took me more than a month before I was finally freed to join the team on this latest project.
And when the module I was working on required the rendering of currency on the frontend, naturally I wanted to find out what the team had decided would be the default currency format (say, USD or $US or simply $). So I went to a colleague, and he shrugged:
“Don’t know. I don’t think we have a standard yet. I’m using USD, but I think someone else used $.”
“You mean you didn’t discuss this?!”
Nope, was his answer.
I was shocked not because the frontend team didn’t decide on the default currency format from the start or they hadn’t had any discussions on the matter—it’s not a big deal and relatively trivial to change them at a later stage. I was shocked because the team had, on chat and mail and in physical meetings, had plenty of discussions about which framework plugins to use, on which Eslint and SCSS lint rules to include, and on which ES6 transpiler to use, but they had failed to have a single discussion on the default currency format to use.
Putting the Cart before the Horse?
This is not the first time I’ve seen something similar happened. I’ve seen this kind of thing happened with another team at another job, so this is likely not unique to one engineering team.
It seems to me that with all the complexities of the tools we use on frontend web development (not sure about the backend) and the enthusiasm we have towards the latest tools and best practices, we have all but forgotten our priorities. We need to remember that we’re not building software for ourselves, we’re building software for our users. Our first priority, when it comes to coding, should be to solve problems for the users, before solving problems for ourselves.
We’re not building software for ourselves, we’re building software for our users.
I understand the need to have a consistent coding style, to simplify merge conflicts and reduce potential bugs. I also understand the need to choose the right framework/plugin, because the right framework/plugin can make us more efficient and/or encourage better coding practices.
But all these decisions we make are for ourselves, not our users.
And when we bury ourselves in such details without first looking into the needs of the users, we’re effectively saying we’re more important than the users. Taking the above example, shouldn’t we make sure we’ve discussed and decided on the best currency format and keep that consistent throughout the software first, then worry about the Eslint rules? I’d think it’s completely acceptable to ship a software whose code is poorly formatted and has inconsistent coding styles, yet takes into consideration all the user-facing details. But the opposite is completely unacceptable if you ask me. If the user sees USD on page one and $ on page two, she will be confused, much more than if a programmer finds it hard to find the source of a bug in the source code. (In any case, we’re paid to deal with such confusions, no?)
You may argue that both decisions are important and that it’s not a question of either or. But if we take care of the users’ needs before our needs, then in the unfortunate event that we are running out of time on the project and we have to let go of some features or concerns before shipping, we would have taken care of the users’ front, and we can rest assure that the app works perfectly fine from the users’ perspective, even if we didn’t have the time to prevent the code from looking unkempt or to use the latest, most exciting libraries.
Some Things Don’t Change.
Of course, if we think about it, this is not a new problem unique to software development. Even in the older days, I’d imagine company employees making decisions in order to look good before their bosses, even if the decisions don’t necessarily benefit—in fact, sometimes even hurt their customers. This is because these employees see before their eyes the person who gives them their monthly paychecks and decide, perhaps not unreasonably, that the boss comes before the customer.
A gross misconception, obviously. Because the boss won’t have a business anymore if the customers are pissed and they stop paying for the company’s goods and services. And when that happens, the boss won’t have paychecks for the employees. It will probably be too late for the employees to realize that though. And of course, the boss who condones such behavior is clearly at fault as well. But then I guess it’s hard to make the right decisions sometimes because of the egos and fears lurking behind them. And that kind of thing never, ever changes.
It’s All Perspectives.
At the end of the day, I suppose, it’s all a matter of perspective. To some, the company and industry matter more than the customers because they relate directly with their livelihoods—more directly than the paying customers. Some may also think that elevating the standard of the industry translates to better customer experience, which makes sense too. Others, like myself, believe that making sure the customers are well served is more important than company politics and industry standards.
I am not naive enough to believe that everyone will agree with me, neither do I think my perspective is irrevocably right. I do think, however, that one should find himself in a team that share the same perspective/goals, where possible. A team whose overriding goal is to make sure the users enjoy a good user experience is bound to do things differently from a team whose goal is to make the best use of cutting edge technologies. I found, for example, that when the general concern is that of better tools and coding practices, it’s harder to remind the team that coding while thinking for the user is just as important.
As the industry matures, I do hope that the current obsession with cutting edge tools will fade in prevalence. While understanding industry trends is always important, it is unhealthy and—as I’ve suggested above—not always in the best interests of our end users to think of tools and frameworks as the silver bullet in development, as many of us do. At the end of the day, it’s not the tools that make a good product, but the willingness to think from the perspectives of end users.
At least that’s what I believe.