Summary: This article is for creators feeling the Shiny New Toy Syndrome. I believe this is expected, and I describe why. Then we go on with a few methods that might get us out of it.
Are you spending a lot of time reading about new technologies? How often do you wonder if you should try this new tool, this new language, this new framework? How often do you use a technology that you just started using?
🌱 This article was published at the beginning of 2021 and is quite fresh.
You spend a lot of time thinking about which tools are the most efficient to do your job, and you spend a lot of time trying new things.
Here is a secret you might know already: you spend a lot of time learning things that you don’t need, and you don’t build as much as you should.
If that’s you, then nice to meet you! 👋 We’re both addict to the shiny new tool syndrome.
Creators are eager to create new things. That’s obvious.
And as a creator, we are very sensitive to new things around us. Maybe they make you uncomfortable “someone is having success with another great idea I wanted to build.” Or perhaps they intrigue you “that looks so much better than what we had before; I need to try this.”
We’re always on the lookout for things changing around us. That’s perfectly reasonable and even expected, below a certain point.
I believe the problem arises when we spend more time learning about new things than using them. Or when we spend more time working with tools, we don’t really know.
Always on the lookout for the latest HackerNews articles, following hundreds of RSS feeds. That felt amazing, every time a discussion about a new tech arise, I knew about it, and I already had an opinion. I tried so many of them.
You know what? I forgot most of these techs, and most of these are dead. Have you ever heard of famo.us? The future of web apps, with their 3D rendering engine that was shaking the world? They build Shopify stores now, and Facebook is still in 2D.
I’ve fallen for this trap multiple times. I’ve seen teams and clients fall for this trap too, and I’ve found a few ways to mitigate this.
I believe this is why we do this: we love learning new things. Every time we learn, we get a small release of dopamine. Success your brain tells you, I like when that clicks, do it again.
But the more we know a tool, the less learning we get per unit of time using it. The less dopamine we get from actually using that thing.
When I try a new Software, give me 25 minutes with it, I learn 5 things about it. But after years, I might discover one novel idea every month.
The more we know a tech, the less rewarding it is to use it. Especially if you care too much about learning. I recognize this as the “Sugar” of my Knowledge Worker role. Learning rocks, especially at the beginning of a career, but it isn’t sustainable by itself. That applies to businesses and individuals alike.
So learning is my thing, is it yours?
I wouldn’t be surprised that’s the same thing for you.
What’s the rational thing to do once you spent time learning? You write about it. And that is the first rule of content marketing: If you publish about something, you become an expert. And if you’re an expert, you get more views, and you get more money and more jobs.
It’s easier to become the top 1% expert for software with twenty users than it is to become the leading expert for some old school beast that has seen generations of users.
So following trends is incentivized, and it’s rewarding.
Up to a certain point.
A few ideas, I’m still learning on this,
Define what your competitive advantage is and where you should be on top. Then forget about everything else.
Here are a few decisions I took recently:
I am not a Frontend Expert, and I am not a Frontend Architect. I know enough about data management and how to separate concerns to ignore state management libraries in the frontend. I’ll use whichever is by default in my library.
My clients don’t hire me for my UI designer skills, and I don’t care about scaling UI to large teams. I know enough CSS and HTML to use a “ready to use” toolkit. I won’t use TailWindCSS or anything more recent than SASS and Bulma.
First, keep in mind that tech hardly becomes obsolete. Once it reached mainstream status, a piece of tech will stay around for a LONG time.
If you’ve heard about a 50 years old book, you can bet this is a good book, and it’ll be around for 50 more years. A trendy book released last year might not stand the test of time.
Because we hear a lot of success stories about new gadgets, we think we should use them. I think that’s ill-advised. We should ask if the gadget we are going to use is going to pay itself.
When you learn a new tool or a new skill, ask yourself: am I going to be more productive on the first project? Nope, On the third project? Maybe, On the fifth project? You might have wandered to another tool anyway.
And you know what happens to a rumor after a few weeks? You forget about it.
Because the high of learning is so quick and rewarding, we have to use the rest of our brain to think about the long term. Stay away from things you won’t use a hundred times. Don’t even think about it. They’ll come back later, and you can catch up because you’ll have matured on fundamental skills.
This one is the hard part. How can we keep working with our mature and old tools rewarding?
I have a few strategies:
first of all, I work using the Pomodoro Method. Completing a Pomodoro is a reward in itself. Using old tools means I can complete tasks faster and this is rewarding.
Second, I redefined the metrics I focus on, like releasing new code, having more users, etc. This is where makers have an edge against creators working within a company. They can define and align their incentives however they want.
Third, I stay on top of a couple of very tiny circles of interests. This is where I get all my “Software Engineer High”.
If this content resonates with you, we should definitely catch up on Twitter, I’m on a quest to meet more Makers and find a tribe of remote Makers.
Now, can you write down the tools you are going to use for your next hundred projects? Or at least your next five projects?
I’m working on a new article called The One Year Stack, so I’d love to know more about your process. Subscribe to my mailing list below, I’ll send a few updates, and we’ll definitely have a chance to talk.
Founder of Singulargarden, I help my customers release products without creating giant piles of code.
I worry about overly-engineered software, and I hate seeing people waste their time and money. I help junior
and senior teams validate their products with lean and frugal architectures.