How to “level up” as a developer? Man, I love articles that cover this topic.
“Code every day.”
“Drink yerba mate.”
“Use a mechanical keyboard while listening to lo-fi.”
I’ve heard it all. You’ve heard it all.
The internet is full of tips & tricks that promise to transform you into a mythical 10x developer, with Docker building itself out of respect for you.
In reality, most advice is generic, performative, or just pure nonsense. (Shout out to @Jake Lundberg and @Kaye Alvarado, who compiled a list of useful tips on becoming a better developer in their posts So You Want To Be A Better Developer? and The Roadmap to Being a Better Developer. Both are well worth a read, packed with advice and fresh perspective.)
But some things do actually work, especially if you’re looking to become a better coder, a problem solver, and a teammate.
That’s why I created a list of 6 proven-to-work tips to help you become a 10x (or at least 2.5x, realistically) better developer.
Please note that this is by no means a guide on becoming the best developer out there. These are just suggestions that improve skills as a developer. Try them and see if they work for you, as well.
1. Learn to enjoy boredom
Real development is eye-roll-worthy. Glamorous product launches and elegant PRs happen every few months or so, but it’s mostly:
- Debugging someone else’s 3-year-old spaghetti code.
- Waiting for builds.
- Wondering why your local works, but staging is on fire.
And when you’re asked to work on tickets everyone avoids (legacy migration, update dependencies, or investigating weird prod issues), as a real pro, you shouldn’t flinch. Instead, you should lean in (no tantrums!), breathe, and get to work.
Do them without whining. Do them better than anyone else, and document the path like it’s the easiest task you’ve ever been given.
Real pros don’t cherry-pick cool work; they immerse themselves in the ecosystem (and hope for the best).
Bonus tip: If you have masochistic tendencies, try reading code that hurts your brain and then ask why. Find a GitHub repo that makes you squint and clone something written in Rust or Elixir or Haskell just for the pain.
Read legacy code from a project and try to understand what the person who originally wrote it was thinking. That’s how you’ll develop better instincts for readable and maintainable code.
2. Stop trying to prove you’re smart
You can write a memoization function while talking to your dentist on the phone. Yay for you. But if your teammates need a whiteboard and 3 cups of coffee to understand your code, you’re not a coding superstar but a burden.
Next-level devs write obvious code that happens to be clever, not clever code no one can decipher.
3. Respect your time
Time tracking is the last thing you want to think about, I know. It takes away your sense of autonomy, and frankly, feels like Karen from HR is watching you.
But the thing is, most developers have no real idea where their time goes. You sit down to fix one bug, and suddenly it’s 4 PM, your desk is covered in empty coffee cups, and you’ve accidentally written a new CLI tool. Happens to the best of us.
That’s why you should be eager about understanding where your time actually goes. (Spoiler alert: it’s not as much deep work as you think.)
You can use Memtime for this purpose because it runs quietly in the background, capturing what you work on (apps, files, docs, etc.) without interrupting, or judging if you spend more time than you should on Stack Overflow.
4. Schedule “do not disturb” time
No one is going to give you uninterrupted hours; you need to take them. Block time in your calendar so you can work in peace. And call it however you want (mine’s called Focus block).
You need separate time for deep work so you can get into flow, and if you’re not convinced this is a good idea, read again Flow: The Psychology of Optimal Experience by Mihály Csíkszentmihályi:
5. Give better code reviews than you receive
The ultimate mark of a confident, leveled up developer is giving code reviews that actually make people better.
Not reviews that say:
- Can you rename this to something more descriptive?
- Lint issue.
- Nit.
Be the dev who explains why something matters, who suggests better patterns, and even sprinkles in a compliment because hey, humans wrote this code.
6. Pick your battles
You’re gonna be in meetings where someone suggests something that feels wrong.
Perhaps it’s a little off. Perhaps it’s wildly chaotic. And your inner dev wants to stand against it.
But, please believe me that, sometimes, professionalism is knowing when to let it go. Maybe that crazy idea is a business decision that will be thrown away next quarter. Maybe the idea is good enough to survive (and later thrive).
You need to learn to pick your battles and save energy.
And if it all burns down later? Just smile and say, “Huh. Weird.” 🙂
Conclusion
Becoming a 10x developer means consistently showing up, paying attention to what actually makes a difference, and doing the boring stuff well.
Yes, your code matters. But your habits? Your systems? Your ability to focus and not mentally combust mid-project? That shows you’re the true MVP.
I hope a few of these ideas help you sharpen your approach or see things from a new angle. And if they inspire you to rethink how you work, I’d genuinely love to hear about it.
Thanks for reading the post! Until next time—stay curious, not furious, and keep building.
Top comments (0)