The Importance of Small Changes
Just quick post on a book I read relatively recently called One Small Step Can Change Your Life: The Kaizen Way. This is a fantastic read. Its one of the few books that has changed my life. I've been thinking about it recently and thought I'd share a few thoughts on how it relates to Software Engineering.
The book talks about how small changes are a lot easier to actually do than big changes. Not only that, they can build up to big changes. In Software Engineering, there are a number of best practices we know we should be doing but that we often don't do for one reason or another. Be it better code formatting, TDD, writing tests at all, communicating better with our Product Owner, or whatever it is, there are a number of things that we often struggle with even though we know better.
If we were to take one of these items and want to improve them, our natural tendency would be to go all in. 100%. We feel that if we're not 100%, we're failing. Why do it at all if we can't do it right. While in some cases that's valid, I've found that in most situations it's better to do it partially than not at all.
For example, say we know we're not the best at formatting our code. That's somewhat of a minor issue, but it can really affect readability for when we or one of our coworkers has to come back to it later. Our first reaction might be to put a reminder of some sort to help us remember to check all the formatting on all the code we write before we commit it. Or we might think we need to spend a lot of time configuring our IDE to format the code for us in just the way we like it. I'm not sure if you've noticed, but your probably feeling resistant to these ideas. You're thinking, "that sounds like a lot of work." Or, "yeah, I'll just add that to everything else on my TODO list." That resistance is one reason why our traditional, normal approaches to change fail.
If we did this in a Kaizen way, we'd notice that we're resistant to making those changes and then try to find a smaller change that we could do. Maybe we choose a subset of formatting rules to configure. Maybe 10 or so (that seems like a lot for this particular example, but bear with me). Even 10 rules feels like a lot. So, we need to go smaller. Maybe we decide that we'll set up one rule and that's our first step. Or, maybe we decide that our first step will be to find out how to set those rules in our IDE. Or maybe our first step is to simply think, "I should set these rules up" a few times during the day. I know that last one is laughable in this case, but the technique can easily apply to other situations (read the book to learn more).
Once we've identified a small enough step that we're not naturally resistant to, then we're gone small enough. We've identified the first thing we should do. We can then build from there.
It's really quite different to think in this way, but it's completely life-changing. Suddenly your New Year's Resolutions take on completely different meanings. The things you resist doing at work suddenly seem more manageable as you address them in the Kaizen way. It still takes work, but you're much less resistant to it if you take it one small bite at a time.
I highly recommend this little book. It's helped me as I've helped refine and estimate stories, it's helped as I've written code, it's helped as I've provided code reviews and feedback for other engineers.
The book talks about how small changes are a lot easier to actually do than big changes. Not only that, they can build up to big changes. In Software Engineering, there are a number of best practices we know we should be doing but that we often don't do for one reason or another. Be it better code formatting, TDD, writing tests at all, communicating better with our Product Owner, or whatever it is, there are a number of things that we often struggle with even though we know better.
If we were to take one of these items and want to improve them, our natural tendency would be to go all in. 100%. We feel that if we're not 100%, we're failing. Why do it at all if we can't do it right. While in some cases that's valid, I've found that in most situations it's better to do it partially than not at all.
For example, say we know we're not the best at formatting our code. That's somewhat of a minor issue, but it can really affect readability for when we or one of our coworkers has to come back to it later. Our first reaction might be to put a reminder of some sort to help us remember to check all the formatting on all the code we write before we commit it. Or we might think we need to spend a lot of time configuring our IDE to format the code for us in just the way we like it. I'm not sure if you've noticed, but your probably feeling resistant to these ideas. You're thinking, "that sounds like a lot of work." Or, "yeah, I'll just add that to everything else on my TODO list." That resistance is one reason why our traditional, normal approaches to change fail.
If we did this in a Kaizen way, we'd notice that we're resistant to making those changes and then try to find a smaller change that we could do. Maybe we choose a subset of formatting rules to configure. Maybe 10 or so (that seems like a lot for this particular example, but bear with me). Even 10 rules feels like a lot. So, we need to go smaller. Maybe we decide that we'll set up one rule and that's our first step. Or, maybe we decide that our first step will be to find out how to set those rules in our IDE. Or maybe our first step is to simply think, "I should set these rules up" a few times during the day. I know that last one is laughable in this case, but the technique can easily apply to other situations (read the book to learn more).
Once we've identified a small enough step that we're not naturally resistant to, then we're gone small enough. We've identified the first thing we should do. We can then build from there.
It's really quite different to think in this way, but it's completely life-changing. Suddenly your New Year's Resolutions take on completely different meanings. The things you resist doing at work suddenly seem more manageable as you address them in the Kaizen way. It still takes work, but you're much less resistant to it if you take it one small bite at a time.
I highly recommend this little book. It's helped me as I've helped refine and estimate stories, it's helped as I've written code, it's helped as I've provided code reviews and feedback for other engineers.
Comments
Post a Comment