One of the characteristics that can separate a successful developer from an average one is the ability to learn and adapt to new technologies quickly.
Transitioning into tech made me realize very quickly that one of the reasons this is such a highly compensated industry is that we're all trying to stay afloat in a sea of constant changes. We're expected to know, learn, and adapt to new information with ease and promptness. New trends, best practices, patches, revisions, a new JavaScript framework coming out every week...
The rhythm of this industry is an insane one to keep up with, and having a strategy on how to learn things can be very useful.
In case you're in a hurry, these are the steps I take:
Table Of Contents
"A smart way to learn"
Coming from a teaching background, I find it inevitable to tie this aspect of software engineering with education itself.
Back when I started learning how to code, it was really challenging for me to put myself in the position of a student instead of that of a teacher. At first, I began to feel some of the same frustrations and challenges I felt when I was in college, I forgot very quickly that I had little techniques, tips, and tricks under my teaching belt.
At some point, I started to feel overwhelmed with the number of new things I had to deal with, so I decided to take it as a challenge instead of a problem and made a pact with myself:
"I'm going to learn this the smartest way I can". Just as my dad used to say: "Más vale maña que fuerza". Which translates to something like "Better brains than brawn".
So today I'm sharing the steps I take whenever I'm trying to learn some new technology.
Here are the steps I take
1. Read the documentation
I know, i know. Many of us are guilty of putting off the whole "documentation" thing. This can be the most tedious part of learning a new technology and we usually don't know how to deal with the boring stuff.
The ability to understand technical language is like a muscle, you have to work it and flex it to get comfortable with it, so the more you read, the less friction you feel with it. More importantly, when reading official documentation you know for a fact that every piece of information there is correct. You can't always depend on the interpretation some random person on the internet gives you.
I put this step first on the list because this is a vital part of the process. The thing is, it doesn't have to be a pain in the backend (I'm sorry, I had to).
You're not expected to learn and understand something just by reading it once from the documentation. It's a process and this is but the first step, so be graceful with yourself here. Scan through the explanations, and try to understand properly what it is you're trying to learn. Check what this technology does and think of how is it useful to you.
If you walk out of the documentation-reading process having just a basic grasp of what the thing is, what its purpose is, what it does, and its basic syntax, you can say you've succeeded in this step.
2. Find it in context (Media)
Now that you know the basics (name, function, basic syntax and capabilities, etc), you should put that knowledge in context.
This is a major step in the process because sometimes these tools can be too abstract and you don't have to reinvent the wheel. One of the most astute observations ever is that we're standing on the shoulders of giants, it would be silly not to use the resources available to us.
This is when you actually go ahead and look for Youtube videos, blog posts, articles; anything written by anyone more advanced than you in this regard and check their explanation. Make sure to be an active listener (I recommend taking notes). Contrast what they're showing with the notions you picked up earlier. This way they're not telling you what to do, but guiding you in the right direction.
Thank god for content creators and the people who answer questions on places like Stack Overflow. You really are the backbone of this industry!
3. Build, build, build
Skip this part to enter tutorial hell...
Listen, you're making an effort to learn and understand something for a reason, right? Well this is make-or-break because one of the best ways to integrate new pieces of knowledge is to practice it.
If you're learning something you can use to build something, you're lucky! Learning by doing is WAY easier than learning by memorizing, and in an industry like this one with regular access to tools like Google, Stack Overflow, and Chat-GPT; employers will look for someone who can build, not recite.
So go and build something with this new knowledge you have. Put it into practice. You're gonna be able to tell how little you've actually retained and when you combine things in your head and put them down in code you're almost going to feel how new neural connections are being built inside your brain like accolades being unlocked in a videogame.
Don't let yourself believe your own excuses here. If it's a really small concept, then all the more reason to build something with it, it's going to be quick and easy. If it's a really large concept, then all the more reason to build something with it, you were trying to get this big concept under your belt for a reason, right?
4. Rubber duck-it
We all know the true difference between an average developer and a 10x-Developer is the presence of a rubber ducky on their setup. So make use of it.
Borrow from the Feynman Technique and try to explain out loud what you just learned, and what you just built in simple terms. Try to explain it so that a non-coder understands what you're doing but, most importantly, try to explain why does your app work.
Yes, it works. Finally! After all that documentation torture you endured, it works. We all know you're a Rockstar, but deep down we all know it most likely didn't work on the first try. We know because it happens to us all, all the time. So don't skip the ugly parts and be transparent with your rubber ducky, explain what was the hardest part, what aspects you're not completely sure you grasp, why did your code fail when it did, and why does your code work now.
Trust me, your rubber ducky won't judge you.
Conclusions
This industry is a fast-paced one and you can (and probably should) set yourself apart by being able to learn and adapt quickly.
Don't fear the documentation, understanding technical language is a skill you develop. Give yourself grace and tackle it progressively. With time, you'll be thankful you did.
Videos, articles, and blogs can be incredibly useful resources, but it's a mistake to rely exclusively on them.
PLEASE DON'T SKIP THE BUILDING PART
Get a rubber ducky! No, but honestly, though, try the Feynman Technique. If you don't have a rubber ducky (shame on you), explain it to your cat, your dog, your cousin, your friends, or your grandma, or be like a Greek philosopher and explain it to random people on the street.
P.S.:
Ok, maybe I went a little bit too far with the whole "Greek philosopher" thing. I mean, we're software engineers, after all, we don't remember when was the last time we encountered another human being... So, you know, just say it out loud.
Joking aside, remember to open your curtains, get some sunlight, touch grass if you can, and go see some friends/meet new people. What you're doing is a hard thing to do and you're not alone in this.
Top comments (0)