If you’ve worked on a project available to any reasonably sized audience, then you’re no doubt familiar with the bug reports, problems, and issues that can come in after something has gone live.
It’s true that the majority of the work in software comes after the first reason of a release.
Think about it this way:
Once you’ve built the product, released it, and then are responsible for maintaining it, how often do you have to triage issues? Then how frustrated are you that you’re fixing something that wasn’t foreseen earlier during development?
The thing is, this is entirely normal. It’s no less frustrating. But it’s normal. However, there are small, practical things we can do to our code throughout development or during maintenance.
And that’s part of the problem that we often face, isn’t it? There are things we know we can do but the amount of time it takes to do them is often incompatible with our deadlines.
So what can we do?
I’m one of those types who reads a programming book every now-and-again. Don’t get wrong: With the proliferation of information available on the web, the need to have an actual physical book isn’t as much as it once.
But there are still several books I recommend (things like Code Complete and Don’t Make Me Think, for example). Most of the rest of the books? If you want to take a nap, then read the first chapter or so.
The problem with many of those books is they become dated, have to have a second, third, or fourth edition released, and don’t often focus on principles that transcend technologies (the above two books do this, but many don’t).
The Little Green Book Series
And that’s where Tonya Mork and her Little Green Book series comes into play. I know, I know: Whenever sentences start like this, it sounds like a plug.
So let me get this out of the way first:
- I receive no commission for selling, promoting, or encouraging the purchase of this book.
- I receive no form of royalty or payment for discussing and sharing this book.
- I’m not paid anything for any of this.
In short, I’m sharing this book because I think it’s something that everyone who develops solutions using WordPress (or other platforms and frameworks) could benefit from reading.
And it’s a very short read:
You’re busy. You need easy wins, fast, and right now to make your code better. Bam, here are 7+ refactoring tweaks that you can do right now. Yup, quick, easy, actionable tweaks that saves you time and money.
That is, you could probably read the book in an hour or two at the most (if you work through the exercises in the book.
On top of that, the book ships with a workbook that allows you to apply what you’ve [quickly] learned. For those who work in WordPress, you’ll recognize many of the examples from our world, and you’ll see just how easy it is refining some of the things many of us are guilty of including in our codebases.
And then we’re able to see how to make the better.
When it comes to supporting resources on this site, I only do so for things that I use and think are beneficial for other people.
I’ve read this book and had the honor or writing the foreword for the book.
As much as I love building solutions for other people, I also enjoy helping others increase their skills. This book will do exactly that. Tonya’s done a stellar job of taking what’s historically dry material, summed it up in seven quick reads, and made it immediately applicable.
I hate quoting myself, but in the foreword, I say the following and it’s the best way I know to summarize this:
It’s not hundreds of pages long, and it’s not full of jargon. It’s succinct, direct, and you will be able to apply your new knowledge by the time you finish reading.
So if you’re feeling the pains of needing to refactor your code, but need some refactoring tips actually to get going, then I recommend this book.
I think you’ll be better for it.