One of the skills that I find to be indispensable for a product manager is the ability to learn new things quickly. The reason why this is important is because we operate in an environment where things change constantly, and there is frequently a need to jump in and help with a specific aspect of product delivery that is new. This raises an interesting question - what is the best approach to learn things quickly?
I will preface this post by saying that it’s not about quantifying the education of those that already went through coding bootcamps, but is rather a point of view (i.e. opinion) for those that are considering whether they need to sign up and pay for bootcamps that will teach them how to write software. I am sure there are quite a few people who found success going down the bootcamp path, and I am extremely happy for those that found it to be their preferred approach.
I remember the day when I got my first internship at Microsoft as a program manager. It was such a new concept to me at the time - months before my interview took place I was hastily doing my research, trying to figure out what does a PM do. One of my first explorations in that domain was through a post from Steven Sinofsky - PM at Microsoft. One part stood out:
As a program manager (PM, for short), I had and continue to have the pleasure of working on a number of features across a range of products. The scope and feature direction can change fairly frequently, and it’s our (PM’s) core responsibility to re-adjust and make sure that we design and develop a solution that helps our customers be more productive, efficient, and successful. In Ben Horowitz’s 15 year old post, he states that good PMs are “mini-CEOs” of features and product segments.
I’ll spare you the tacky quote that one could put at the beginning of an essay that tells you how important focus is and instead jump right to the content. I thought some time about writing this - reading Deep Work by Cal Newport pushed me to formalize my thoughts a bit more, the output being this blog post. There is two definitions to focus, each with its own direction. One is related to an inherent ability to segment one’s attention in a way that produces the best outputs.
August already flew by and it’s a good time to finally post the presentation I delivered here in Vancouver, BC, at the Open Source Summit North America 2018. This year, it so happened that I had the pleasure of doing two rounds on the same topic - Docs as part of the product: open-source documentation at scale. The two rounds were: A lighting talk, giving a high-level overview of where we’re going with open docs.
Prompted by a Reddit thread, the question in the title seems to be a fairly common one among Computer Science undergrads as well as those that are just now starting up in the field - What programming language should I choose? Is there a possibility that I will choose the wrong one? Should I learn one or many?
As someone who is almost (and by almost, I mean months away) from finishing my undergraduate program and starting as a full-time Program Manager at Microsoft, I feel like the past 4 years have really been life-changing for me, both from personal and professional standpoints. It’s been a rollercoaster, and I happened to be lucky every second that I’ve been on it.
Back in the day, December 8th, 2008 I decided to join Dream.In.Code. What was the reason? Just for fun, in the first place. I wanted to see how many people I can help with programming issues, how many articles I can write and how many pieces of reusable code I could submit.