On this page:
I teach advanced coding to professional developers from all over the world, and it’s surprising to me the number of developers that write very few tests for the software they build. There are many reasons for this, and I’m not here to point anyone out, instead, I’d like to share with you what I’ve found to be the number one reason that makes me, in practice, want to test the software I build.
First, let me tell you something about who I am, I’m a software engineer with 15 years of experience and I am extremely good, I’m very very very good… at writing bad code… on the first try. But I think I’m not alone.
Why is it so hard to build it right on the first try and so we need to iterate? The good news is it’s not because of us developers :), it’s because of the nature of building software. Building software is a complex problem.
I’m going to define complexity in the context of this article as the "unknown unknowns", meaning cause and effect can only be deduced in retrospect. In other words, when we build software, a human believes that there is a problem to be solved. The problem needs to be defined and explained to other humans (unless it’s both built and used by only one person). Then, other humans design and implement the right solution to the problem. Finally, even if all the previous steps were executed perfectly, it could be that the problem was not actually a problem or that before the right solution is implemented the problem changed. Building software is a discovery process because of its complex nature. That’s why we build it iteratively.
It seems that the more tests we write, the more we can iterate. Let’s list the main reasons for which writing tests will help us iterate more, but also the people who will directly benefit from that:
- Test automation. This means faster deployment and fewer bugs. Reliable products, happier users.
- Adapt to change. We can add new features or change existing ones faster. That makes all the product owners and stakeholders that I know happier.
- Understanding and documenting code. This is good for onboarding new developers. Now we’ve got happier colleagues because it’s easier to understand the new code base they’ll work on.
- Last but not least, there is a reason that will likely make you, the developer who implements the feature, happier. Code refactoring.
Code refactoring is in very simple words, making something that already works, better, without changing what it does. I don’t know about you but I feel an extreme pleasure every time I can improve something I built before.
The more we iterate, the closer we are to the optimal solution. The goal is not to get to the optimal solution, but to be good enough at different points in time.
In my view, a senior developer is such that understands the complexity of our job and so plans for successful future change to minimize the cost of that unknown change, now. Experience can be defined as the knowledge you learn after you need it. Writing tests is a key tool to help you with that process.
Related articlesHow to choose an online courseHow aligned is GraphQL to your business needs? Are Employee Retention and Employee Training Related?Arise React GraphQL Academy - Announcing Our New NameAnnouncing our new GraphQL Bootcamp!
Join the newsletter
Do you like the article? Sign up for our newsletter and don't miss a thing!Sign up
Share this on:
This website is built using Gatsbyjs. Curious about how this blog is implemented? It's open source so you can check the source code
Comments? Shoot me a tweet @alex_lobera !