While I was working as a PM, I spent a lot of time as a hobbyist programmer, and a lot of time learning about how to engineer good software systems. After leaving that job I spent 6 months or so just building stuff. Games, android apps, whatever I felt like. It was awesome. I turned one of those projects into a consulting gig, then another, then got hired full-time from one of those gigs into a startup where I learned like crazy and sought out as much mentoring as I could get my hands on. I maybe could have done a similar side-step at my previous job, but having talked to some folks about what that would look like, I decided to just jump. It worked out. I hope it does for you too.

I prefer whiteboarding systems design/architectural concepts, which is definitely something I do in the course of my regular work.

We make the game League of Legends, which by various metrics is the most played PC game in the world. That means we have some really fun problems that come with operating at scale, worldwide, 24/7.

We're hiring for a bunch of things (http://riotgames.com/careers) in a few locations worldwide, but I wanted to specifically plug my team, Service Availability. We basically manage all the 'behind the scenes' stuff from data centers to backend microservices. It feels like a tech startup within a game company -- many of our engineers have tech-industry backgrounds (Google, Amazon, Netflix, MS etc).

Engineering blog: https://engineering.riotgames.com/

We're solving problems from the infrastructure layer up, making it easy for developers internally to launch and operate services worldwide, regardless of the underlying hardware/cloud. e.g. building a Docker-based cluster, deployment and build tools, microservice frameworks and interoperability standards, monitoring, logging, and other developer-experience type features. We're also working on services that use that stack to deliver awesome new things to players, e.g. the Riot API. We write a lot of Go, which I'm really excited about.

Our culture is also really interesting, especially for a games company. We've got some Fortune awards etc, but the TLDR is: we have work-life balance, we are focused around personal growth, individuals are very empowered to make change and be part of decision making, and we are very feedback-driven. If you like working in a silo we are not the place for you. We value engineering breadth and the ability to level others up.

If you're a gamer with a tech industry background (you don't have to be a massive League of Legends player, but if you hate the game, you probably won't have a great time working here), you like developer platforms, microservices, distributed systems and scaling problems... we should talk. I'm jlees at riotgames dot com, Jellybear ingame, or you can apply via our site.

PS: Working at a games company surrounded by people who love games as much as you do is really freakin' cool.

Per the original article, minimizing the frictions that make it less likely you'll do something was really important for me. Not every exercise works for everyone - I found that I prefer a group, or solitary, environment and that mainstream busy gyms don't work well for me. Since I can't afford 1:1 coaching, I do the group stuff, but I'm picky about my gym and coach.

When I moved, I did seek out a local weightlifting gym and met with a coach occasionally, but finding a local gym with even a proper squat rack (not a smith machine) was a challenge. I enjoyed doing the Starting Strength program, though dealing with setbacks from illness, travel etc got annoying (I felt like I was always retreading the same ground) and I missed doing more rounded cardio/plyo/flexibility work, so I've since gone back to Crossfit for a while to get my base fitness back up again.

A couple of issues with this approach:

- Make sure your material is good. Bugs in the material led to me repeating myself 1:1 a lot, and having to pause the class occasionally. Which leads to:

- Pausing the class is hard! People are at different stages of the material, so it's hard to find a good stopping point, though I did it a few times when something was either not resonating, or folks were going too fast and I sensed they were copy-pasting rather than fully understanding the point.

- The solution to this is to have 'core' material and then 'extra credit' stuff, but people feel behind if they haven't done all the material; nobody's happy only doing the core. In general, fear of "not keeping up" was a big issue in my class.

- Finally, some folks do learn differently, and you have to account for that. I spent a lot of time 1:1 with a couple particular students who weren't getting the tutorial format. Another felt like class was just "doing homework" and dropped out. I got around this by sending videos in a flipped-classroom approach between classes, but my students didn't have a lot of spare time and I couldn't rely on them doing anything outside class.

If you have the choice between hiring two people for an engineering position, one of whom can write code and one who can't, you'll probably want to pick the one who can rather than training up the one who can't. If your hiring efforts are lackluster, perhaps you can only attract the latter category of people, so you spend a lot on training people to simply do the jobs they're hired for. It's a bit like the Silicon Valley "senior engineers are impossible to find" argument right now. Nobody wants to take the burden of training a junior engineer into a senior engineer if they can hire someone who's already made their mistakes somewhere else. (Not a mindset I particularly agree with, since it implies a failure-intolerant atmosphere, but you get the gist.)

On the flip side, once someone is in a position that they are qualified to do, training for growth and development is a must-have -- 31 hours seems low to me. I definitely spent more than that in learning/development programs at Google, and I don't think that culturally they have an anti-training mindset, but I could be being too generous -- the quote on the site certainly reads exactly like your interpretation.

Continuing to develop while totally rewriting the core leads to wasted effort and a "running to keep up" effect, though allows for a strong technical foundation, provided you actually finish it. Incrementally rewriting the codebase takes longer, but is easier to do in flight, and easy to test in a modular fashion -- and that's already happening.