Learning New Languages, Frameworks, Tools
A question that has been appearing more and more in my life as I have moved into a leadership position is “what is the best way for me to learn X?” It is a fairly innocuous question, but most people don’t seem to have an answer that works for them. I am going to share my thoughts on it, as I have been served pretty well by this process on new projects and jobs.
There are a few components to my formula which I try to follow pretty closely when I pick up a new framework. I will use the example of my recent “Dog Barking Detection” iOS app. It stretched my limits from web engineer to focusing more on the mobile device, which was new and exciting. I also had a lot of success in the project without formal iOS experience. Let’s get to it.
Locate material about the topic, but not too much
My tactic for dealing with the plethora of material that is available on the web is to use whatever material I find as areference and not as the end-all for that topic. For instance, a lot of people in the Rails community talk about Hartl’s tutorial. I’ve witnessed many Rails developers building up a dependency on this tutorial where they are unable to get past the content. By building only the app that Hartl talks about, the individual loses the ability to look critically at the larger picture. I am not sure what a phrase for this is, but let’s call it tutorial paralysis.For me, I didn’t find any full on tutorials that were of value, but piece-mealed my application together organically by focusing on 1 component at a time.
Find an idea you genuinely care about
The only way to get truly involved in a project is to care about the project. This is a simple concept that is overlooked because of the tutorial paralysis that builds up initially. For me, I faced a problem with my dog’s separation anxiety and wanted to build an app to let me track / listen to barking instances, so I can know if he’s healthy while I’m away. By being genuinly committed to the success of this project, I know that it has a higher chance of getting done.Ideas don’t need to be real world or even useful to anyone but you. Just pick something you are interested in and have at it. Another benefit of this is that when you are asked to explain something about the project in an interview, you will have a much much deeper understanding of the topic. This will come off as “on-point” versus talking about someone else’s project that you are only mildly interested in.
Start with “Hello World!” and go from there
I always start any app in a new framework with “Hello world!” This seems silly, doesn’t it? However, this ensures that I can take a managable first step in making sure the toolchain that I will use is setup.The difference is that my “Hello World” project quickly turns into the product that I care about. There needs to be quick agility in turning that working setup into the project I want to work on. This is one of the more interesting ways of how I start off a new project in a new language or framework.
“Going from there” is a pretty large statement in and of itself. The classical approach to this, and one that I believe in greatly, is problem decomposition. My strongest attribute as an engineer, by far, is my ability to rip a problem apart to its core, build that up, and then put it together. In my iOS app, I would focus on what I wanted the app to do next (as a user myself) and then make it happen. I had to overcome difficult technical challenges like dealing with audio along the way, but it was manageable because I broke the problem down and focused on that small bit at a time.
Prioritize that project over all other projects in your free time
There’s no secret here, learning takes time; time that you may not have. If you want to become truly skilled in a certain area, you need to be willing to invest time. That often means later nights with no return other than having something working. Failure will occur frequently but will make way for wins and overall success. You aren’t going to get paid in $, but you will gain knowledge that carriers with you for a while.I suggest getting into a rhythm where you are holding yourself accountable for making sure your project gets done. If you “check-in” with yourself on a weekly basis, and stay true to yourself, you will probably make progress. Remember that this isn’t forever, putting in some time now to benefit your future self is totally worth it and, again, isn’t forever.
Talk about the project
This is one engineers most often skip over. Talk about what you’re working on. Get your co-workers and friends excited about it. Let them know how cool you are for tackling a new problem. Hell, open source it and share the source code with them if you’re willing / able (you probably won’t make money on it so at least consider it).By sharing what you’re working on (probably to people who know what you’re talking about), you will let people know that you care about bettering your skillset. You will appear as more self-starting, determined, and you will hopefully gain confidence in the new skillset.
What have I missed? How do you acclimate to a new language or framework?