The Meditations Newsletter

📊 Survey: Modern Work and Wellbeing

🙋 Ask Ashutosh

💬 Gary asks:
I'm a self-diagnosed tinkerer, and I'm always trying new tools. But your point about expertise resonates with me; I'm challenging myself to critically evaluate my own behavior in light of that insight.

Here's my dilemma: technology is rapidly evolving, and tech companies can get stagnant once they attain market share. It stands to reason that new tools will come along that are objectively better (cheaper, faster, more efficient) than the tools I'm using. My fear is that the "expertise" mindset could lead to an irrelevant skill set with deprecated tools, workflows, and processes.

A couple of questions for you:
• How do you define a "high quality tool" that's worth the time it takes to develop expertise?
• How do you evaluate your current tools, processes, and workflows to keep up with technological advances and avoid stagnation? 


🎙️Ashutosh's response: 
I can confirm your fear of the expertise mindset is well founded. I’m the opposite of you. I do not try new things just to tinker with a better way. I’ll suffer through a good enough solution for as long as I can bear it. This approach risks me falling behind the times.

I think I ended up with this approach after years of living in the novice mindset where I always wanted to try new tools was optimistic that each new tool would be the solution to all my problems. I kept trying tools and kept finding my problems never really went away. The common denominator was me and so what needed to change was how I thought about my tools, how I developed expertise in them, and how I used them. I now approach new tools with skepticism.

I’ve had to find a balance. Tinkering all the time is just a distraction and if you don’t lean in and learn a tool you probably won’t be very good with it. Sticking with what works risks irrelevance and just doing things in an objectively worse way as the world evolves. I don’t have a system for evaluating my current tools and processes but I make it a point to try and learn or try new alternatives as I see them to ward off obsolescence. I’ll usually come across new tools on HackerNews, Twitter and the like.

Instead of approaching new tools with the enthusiasm of a tinkerer and optimizer. I approach them as an A/B test. My current tooling is the control and the new tool is the variant we’re testing. I don’t just wholesale replace my current system with the new shiny tool. Instead I evaluate side by side (in a limited way) until I can truly decide whether or not it’s better than my current system. The hard part is knowing how long to run this trial before you say a tool isn’t better than the current way. And what makes that even harder is when you are evaluating a new tool against something you are quite proficient with. The more proficient your are in your control tool, the more time investment you’ll need to get good enough with the new tool to truly evaluate it. So expert usage of a tool has a way of making potential new tools look really bad at first glance. I think this is why you see so many experienced people stubbornly continue to use objectively worse tools - they are unwilling to invest the extra time in the new tool to match their expertise in their current tools. And this is why novices are willing to always switch tools, they’re over the expertise hump quickly, if it even exists.

I recently went through this as I tried out using Cursor (an LLM/AI coding copilot). Instead of just swapping into Cursor for a real work day, I decided to set aside a few hours on a weekend to try and do a real task but without the the usual time pressure of getting things done as quickly as I usually do. This gave me lots of time to try thing, learn, read docs, watch demos, and build proficiency in the new tool without feeling like I needed to be as fast as I am usually. If I had used Cursor during a new work day, I’d have been frustrated with the learning curve and just gone back to my old way of doing things. After a couple weekend sessions like this, I started feeling comfortable using Cursor and started adopting it into my normal work day. It took about eight hours of dedicated and less efficient usage to feel like I got to my normal pace of development. And now, a few months in, I’m writing code significantly faster than I ever have before because I took the time to overcome my own expertise. Had I just jumped head first into Cursor (like I did for GitHub Copilot), I’d have given up on my first day out of frustration and incorrectly deemed the tool as being “not good” even though the problem was really that I wasn’t good enough at using the tool.

I know that’s not a direct answer to your question but hopefully it’s food for thought to those questions. 

Write Us Back!