or at least consider it
“Don’t sweat the small stuff” has been around since forever. It is on TV, in movies, on the walls as posters, there are even books named that. Parents try to teach their children not to overreact to minor issues by using this idiom from the early age. With all of this, it is not odd that this phrase is so deeply engraved to adults’ mindset that it is almost common sense.
I like the idea of this expression, but I also see a problem that arises from overusing it. I, as a software engineer, have been seeing how people embrace this idiom in their workplace:
- how managers do not sweat the fact that team missed the deadline by one day
- how developers do not sweat that little bug which crashed the production for two minutes
- how product owners do not sweat that small system performance drop
- etc.
All of these examples could look like they are no biggie and “Don’t sweat the small stuff” is the one to go with when such situations occur. Well, I would not jump to such conclusion just yet. From my personal experience, the people who do not even consider sweating the small stuff, tend not to sweat the big stuff either. But they should and here’s why:
Small stuff indicates upcoming problems
Consider this — your team failed last development iteration by an inch. It is not that big of a deal. Right? You will probably do better next time. Right?That might be true, but there also may be problems inside the team. Maybe team spirit is not at its best place right now, and it is getting worse. There are high chances that you can solve this whole mess by going for a beer with the team after work today. But if you will wait for a while to make sure that something is wrong, it will most likely explode and turn into big stuff.
Small issues that you are not resolving in time tend to turn into bigger ones every time they re-occur. Give it a couple of minutes of thought, and it may save you hours of struggle in the future.
Small stuff teaches lessons
In software development business bugs, downtime, emergencies, post-mortems and similar things are very common. There is just no way to avoid them entirely. So we can only choose how to handle them. It is very common for IT companies to embrace “blameless” policies. In other words — nobody is ever guilty of anything. It is an excellent point of view because nobodies hands are getting chopped after production crash. But it also removes the chance for individuals to improve their game.
Consider this — developer deploys a buggy code to production servers and they crash for a few minutes. Other developers and operations staff reacts to automatic alerts, proceeds with rollback and resolve the issue. Everything could end here, or you could organize a post-mortem meeting next day. During the meeting, everyone would talk about reducing reaction time, code review quality, more automated test, etc. And it is very likely that developer who was responsible for that deployment would leave the room with a smile on his face.
Well, guess what — he will deploy buggy code again, and next time impact could be a lot bigger. So, try to treat every small stuff as colossal stuff and learn from it as much as possible.
Small stuff helps you prepare for the big ones
Not every issue has a lesson in itself. Sometimes you are just glad that it was so small because overwise you would have been screwed. For example, you have re-implemented your database storage layer, and overall servers’ CPU usage jumped up by a few percents. That’s no big deal you had good reasons to make that change and impact is not that big. So, you should probably not treat it as a lesson not to switch database engines ever again. What’s important here is how serious you will look at it.
You could not sweat that three percents at all, or you could decide to dig deeper and find out what precisely caused increased resource usage. It could turn as an acceptable trade-off. But it also can turn out as a problem that will spread. If you do nothing, your resource usage may grow by a few percents after releasing new features, or with increasing amount of data in your database. Those few percents can become full hundred out nowhere one day and cost you lots of money to fix that.
However, if you would monitor those small changes and track the trend, you could probably solve it over time without the struggle. By observing minor issues, you can prepare yourself for upcoming big ones or prevent them altogether.
So, to summarize, small stuff in our world is not always the same small stuff as outside of our workplaces. I believe that many significant problems tend to introduce themselves in the form of small ones and it is up to us if we will react to it. Usually, it takes only a few minutes to distinguish if what you are looking into is worth more of your attention or not, so that is a small trade-off in comparison of what might happen.
Happy sweating, folks!