The career-changing art of reading the docs

Interesting article:

Also discussed in this podcast episode:

A quote from the podcast episode:

There’s this really interesting trait about me in my career, that I’ve only kind of realized in the past couple years… And that is that I’ve never had a software engineering job where I’ve been in a junior engineering position. Every job I’ve been at, I’ve been the most senior person on the team as far as knowledge and expertise in whatever we were working with is, whether that was Drupal or Go… And I think pretty much all of that is owed to me sitting down with the documentation and pushing myself through and continually learning, not because I needed to solve a problem right now, but mostly because I was interested in how things worked, and dug into them, and sat down and was like “Alright, this thing is bothering me, that I don’t have this knowledge right now. So I’m gonna go and really acquire this knowledge.” And you wind up where you’re trying to acquire one piece of knowledge and you acquire a ton of ancillary knowledge around it…

I think that’s the kind of mindset that I had that led to me being so senior most of the times, because everybody else around was doing the thing I just mentioned, where they just go and ask someone to answer a question that they had right now”, and then “Oh, my question is answered. I’m not gonna have to dig around anymore.” And I think when you have to dig in the docs, you spend a lot of time finding other things and asking other questions. And as soon as you kind of jump from question to question to question, you just kind of grow your knowledge base. And that’s what I feel I’ve done in my career, and that’s what’s led me to this kind of peculiar position where I’m just like “Yeah, I’ve never been in that junior engineer position, or that intermediate engineer position.” It’s always everyone else coming and asking me, “Oh, how do we do this? How does this work? Can you design a system that solves this problem that we have?”

Another quote:

I wanna give two examples, because I have one that is non-software and one that is software. So my non-software one kind of dates back to my days in college, when I was a freshman. At my college we’d gotten this brand new television station, so no one knew how anything worked in it… And I joined up and I was like “Oh, this is all so cool!” and there’s this thing called a video switcher, which if you’ve ever seen a picture of a television station or TV studio, it’s that thing with all of the lights and the buttons…

Yeah. So it’s actually pretty simple, but it looks crazy… And I saw that, and I was like “I wanna know how this thing works.” So I sat down and I literally pulled out the manual and started reading it, kind of cover to cover… And I had no idea and didn’t understand anything for like the longest time, of just like reading it… And I’m like, “I don’t get it. What is all this for? I am confused.” But after a couple weeks of just sitting down and doing that, all of a sudden I was the most knowledgeable person in this station about how this switcher worked… And it felt super, super-good, because everyone else was now coming to me with questions about “How do we set this up? How can we do this?” and we got to do all this really awesome graphics stuff that we couldn’t do before, because now someone had acquired the knowledge of the switcher.

I think that’s one of the earliest times I can remember sitting down and pushing myself through documentation until I understood something… And I think that level of perseverance and the payoff I got from it motivated me to do the same thing with Drupal… Which for those of you that don’t know, Drupal is a content management system and it’s written in PHP, and is probably one of the most complex pieces of software that exists. Its learning curve is absolutely atrocious. You will spend so long trying to figure out how anything is working, and it will still be confusing. But it has a ton of really good documentation.

I remember over the course of the summer before I became a real software engineer, I was just reading the documentation over and over and over, and none of it made sense… And I think at some point I was literally screaming “Why aren’t you working?!” at my computer. And then kind of as Ian was saying, as I went through things over and over and just kept digging and digging and trying to figure out how things work, things just started to make sense. And as I kind of alluded to before, that’s literally how I managed to get my first job as a software engineer, just because I understood how Drupal worked. It was super-hot at the time, and people really, really wanted people that could actually go in and build custom modules and do things with Drupal.

So I think this topic of documentation is super near and dear to my heart, because it’s one of those things that allowed me to become a software engineer in the first place.

This is no substitute for really understanding how things work!

A related article: