Learning from mistakes
Today I'm kicking off a new series on writing and maintaining JavaScript software titled "Designing Good JavaScript" by looking at learning at our mistakes. I hope you enjoy this post and the series!
How many times have you loaded up a file in your codebase to make some quick changes, only to be confused by the choices you made six months ago? How many times has that architecture you worked so hard on in the past come back to bite you? How often do you find yourself bemoaning a section of the codebase to a colleague, thinking that the only way to solve it is a complete rewrite?
The good news is that if you answered "yes" to any of those questions, you're not alone, and you have something in common with me! I've spent the most part of my career maintaining large JavaScript applications and what I've come to realise is that it's easy to write code you can understand now, but hard to write code you'll understand in six months. The best engineers I've worked with aren't the best because they know every API method under the sun, or because they can turn five lines of code into two with a clever reduce call, but because they write code that they (and their colleagues) can understand now and code that can be understood in the future. They have an awareness of how a particular decision now can impact your velocity further down the line and an ability to predict problems before they happen.
How do these engineers get this ability? Experience. They don't foresee problems because they are able to look into a crystal ball, or experience premonitions of the future like that kid in Final Destination, but because they've been there, done that, countless times. How do they know that a particular approach might backfire? Because two years ago working at Company X, it did.
The good news is that whilst there is no substitute for experience and learning from your mistakes (and being nice to yourself in the process) there are many people, including yours truly, willing to share their mistakes and lessons learned from them. No engineer knows everything, and no engineer makes the right decision on software every time. Opinions on software are formed over time as we write code, make decisions, and learn what works and what doesn't. That's what this series is all about. Over the coming weeks I'll be sharing opinions and stories from when a software decision backfired - or when one really paid off - so that you can keep them in your back pocket when the next time a similar decision has to be made. I'll reflect on teams that I've worked on that have executed efficiently, and teams who have got bogged down in process, and everything inbetween. Think of this as a series where I share my experiences so that you can take them and use them to inform your decisions. There's no lecturing here.
If you've got any questions, comments, feedback, or just want to say hello, get in touch with me on Twitter. I'm excited to share these articles and would love to hear what you think, or any suggestions for content.