Learning how to learn

While not strictly relevant to the post, amazing song.

While not strictly relevant to the post, amazing song.

My dad asked me a few weeks ago, "What are you going to do if Android dies out?”. As someone who can really claim to be an “expert” at just Android, I should have browned my pants at the thought. Thankfully, I didn’t. I wasn’t even perturbed. I could even go as far as to say that I was a little excited with the thought of what that tech landscape would look like.

It isn’t a question of whether Android was going to die out, it was just when. This is especially true in the tech industry, where it's ridiculously easy to evolve. And while that could be a different post in itself, it was pretty self-assuring to know that I wouldn’t be stunted then. As much as I try to keep myself at the bleeding edge on Android, I also try to actively broaden my scope of knowledge. Knowing enough to talk intelligently on a particular subject or technology is a big plus in my books. Being a jack-of-all isn’t so bad if you’ve inculcated a mindset of being open to learning about new things. You just need to *roll credits* learn how to learn.

For the past couple of months at Staples, I’ve been doing legwork around setting the stage for a new product that we’re going to roll out this year. A plethora of items had to be checked off by my team to make sure that what we were trying to do was actually viable. Micro-PoCs (proofs of concept) were the order of the day. Whether it was hardware or software, a management or technical tool, we took essentially the same approach to each item:

  • Absorb existing documentation/resources of the item.
  • Set up the environment.
  • Get the barebones, "Hello World" equivalent working.
  • Come back to our use case for the tool. Play around with it enough to say that there were no deal breakers.
  • Document what we learned/ save the project in the safe place.
  • Rinse and repeat.

In our case, this cycle took anything from a couple of days to a few weeks, depending on the complexity of the tool and our own use cases. By doing this, we’ve quickly covered a lot of ground around exploring tech necessary to make our primary product work. And the approach did work. We were able to iterate quickly around items to get critical pieces of information.  This resonated well with what I had read in Little Bets, and what projects like Google[x] were founded upon.

All this isn’t to say that there is no place for those with deep knowledge in subjects. They’re the ones that you call when you need to get sh*t done, and done well. But even domain experts can benefit from knowing just enough about their surroundings.

My academic career might be over, but the learning has just begun.