There's a forest in the trees?
I have a high attention to detail, which also means I often get caught up in the details. This makes me a good engineer (I hope), but sometimes frustrates my friends when my stories/jokes get cluttered with all the little details. I appreciate those details, but everyone else? Not so much. Here’s how my best man at my wedding put it:
Joel can’t see the forest for the trees. If he tries to explain the forest, you are going to get the trees, the shrubs, the flowers, all along the way. But those are the important details that a lot of us overlook.
This is probably my greatest asset and weakness at the same time. I’ll see all the little things, but miss the big picture. I’ll notice the typo that leads to a production outage. I’ll realize there is inconsistency in the user experience. I’ll find that missing field in the data that means a migration has a problem. I’ll see those dust bunnies hidden in the shadows. I’ll miss the fact that my wife just needs me to shut up and let her vent about her day. She doesn’t need my engineer brain to solve a problem.
As you can probably guess, I’m a firm believer in getting the little things right. Covering every test case, talking through every user flow, ensuring we abstract our code appropriately, and triaging the little bugs to ensure they aren’t a symptom of a much larger problem. All of this also means I get exhausted from context switching. It’s truly painful. I can do it, but my brain has a recalibration time and cost. This is one of the tough parts about my current role. I’m a lead, which means that I am in the early conversations and planning around the next cycle of work, while also being responsible for delivering sprint work. Usually, these are not remotely the same subjects. How do I handle that? Great question, so glad you asked.
This should be the point in the story where I give you my five step plan for how to combat context switching and sell you on some course. However, there is no such plan and I have no such course. I don’t have it all figured out. I’m still learning, but that’s the beauty of it (at least that’s what I keep telling myself to stay sane). I’m learning something entirely different from what I’m used to. Usually it’s a new coding language, framework, library, tool, etc. Those have a solution or consistent pattern usually, but this has no such thing. It feels a little bit like project management, but for my brain. I’m usually not great at taking notes, but I’ve had to start doing that more, and it’s actually helped. I guess that’s my one step plan that has helped me thus far, and I’ll probably report back if I figure out anything else, but honestly, I feel like every person is different and every situation is different. What works for me may be the least helpful for you (so don’t consider this “advice”).
I’m going to try to be more diligent about taking notes. Since I need the details, having them written down will hopefully help my brain recover from that cognitive load more efficiently. I’m kind of hoping that having this blog will help me be more mindful but also maintain the habit of writing more down. Though ultimately, I’m trying to work with the product team to reduce the number of priorities we are executing on at once. Fewer priorities means less context switching (this should absolutely be a takeaway, so I guess that’s a second step in my “plan” that isn’t a plan).