How I Learn a new Framework/Tool
Inspired by my recently started journey in node.js.
Begin by finding that new π₯
If you're looking for something new to learn, I may not be able to help you. You're on Dev.to and there's hundreds of other bloggers with really cool new projects. We're going to assume you've already completed this step.
Phase 1: Getting Startedπ
Now that you've selected your new toy, find out a little more about it. Open your favorite search engine and yeet that framework's name right into the search bar and smack that space bar.
After you read the first link, which is of course their site/git/nuget/npm/pile of post it notes/twitter, realize you need to add "tutorial" because you have no idea what's happening right now.
That last part is important because it's a trigger. You're going to need to make a nice big [ glass | mug ] of your favorite [ beverage | ( coffee | tea ) ]. Take a sip, the journey begins!
Phase 2: Onward to Excellence π
Now that you've got a nice big list of results, ignore everything else on the page and go to the first one. Don't worry about learning styles/getting to know the tutorial author, it's all the same.
Phase 3: Do All the Things π€
Diligently read each step of the tutorial at first. This is super important as following the instructions will walk you through the basics of the what you're trying to learn. It's important to understand these fundamental concepts before continuing. Keep in mind the tutorial author does not know what you know or don't know, so there may be some early sections you will want to skim, but make sure that you're not missing anything. Lord only knows what weird thing is different about this framework, behind that keyword you recognized is an ocean of code.
Phase 4: Get Super Bored π₯± *
Maybe you have a few things under your belt, maybe you just got started, but code is code and changing a few variable names couldn't hurt, right? Just go ahead and start renaming things. I mean, they're only variables.
And what's with all of these paths and files? Just store everything in the root directory. This is supposed to be a quick jog through the basics, you know this all already. Just toss everything in a pile, you can clean it up later.
Or maybe the organization of the tutorial isn't what you like, just stuff it into another folder and re-use some shorthand. Personally, I use the Seussian "thing" naming pattern. You'll never run out of variables iterating through "thing1", "thing2", "thingN", or if you're feeling frisky "thingBuzz". If your language supports emojis, definitely use those. There's no reason why you can't iterate by doing a foreach(var π©βπ in π)
Seriously, just go nuts here, gotta keep it interesting.
Phase 5: Debugging π¦
All right. If you're like me, you're now somewhere around 10-15% of the way through the tutorial, but there's red squiggles and things aren't compiling.
π π DO NOT PANIC! π π
There's probably something clarifying what your [ linter | debugger | whatever that thing's called ] is complaining about on the page before that we've skimmed through. Just take a step back and read through it.
This is a perfect time to get up, stretch, refresh your beverage, pet the cat, walk the dog, water the plants, or check Twitter. Go ahead, I'll wait.
Are you back? How's the pet/plants? Anything fun on Twitter? Did you bring me a coffee? No? Ok, fair enough. Now, start searching all those errors. To save you a step, remember to put the framework at the end of the query. If that doesn't work, just search the framework and "github". There's probably an issue out there that is exactly what you're looking for because there's no way it's not working because of the previous step. Trust me, we've all been there.
Phase 6: Return to the Tutorial π©βπ«
All right, so, that didn't work. Let's give the devs the benefit of the doubt, they probably know what they're doing. I might have lead you too far afield with using emojis in code, that was my bad. Find the tutorial you were reading before, copy the example code and pop it into your IDE.
Phase 7: Guide Rails π
Search your IDE's extensions/plugins for the framework. Add as many as possible, we've lost precious minutes already. Bonus points if the framework provides one specific to your IDE. A good benchmark here is at least five plugins to ensure success.
Bonus Tip: Write down these extension names on a post-it note, you'll need that for a later phase.
Phase 8: De-clutter your IDE π
Got that post-it note? Yeah, me neither.
Either way, these plugins are not bringing me joy, so away they go. Just get rid of anything that's not from the framework provider.
Phase 9: Find Another Tutorial π
But keep your old code. You're going to need it. Copy it and rename it the same with a 1 (e.g. app1.js, index2.html). Don't worry about referencing other files, we're not coming back to them and they're only referenced by that one folder.
Well, that's not true. As you're starting the new tutorial, skip the first few pages as you were just in another one and there's probably nothing new there**. Adapt your other files as you can, but there'll be clarification if you can find roughly the same spot in this tutorial equivalent to where you were in the first one.
Phase 10: Goto Phase 3 π‘
All right, off you go now. Repeat the previous steps with a new tutorial until you get back here at least 2-3 times. If you're just returning, go ahead to the next phase, I don't have anything witty here.
Phase 11: Return to the Original and Complete π
Now that I think about it, let's go back to that first tutorial and finish it. I mean, really finish it. Delete everything, and start with step one. Definitely read the details even if it's not new to you at this point, that debug step was probably confusing.
Once you've made it through one tutorial, head back to one or two of the others and give them a shot. With a few under your belt, you'll grasp the basics and now it's absolutely time to implement this at scale! Add it to your LinkedIn and start drumming up use cases!
(If you made it this far and wonder what the joke is, this is legit how I do it and there's some problems with my methodology. Send help/coffee!)
* Tutorial authors: please don't take this to heart. I'm a fan, really. If it weren't for your efforts, I wouldn't know anything about how programming works.
** For real, tutorial authors, you're the real MVP here.
Top comments (0)