This is a select list of things that I’ve read lately and thought were important enough to hold on to.
Mindy Kaling’s Guide to Killer Confidence
I’ve always worked hard, but it feels like my hard work has been directed to certain projects rather than ideas or shoring up general insecurities or weaknesses — treating the side effects of the insecurities, rather than the insecurities themselves.
Not Quite Out of the Office by Raw Signal Group
This is about bosses, but it might as well apply to consultants who care about results, too. An excerpt, that I may hold it in my head and be reminded when I’m in the deep end:
[…] Dr. Clark, almost offhand, mentioned that there was a clear and lasting benefit to having a thing. A thing that pushes work out of your brain. Some kind of task that occupies you enough that work thoughts don’t make it in.
[…] We’ve got about three weeks before we’re into the end of year downtime. Maybe you already know your thing. The one that pushes work out of your brain completely. Maybe you have a stack of puzzles lined up and ready to go as soon as you send your last email. And maybe it helps you to know that the research is on your side. That stack of puzzles is part of a comprehensive rest and recovery practice you’ve happened into. So long as it actually happens.
Focus on Your Own Shit by Justin Jackson
My focus in the past few years has notably shifted from ‘do my job better’ to ‘really serve the right people’, and Jackson’s point about that being one of the only two things to really focus on hits me good. But at this point, I feel like the former is so, so much more important. If I’m helping someone and they’re happy with my work, it doesn’t really matter how good I am at my job. There is no meaning that is derived from being amazing that’s not simply supplanted by actually making a difference.
The Art of Documentation by Chelsea Troy
I always appreciate Chelsea’s take on things. Her take on documentation is very interesting to me because I’ve never ran into the issue where there was sufficient documentation, let alone too much in the wrong spot. I basically agree with everything she said, with two minor exceptions:
First, I think I disagree regarding the utility of an architectural decision document (she argues that it’s better to have these decisions live in git commit history; I prefer something that also gives me a linear overview of major decisions in a project’s history). I also want this information in Git history, though, or at least a commit message that references some specific line in the ADD.
I also would prefer some of the setup steps that she preferred in the README to be system-independent scripts where possible. This is sort of possible with Docker these days but it’s not perfect by any means, but I feel like even if a script doesn’t work on OSX, par exemple, the fact that it was written by someone else and ran at some point moves it closer to being tested and/or at least portable with some effort to different dev set-ups.
On My To-Read List
- Moduliths: because we need to scale, but we also cannot afford microservices
- Is High Quality Software Worth The Cost?
- No, we won’t have a video call for that!
- A Practical Guide To Evil (webnovel)
- Documenting Architecture Decisions
- Decolonizing Fitness
- Production-Ready GraphQL
- Community Banking and Fintech
- Some Notes on Doublethink
- System of a Test
- Learning to Build Conviction
- How I Structure My CSS
- Manage Large CSS Projects with ITCSS
- Why Flow Matters More than Passion
- The Problem With Goldilocks Reliability
- Scaling the Practice of Architecture, Conversationally
- You Can’t Buy Integration
- Introduction to Probability for Data Science