Finding boosts
When I first wrote my first line of HTML back in the early 2000s and saw text appear on the screen, I was elated. It felt like magic; this wasn’t just any instance of mashing a keyboard and seeing something on the screen, it was a deliberate act of formatting and producing a document to be shared on the web. I created this text. I experienced my first boost.
Something that I’ve found so magnetic about writing software is that there are so many opportunities to find little boosts no matter what I might be working on. In my early days, pointing a browser at a local HTML file was my gateway. Nowadays, I make it a point to try and maximize boosts through things like:
- Refactoring files so they’re easier to read without language servers or AI copilots.
- Writing comments to help future me and team.
- Reading code and comments later and quickly understanding what’s going on.
- Optimizing server response times and seeing latency graphs go down.
- Writing tests and making them green.
- Fixing bugs and supplying tests to guard against regressions.
- Pair-programming with teammates and reaching ah-ha moments.
- Taking advantage of newly shipped CSS features available on all major browsers.
- Using CSS instead of JavaScript where possible.
- Using HTML instead of JavaScript where possible.
- …and the list goes on and on.
Boosts are different for everyone, but they’re important. They’re critically important, maybe. I think cultivating an environment where the team can find boosts directly affects retention and overall happiness. I’ve definitely left jobs where boosts were discouraged.
I’ve started using that vision as a guiding rule of thumb of sorts. Will doing this thing help build a culture of finding boosts? Yes? Okay, I’m going to do it. You don’t need to be in a leadership position to contribute, although that certainly helps.
What do the wider team’s boosts look like? Do they align well? Do they encourage boosts? Communicating to learn each other’s boosts could unlock something.
Find boosts.