I’m ready to set up the Bulletproof Workspace in Notion. Last week I finished examining the Bulletproof Workspace guide. I turned it into a big checklist to help me set up all the pieces. This week I’ll create the workspace in Notion and start customizing it. Bulletproof is designed to be a basic and highly flexible framework for managing an organization’s information and projects. That’s what I need for adapting Notion to my semi-organized system without feeling immediately lost in all the possible setups, since Notion itself is even more flexible than the Bulletproof template.
At work I spent the week adding improvements to my practice of work journaling. It continues to be an incredible tool for my productivity and state of mind while working through complicated knowledge tasks. I think of it as a harness, and over the week it gained new straps to secure more aspects of my work. I used this in conjunction with TDD (which I refuse to admit was actually fun), and I confirmed that pondering the work is the necessary 0th step of the TDD cycle.
Object-Oriented Reengineering Patterns by Serge Demeyer, Stéphane Ducasse, and Oscar Nierstrasz is a wide-ranging guide to understanding and updating your legacy systems. The only other book I know about for this is Michael Feathers’ excellent Working Effectively with Legacy Code. OORP is written in the form of patterns, which I find helpful for getting a handle on the content. The book expands on Feathers by covering not only testing and refactoring but also the organizational aspects of legacy code, such as communicating with the original engineers and preparing the organization for the new software version. It also goes in depth on ways to analyze the legacy code.
The Art of Readable Code by Dustin Boswell and Trevor Foucher has a lot of practical advice, yet also not enough. It has an extensive and helpful section on naming things, which is one of the hardest parts of programming. And I’ve already started using some of its advice on comments. For example, write them as if you’re explaining the code to a new member of your team. The book is briefer on some of its other topics. For example, when it cautions against constructs that can make the flow of control harder to follow, it lists some very common ones, like threads and exceptions. It would be great to see an in-depth treatment of writing code that minimizes these. But overall the book is very worth the time.