I’m going to ignore all the contents of Will Larson’s The Staff Engineer for a moment to just point out how ingenious it is to put QR codes next to every article/post/book in the references! Such a simple change, but so helpful!
Hey, look at that, almost exactly a month between my last 2 posts!
Old habits really do die hard… you have to actively try to kill them, and they will jump at the first opportunity to rear their head. (ctx: After taking my digital usage down to a reasonable level I have relapsed for a month, but I’m starting to get it back under control, hopefully)
Bookworm PSA: Buying an e-book reader is dangerous! Now the only thing stopping me from immediately buying and starting to read a book someone recommends me is my self-control. I am doomed!
P.S.: It’s also amazing, if you want to read huge fantasy series spanning multiple books, 700-900 pages each!
P.P.S.: I still love physical books, but the convenience factor is impossible to deny and hard to beat.
TIL: When you are making large refactors to your code (e.g. when introducing a code formatter like black) and you don’t want them to muddle up your git blame, you can create an ignore file for specific revisions! No more false attribution and having to manually look up the change history for specific lines to find out the real source of truth!
Command for setting the .git-blame-ignore-revs file as your ignore file.
git config blame.ignoreRevsFile .git-blame-ignore-revs
The format for this file is a single git revision hash per line. This also automatically works with most IDEs I’ve tested (a restart might be required), as they use git blame under the hood.
Investing a little bit regularly (every day) into keeping things in order / taking care of things applies the same way to tech debt as it does to household chores or self-love.
If you do it consistently, you might be able to prevent the big intervention/clean-up effort. Or at least significantly reduce its scope.
With the first snow of the year here, I’m once again reminded what a great feeling coming in from the cold after a long walk, making a nice big pot of tea, and settling in with a good book is. 🫖🍵
“Therefore, you should be warned that this book, like all books, is biased and incomplete…”
- Donella H. Meadows, Thinking in Systems: A Primer
Judging just on the Note from the Author, I know I’m in for a treat!
When I first heard of the Godhart’s Law it resonated with me, as I believe it did with many people, because it describes a common pain developers feel. However, the more I thought about it, the more I realised that that’s all it does - describes the problem. It doesn’t in anyway help you identify the core issue, nor solve it in any way. That’s why when I ran into this article I was glad that someone else felt the same way and even provided a more useful formulation:
When people are pressured to meet a target value there are three ways they can proceed:
- They can work to improve the system
- They can distort the system
- Or they can distort the data
Thanks, Cedric Chin!