We think you should test your code for not only function but performance. We’re not alone, and we loved this article we came across recently by Thiago Duarte. Called “7 Things I Learned That Made Me a Better Programmer,” Duarte tells some great stories and shares great tips.
While the whole article is worth a read, we liked his practical and wise insights. This insight was particularly affecting: “You’re not being paid to write code, but to solve real problems for real people.” In the never-ending churn that is software development, it’s easy to lose sight of the end goal (and easy to lose your work-life balance).
Keeping that maxim in mind, we felt it put his advice to “test obsessively” in perspective. We believe that testing isn’t something you do just to increase your build or performance metrics: instead, it’s a way to make sure your user experience is the best it can be.
Thus the title of this article, also taken from Duarte’s piece: “If you don’t test your software, your users will.” That’s sobering.
That’s the last set of people we want testing our software, right? I mean, it happens, but only after we’ve tested to the best of our abilities.
The “best of our abilities,” as Duarte puts in perspective, means that “no change is too small to need testing.” We believe, of course, that should mean not just the functional testing you’re likely to be doing already, but also the consistent and continuous performance testing you should be doing regularly as part of your build process.
Here’s the piece that we felt really put everything in the right place. Let’s say, hypothetically, that you’ve found an error in your testing, or a particularly painful performance slowdown. What’s the next step?
Of course, you’ll want to find out what’s causing the problem. But when you’re working with your team, peer, or manager to solve the problem, here’s some great advice from Duarte.
He suggests that when you’re trying to solve a problem - and it’s one with which you’ll need some help from a peer, manager or your team - you can be proactive about solving it. Be proactive by remembering that you’re not just there to alert everyone to the problem, but, instead, to bring solutions. Even if you’re not sure about the exact solution, you can “outline possible solutions,” Duarte suggests, when explaining the issue.
Take a look at Duarte’s advice and let us know what you’d add for programming tips to the list.