Leave something slightly better of than you found it. - Boyscout Rule

Ancient history tells us this rule was created by the boy scouts: "Leave the camp cleaner than when you found it". But then devs took over the world and started using it as well.

This rule plays out on two different levels, the level of the individual and the level of the collective.

How does it Play out?

Let's picture a few scenarios so we can understand the depth of this rule.

Software Developer

You need to do a task that involves another task that a fellow programmer touched on 2 years ago.

So you find a lot of places in the codebase that are not up to current standards. Instead of refactoring the whole codebase, you can instead focus on improving with Clean Code just the places you need to touch while working on your task.

If everyone in the project acts in this manner, every task done is also a task that refactors a bit of the codebase. Over time the codebase approaches a state of fewer errors and more "clean code". Guess what? That is awesome!

"Leave the code cleaner than when you found it".

Take this to heart and people will love working with your code.

Designer

Your client wants to create a new product under an old legacy product. The old legacy will act as a portal where people will find this new product.

So you create the new product and the client approves it, and along the way, you notice a few things that the old legacy product might improve with little to no effort.

If every designer working on this project improves just a little bit the original legacy product's design... you can see where I'm going right?

"Leave the design cleaner than when you found it".

Scientist

Fellow scientists will see this as an obvious thing, it is after all a scientist's job to improve on previous work. But allow me to explain some other scenarios where the boy scout rule might play out.

You are reviewing a thesis for a friend or even a mentoree, and instead of pointing out many places that can change, you decide on reviewing bit by bit, over one month. You point out a few things that can be improved, knowing that other reviewers will do the same.

Over time, that thesis will be in far better shape than if someone only looked at it once, points out a lot of stuff, and then never reviews it again.

"Leave a contribution to every citation".

Manager

This is a unique case scenario, because before we had the individual focus before the collective focus. Now, as a manager, you need to focus on the collective first.

So instead of focusing on how you personally can improve bit by bit the project, you need to make sure the team is on board with this rule.

The team must be with enough room to improve, not only to spit out tasks every week. The more pressure you as a manager put on the team, the less the team will focus on improving bit by bit (it will be seen as a waste of time).

So it is a fine balance between allowing the team to improve bit by bit and pressuring them to fulfill the client's needs.

But on an individual level, you can take this to mean "Make the processes better than when you found them".

One caveat here: I've ever only had technical roles, so I normally see how the codebase is improving through the Pull Request discussions, I have little to no clue how a non-technical manager would look at the project to see the little details improving, perhaps one shouldn't as it would mean way too much information.

If you are a manager and have a different opinion regarding this, leave a comment below, I'd love to get your input.

😗 Enjoy my writing?

Like my content? Feel free to Buy me a Coffee ☕.

Subscribe to my exclusive email newsletter here.

Forward to a friend and let them know where they can subscribe (hint: it’s here).

Anything else? Just say hello in the comments :).

Join an Exclusive Tech Friendly Community! Connect with like-minded people who are interested in tech, design, startups, and growing online — apply here.