Boyscout Code
Published on July 20, 2017 (↻ February 5, 2024), filed under Development (RSS feed for all categories).
[…and girlscout code and any scout code:]
Still evaluating and normalizing feedback for the great maintainability survey I’ve so far worked through a ton of excellent comments. All of it will, in a comprehensive fashion, make for a new, updated web maintainability guide, and yet one particular aspect resonated so well with me that I wish to call it out again specifically: the boyscout approach to code.
This approach resurfaced after one of our peers commented the following on “What techniques do you find useful to keep websites maintainable?”: “Refactoring every time you touch something and see potential for improvement.”
We’ve probably all been there at some point, when we saw something and fixed it (a googley principle), and so I instantly nodded, “yes, that’s a great habit.” It reminded of the boyscout credo, attributed to Robert Baden-Powell, to
Leave this world a little better than you found it.
or, more specifically,
Always leave the campground cleaner than you found it.
This does work so well for code that—formerly (though certainly not unsurprisingly) unbeknownst to me—it had long been quoted by Robert Martin in, exactly, The Boy Scout Rule:
Always check a module in cleaner than when you checked it out.
…which we could, and I’ve included this in my errata for The Little Book of Website Quality Control (updated), rephrase to simply say:
Always leave code better than you found it.
This is not new, either, but it’s how I’d prefer to spell out the boyscout rule. Always leave code better than you found it.
As I said, there’s progress with the new, survey-inspired maintainability guide; stay tuned on Twitter or through one of this site’s feeds (subscribe just to my developer feed if the rest is not of interest to you).
Update (August 21, 2021)
I like John Ousterhout here, writing the following in A Philosophy of Software Design:
Whenever you modify any code, try to find a way to improve the system design at least a little bit in the process. If you’re not making the design better, you are probably making it worse.
This makes the boyscout rule imperative rather than “nice to have.” (It also asks for strategic and not tactical programming, but this is best explained in the book.)
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m somewhat close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you’d like to do me a favor, interpret charitably (I speak three languages, and they do collide), yet be critical and give feedback, so that I can make improvements. Thank you!
Read More
Maybe of interest to you, too:
- Next: What I Learned Building Google’s Web Frameworks
- Previous: Stop Using Resets: Visual Examples of the Practical Nonsense of Resets and Normalizers
- More under Development
- More from 2017
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.