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
- Take some online courses.
- Build a project or two.
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.
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.
- 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 Happiness Engineer
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.
With the ultimate goal of “build things” in mind, here’s what the work actually looks like:
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?”
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