You open an old file and everything feels wrong, right?
The code feels off, the comments are wrong, the variables mean nothing, style’s all weird, even the formatting looks funny. Like somebody with no skill and poor taste wrote that code.
NOTE: This is a cross-post from my newsletter. I publish each email two weeks after it’s sent. Subscribe to get more content like this earlier right in your inbox! 💌
Sure, it was you, or your team, but 3 years ago. That was a different person. Your team was a different person. You’ve all grown and gotten better and your priorities are different now.
Maybe 3 years ago you didn’t know the language as well. Or the framework. Maybe you’ve learned a bunch of new frameworks and libraries and tricks that make your code better and easier to write.
Maybe you were just rushing to hack together a prototype and now that same prototype has proven itself and you’re focused more on stability and correctness.
Whatever it is, your old code looks like shit to you.
So what can you do? The Boy Scout rule!
How the Boy Scout rule improves your codebase
The Boy Scouts have a rule:
Always leave the campground cleaner than you found it.
You can apply that rule to code. When you open a file, clean it up a little. Leave it cleaner than you found it.
Comment out of date? Fix it. Code style looking funny? Change it. Indentation all wrong? Fix that too. Fix all the things!
You might not have time to make any real changes, but anything helps. Next time you open that file, you can clean it up a little more. Over time, your codebase improves.
With the Boy Scout rule, your whole codebase grows with you and your team. Not just the most recent lines of the most recent files.
If you’re afraid to work with some parts of your system because there be dragons, that’s a sign you need to clean up some stuff. Maybe even put some time on the roadmap to get in there and fix things.
Why teams ignore the Boy Scout rule
Most of the teams I’ve worked on tend to ignore this Boy Scout rule.
Last week, I was auditing our API integrations and found a file that was 60% TODO comments from 3+ years ago. Code in active use, as far as we can tell, just never finished. Got it working, moved on, never came back.
That’s an extreme example, but when was the last time you refactored some code just because it wasn’t pretty enough? Exactly.
Engineers avoid changing code for all sorts of reasons, but two stand out 👇
Engineers are afraid to change code because code that you currently believe is working might stop working if you change it. The number of times I broke something by fixing a typo that introduced an
undefined error is too damn high. Or removing a comma that I shouldn't have…
Your code coverage isn’t perfect. It never is. So you might not catch the error. Your type system might have one too many loose
any type. That won't catch the mistake either.
So you have to hit your QA team and that just takes forever. Ugh.
Best not to bother. Leave good enough alone.
As an extension of that fear, engineers avoid taking ownership. When something does go wrong,
git blame is a magnificent tool. Tells you the last person who touched a line of code, when, and in which commit.
Blame is a strong word. You don’t wanna blame them for anything. But you can ask them why they made the change. Maybe it broke things for you or you just need some help understanding their code.
It’s great when you know who to ask.
When everyone’s making random style changes, you might use
git blame, waltz over to ask a question, only to be stonewalled with a "Oh that's not my code, I just fixed a typo. Ask her. She wrote it 👉."
Use the Boy Scout rule anyway
You can fix your fear of changing code with improved processes and better tests. The more you do it, the less fear you’re gonna feel.
Talk to your boss. Their job is to create an environment where you feel confident about changing code. You should never be afraid to improve your code.
If you are the boss … well 😉
You can’t solve the
git blame problem, but you might not need
git blame, if your code is nice enough to read because you've been boyscouting it this whole time.
In other news…
I passed my motorcycle class this weekend! Two intense days of classroom theory and parking lot practice. So much fun!
You know what that means? It means this idea might happen 👇
That’s gonna be fun if it happens. But we’re not quite there yet.
I now have all my gear and I know how to ride in a parking lot. Lots left to go.
You should read this fun story I published last week: A lesson in sales from the guy who sold me $1500 of gear when all I wanted was a $100 pair of gloves
React + D3 2018 news
Big progress on the React + D3 2018 book/course update last week. The main 12,000 word chapter is all up to date. Currently being test driven by my interns.
Plan is to update the small intro exercises to match the workshop stuff tonight and send the updates to everyone who’s preordered tomorrow. Fingers crossed it works out.
If all goes well, the whole book might be finished by next week and then we launch for realz. After some more QA.
A few cool things…
Long week, feels like I missed most of the internet, but here’s a few cool things I did find.
- You know carbon.now.sh? That service for making beautiful “screenshots” of your code? Apparently there’s a CLI too. Somehow I just found out.
- If you upgraded to MacOS Mojave and don’t like how VSCode renders fonts. MrAhmadAwais recommends this fix.
- WatermelonDB looks super cool. They’re calling it a React database. To me, it looks like someone built a state management library with built-in firebase sync (but prob not backed by firebase). Need to find an excuse to try it out :P
- Somebody built a self-solving Rubik’s cube, and that’s amazing. Algorithms to solve a cube are common these days, but the mechanics of fitting all that inside the cube? Amazing.
P.S. If you like this, make sure to subscribe, follow me on Twitter, buy me lunch, and share this with your friends 😀