Make Better Software by Learning from Your Mistakes
You’re going to make mistakes. You’re going to break code. You’re going to put a lot of time into one aspect of a project and, in the process, throw an entirely different section out of whack—likely forcing a different member of the testing or development team to put back together whatever you let fall apart.
It’s human nature, but what you can control is what you take from making these types of mistakes. One of the simplest comparisons comes when you look at the relationship between a freelance writer and an editor. A good writer will do his best to deliver copy that's as clean as possible, but a great editor will almost always find things to improve upon in the final article.
That editor will apply the changes, and if they aren’t overly extensive, publish the post without asking any more of the writer. However, many writers will see that their work has been published, turn in an invoice for the payment, and call it a day without understanding the edits. That would be like a developer breaking some sort of scripting in the code, having the tester clean it up, and then moving on without learning how or why it happened.
In both cases, the person responsible for the work that needed editing or fixing must put in the effort to learn what was improved and how to be better in the future. Assuming that there’s always going to be someone there to clean up the mess can lead to major issues if, for example, you’re faced with greater responsibility and less of a safety net down the line.
Jared Richardson, a principal consultant, spoke with StickyMinds about the teams he’s worked with who actually grow from these scenarios.
“The best teams I've ever worked with—the people who make the mistake, get the email, learn from it, and quite often, they don't make the mistake again. That's a completely different scenario for having one group maybe cover a product through maintenance, versus the team that wrote it,” he explains. “If you can have the same people who write the code, write the problems, the mistakes, the issues, be the same team that fixes it, they become a much better team.
“When you have anybody else cover that, you're cheating the team, and you're enabling those long-term dysfunctional behaviors to continue. A good continuous integration system, with a good automated testing suite, gets you that feedback while you still remember what you were coding.”
If you accept that it’s OK to make the same mistakes over and over, you’ll never give yourself the opportunity to grow. If you don’t grow, you won’t improve your software. A writer should always ask why an editor did what he did in the same way a developer should understand how he can fix the code he broke. This way, the entire development process becomes much, much smoother.
