If you’ve read my blog, project posts, or weekly updates over the past year, you’ve probably noticed a heavy focus on learning JavaScript. About a year and a half ago, I decided I wanted to move more towards doing more development-oriented work at Automattic.
I’ve never been shy about talking about this. I’m a bit believer in sharing goals out in the open versus keep them close to the chest. I thought I would share my initial thought process and how I’m currently approaching the goal for anyone that might be interested. One warning before we begin—this is just my experience. Your mileage may vary.
A Bit of Backstory
In January 2015, I set my sights on a goal: Become a JavaScript developer. In my head, it would look something like this:
- Take some online courses.
- Build a project or two.
- Work as a JavaScript developer at Automattic.
I toyed with the idea of completing a Nanodegree or going to a full-time coding bootcamp while also balancing work at Automattic, but eventually, I decided to just go with Treehouse. I finished both the Front End Web Development and Full Stack JavaScript tracks. I built some super duper basic JavaScript projects (I really can’t emphasize just how basic they were). I had progressed miles from my original skill level. Ready to rock n’ roll right?
Around October of 2015, I started to dig into Calypso, which is a API-driven remodel of the WordPress.com front-end. It’s written in JavaScript, which was right up my alley (I still don’t know much PHP at all).
My thought process was pretty simple. If I was planning on being a contributing JavaScript Developer at Automattic, I should probably have a solid understanding of our main project. Makes sense. Time to dive in!
There was an immediate gut check the first time I tried to fix a small bug. I realized I was the walking representation of this quote from Mo Jangda (ref):
From what I’ve seen, attendees of bootcamps leave with two things: intense passion to go out and build things using their newfound skills (awesome!) but also an overestimation of what their current skills are actually capable of (not-so-awesome!).
To talk psychology for a second, I suffered from the Dunning-Kruger effect (h/t Simon)
A cognitive bias in which relatively unskilled persons suffer illusory superiority, mistakenly assessing their ability to be much higher than it really is. (ref)
This isn’t to say that the Treehouse courses were for naught. The journey would just take longer than anticipated. Basic projects weren’t a sufficient substitute for contributing to a living, breathing project with dozens of developers—the kind of work I would be expected to do.
Automattic hires the best developers around the world. I was going to need more than a few online courses to even get in the same universe.
The Two Hurdles I Hit Learning JavaScript
I share the backstory to highlight two main hurdles I ran into:
- If you’re thinking of pursuing a developer role through online learning, it’s important to realize just how long the road is going to be. Finishing an online course is just the beginning.
- Moving from A) Finishing an online course to B) Squashing small bugs to finally C) New, creative feature development as a full-blown developer is very, very hard.
The first piece was difficult to swallow. My naive mind envisioned a year and a half or so of work. Realistically, the timeline is more in the 3-5 year territory.
While I’m working on JavaScript, I can’t set my current work as a team lead/Happiness Engineer aside. I needed to figure out how to approach learning JS while excelling in my current role. To efficiently juggle the HE lead role and my JavaScript ambitions, I setup some boundaries.
- Any JavaScript coursework would not be considered working hours.
- If I’m contributing code directly to something that relates to Happiness/Customer Support, that falls under my traditional work, but it’s limited to 2-3 hours a week.
- In order to keep improving, I would need to log at least 5-10 hours a week on code projects (I use WakaTime to track this).
These boundaries helped me to create two separate buckets:
- Jeremey as a newbie JavaScript developer
- Jeremey as a Happiness Engineer
Having two buckets gives me peace of mind. I know when I’m working on JavaScript, I can be fully focused on the task at hand without worrying about my Happiness Engineer role and vice versa. In practice, this means separate todo lists and separate calendar blocks.
The second problem (moving from finishing an online course to working as a full-time developer) is a difficult problem to solve. After finishing the basic steps and realizing how far I have to go, I was left with a pretty simple question: What next?
Based on everyone that’s been kind enough to give me advice and everything I’ve read, the answer boils down to two words: Build things.
My Current JavaScript Curriculum
With the ultimate goal of “build things” in mind, here’s what the work actually looks like:
Surrounding myself with info. I picked up this tip from my colleague Hew at Automattic. I follow internal blogs related to Calypso development even if I don’t understand them 100%. I’m reading virtually everything I can get my hands on (JavaScript: The Good Parts came highly recommended and has been awesome). I’ll post a list of favorite resources later on.
Following commits. I’m lucky in that Automattic has some of the best developers in the world and the codebase they primarily work on is completely open source. A few days a week, I’ll pick a larger commit to explore and read through it until I have at least a vague understanding of what’s happening.
Write down. Look up. Repeat. Applicable to both of the above, I have a Simplenote file that I use to track words/phrases/concepts I’m unclear on. Once every week or two, I look them all up and try to find ways they’re used in Calypso to help solidify my understanding. Recent words on my list: bind(this), fat arrow syntax, require vs. import, and componentWillReceiveProps.
Contribute. There’s no substitute for actually submitting code to Calypso. Pull requests are the main quantifiable way to say “I’m learning.” I set a rather ambitious goal of 80 PRs. I figure the only way to hit 80 is to learn…a bunch. Plus, if I submit a PR, I’m virtually guaranteed to receive feedback from a world-class developer.
Ask questions. Previously, I was under the impression that a pull request had to be perfect before it was pushed up. Now, if I’m completely stumped, I’ll push up a PR, add the “In Progress” flag, and openly ask questions. Obviously, there’s a balance here right? I’m not going to throw up some code and say “I have no idea—can someone tell me how to solve this?”
All-in-all, I’m looking at around 8-12 hours a week reading about or working on JavaScript-related projects. While that’s great, I am failing in the “Build stuff” department from the perspective that I’ve solely been working on Calypso. I haven’t actually built any standalone applications with what I’m learning.
Here’s the Accountability Piece
I talk a lot about goal setting. In my monthly updates, I’ve continually talked about this super basic todo list project called Theodoro. Again, it’s very basic, but it was helping me to learn about state, props, and all things React.
If I don’t ship a finished product by June 15th, I’ll donate $150 to Girls Who Code, which feels like a relevant cause.
Help me out and keep me accountable!
Photo Credit: Calypso GitHub Repo