Learning To Use New Tools

I love building software, especially on the web. The features that have come into the web stack are phenomenal, and with that has come an explosion of available build tools, libraries, frameworks, and different paradigms for how they should all be used. Given the rapid changes we see, it is very difficult impossible to keep up with all the latest rages. This is why I have a fairly rigid set of steps I follow in order to help me learn to use a new tool. For the TL;DR version, I haz slides :)

Learning to use new tools isn't specific to software, so I've attempted to write this more as an abstract instead of strictly software-specific.

Ask WHY?

"Why" is usually a good question to ask yourself before making decisions. Why change that job? Why move to that new location? Why buy that goldfish your toddler is begging for when you know the end result is a fish down a toilet? These, and many more, are some typical questions we'll likely ask ourselves many times during our lives - especially those of us that have goldfish-loving toddlers.

One area in which I try to ask myself "why" is with learning to use new tools. I only have so much time to dedicate to learning new things, and I only have so many things I'm capable of learning at any given time.

Why do I want to learn this [shiny new] tool?

Here are some common reasons people learn to use new tools:

• The tools I have aren't cutting it
• To increase my versatility and further generalize my skillset
• To accommodate client needs/preferences
• To help facilitate a career change
• It's the new hotness in my field, so I haz to!

While most of these are fantastic reasons to learn to use new tools, let's take a quick second to understand the "what" - what exactly does it mean to learn something? There are actually several accepted definitions to the term learning. One definition that resonates well with me is

Learning is a process that depends on experience and leads to long-term changes in behavior potential. ^[1]

At the heart of it, if I don't believe a tool has the potential to change my long-term behavior, I don't invest much more time into it than a cursory overview. I'm not out to switch to the latest hotness every quarter - which could be easily done in the JavaScript world. My endgame is to focus on learning those things that will help me alter long-term behaviors to make me a better developer, or a better husband, or a better father - or all around a better person.

Getting Started

Once I've determined that it is worthwhile to really learn to use this new tool, I do a couple of things to prepare:

• Find solid resources to look to when stuck. This may be the project docs or, more often, folks on twitter.
• Look back at things you've already done with similar tools. I'll elaborate on this a bit more later.
• Look at already-implemented solutions from others to common objectives - i.e. tabs, modals, forms and validation, etc... However, intend to do your own implementations as needed and cite where ideas or techniques were gleaned and reused. It's good to look at how others did it, but even better to do your own version and use theirs as an aide.

Learn by (Re)Doing

One way I prepare to learn a new tool is to

Look back at things I've already done with similar tools

This is important in how I approach learning new tools. I have a set list of things that I've implemented with other technologies, so I'll use that as a roadmap of sorts for how to dig deeper than the simple hello world or TODO apps. In fact, it's actually a small application that I just rewrite using the new tool. This approach yields many benefits (after the very first implementation, of course):

• Lessened burden of creativity: I don't have to spend the first xteen hours trying to come up with what to build in order to learn some of the innards of the tool - I just build a new version of what I've built before and only focus on the how!
• Clear directives and expectations: I've built this app before, just with different tools, so I already know exactly how it should function and generally look.
• Solid roadmap already in place: Once you've built something once, you gain the benefit of 20/20 hindsight! The order in which you build your components, models, etc... will be much better in subsequent builds.
• Higher chance at success: Starting out of the gate where all you really have to focus on is the new tool itself, rather than what you're building with it, is a big head start. You're much more likely to actually finish the app.

If you are new to this approach and you need to build the first iteration of an app, here are some things to keep in mind:

• Don't over-build! I can't stress this enough... It's easy to start a project and have it stay in the "in progress" status for years! While that's ok for other objectives, I don't believe it suites this purpose well. Come up with something you can build in spare time over 2-3 months or less. A project specifically for digging into a new tool is not really the time to start on the next big thing :)
• Don't go down the rabbit-hole of all related tools. For instance, if you're looking into React for the first time you'll see things about Flux architecture, RxJS, etc.. and if you're digging into node for the first time you'll see things about npm, bower, browserify, webpack, etc...
• KETGID - Know Enough To Get It Done! You don't have to dig into every nuance of the tool - just build the app you've come up with, then stop and reflect. If you decide to continue using the tool for future projects, you'll get the opportunity to dig deeper.

So, the app I use is a Mortgage Paydown Calculator. My first programming job was at a mortgage company, so this is basically a carry-over from those days. The company had this excel sheet available for download on their website; you could plug in your loan info and where you wanted to make extra principal payments and it would calculate how much time and money you'd save. I thought it'd be cool to replicate it in a web app.

So far, I've built this app using these tools (built in order listed) and learned some important things along the way:

• KnockoutJS - View App
• I was so new to JavaScript when I built this - the code is likely awful! But, I was coming from ASP.NET Web Forms and MVC, and knew I wanted to do more with the front end than just the little bit of jQuery I was doing.
• I learned about client-side templating, view models, prototypal inheritance, and declarative data-bindings.
• AngularJS - View App
• After working with JavaScript more, and writing more and more with vanilla JS and libs like jQuery and Knockout, I realized that the code I was writing was messy and hard to maintain. I was learning to use some techniques and patterns (IIFEs, Revealing Module, Singletons, etc...), but it just didn't feel clean.
• Angular really helped me learn better approaches to structuring a JavaScript app. I like the way things were broken into modules and each module specified other modules it depended on. I love the idea of services and filters.
• iOS using Xamarin & C# - No link for this one, was built as POC
• and most recently ReactJS - View App (not quite done yet, but mostly there)
• I am really starting to see the benefits of uni-directional data flow, immutable properties, and other paradigms React is helping me learn. Even if I don't switch to React, I plan on applying some of these principles in my future projects.

Altering Behavior

Once I go through the exercise of deciding to learn a new tool, finding resources, and learning by redoing, it is then time to assess the outcome and potentially alter my behavior moving forward.

• Take note of areas where the tool had weaknesses and strengths.
• Discern the appropriate scenarios for using the tool - there is no golden hammer.
• Form strong opinions grounded in your experience, but don't be unwilling to change them.
• Don't be afraid of being wrong. Even if your initial opinion(s) are wrong, the fact that you care enough to form strong opinions is a good sign you'll care enough to adopt better ones you come across :) This, the fear of doing it wrong, was a big hindrance for me for the first few years of my career - if you only get one thing from this post, let it be this.
• Don't be afraid to incorporate paradigms from the new tool into usages of old/other tools. For instance, I'm finding I really like the notion of immutability that exists in React. I also really like a lot about Angular. I intend on adding immutable data structures to future Angular apps where applicable.

I sincerely hope this is helpful to someone, or at the very least thought-provoking. Do you have a specific set of exercises you go through when learning a new tool? I'd love to hear about it! Please discuss in the comments, or ping me on twitter @dotNetKnight!

-Bradley