A developer’s life is a never-ending saga of learning new things. It’s like you’re playing Diablo where every new Jira ticket can feel like the next mini boss to slay. Exciting? Absolutely. Scary? Sure. Especially at first.
Why do we resist learning new things? 🔗
We’re creatures of comfort. We like what we know, and the unknown can be as intimidating as a null dereference in prod. But here’s the deal: the software development industry moves fast and there’s a near-infinite amount of stuff to learn. This isn’t mechanical engineering. We have 3 new JavaScript frameworks per day people.
Imagine this. You’re squaring off against another candidate for a job, and you both are qualified in that you check all the boxes in the listed job requirements (I know, super unrealistic). The only difference between you two? They know a heckofa lot more about the non-essential stuff than you do.
Who do you think the employer will choose?
The necessity vs curiosity dilemma 🔗
Now, I’m not saying you should learn every design pattern, language or tool that comes onto the scene. What you need is a balance between necessity and curiosity.
Before you panic about not knowing the ins and outs of Kubernetes or TensorFlow, remember this: you don’t need to learn everything before getting a job. Real growth happens on the job, through tackling real problems, not hypothetical ones.
But if you want to stand out in this vast sea of developers, a spark of intellectual curiosity can be your purple cow. Go ahead and explore an interesting algorithm, RTFM when you’re working with a new library, or take a minute to watch FireShip’s latest video about that language you’ve been eyeing. You might be surprised by the doors it can open.
Increasing your “starting point” 🔗
Learning isn’t about hoarding answers like Scrat hoards that acorn. It’s about pushing the boundary of your ignorance a little further with each passing day. I like to call this your “starting point”.
Think back to when you first started coding. You probably spent a lot of time googling basics like “how to write a for loop” or “what’s a git branch?” (We’ve all been there, no shame.) But as you learn and grow, your starting point moves ahead. Now, you’re probably googling something like “how to specify a PUT endpoint in the go-CHI library” or “best practices for asynchronous error handling in Node.js”.
See the difference? Your journey from ‘for loops’ to ‘PUT endpoints’ is a testament to your growth, and each new concept or tool you learn pushes your starting point even further. You’ll never be done Googling or asking Chat GPT, but you’ll be able to tackle more complex problems more efficiently with each passing day.
Take the scenic route 🔗
Learning to code isn’t part of the problem set solved by Dijkstra’s shortest-path algorithm. You don’t need to find the shortest path to success. Taking the scenic route isn’t just okay, it’s better in the long run and can be good for your career.
Dare to venture off the beaten path. Those side quests where you learn a random library because it looked cool, or spend a weekend building a game in a language you just stumbled upon, can do wonders for your skillset. Even if you never go on to use those tools again, you’ll have learned a new way of thinking about problems, and that’s invaluable.
Each time you solve a new problem, or the same problem in a new way, you add flavor to your developer identity. Plus, that random knowledge often magically pops up in interviews and projects.
Moving forward, not sideways 🔗
Now, while I encourage you to embrace deviations, it’s crucial not to lose sight of your core learning path (If you’re a Boot.dev student, it’s probably this backend learning path).
You don’t want to end up in tutorial hell.
Ah, tutorial hell. The Bermuda Triangle of coding, where you’re lost in a sea of online courses and YouTube tutorials, endlessly copy-pasting code without truly understanding anything. The only way out of tutorial hell is to continuously progress along a learning path so you can make sure that you’re actually learning new, important things.
Well, that and you need to actually build something. Lots of somethings. Lots of somethings where each step isn’t spelled out for you.
Embrace learning, embrace growth 🔗
As developers, we’re not just coders—we’re lifelong learners. It’s part of the job description, like being able to survive gruelling Scrum meetings.
So, don’t shirk from learning new things. Embrace it. The fear, the excitement, the occasional frustration, it’s all part of the package. And remember, you’re not running away from learning. You’re just taking a consistent jog towards success.
