The growth curve

Some experiences are more equal than others

(Like this article? Read more Wednesday Wisdom!)

My numerous gray hairs are proof of a lot of experience. Multiple decades of experience, in fact. This regularly impresses people, especially those who were born after I started my professional career :-). We set a lot of stock by experience; job listings typically mention requiring a particular range of experience with certain technologies or in particular roles. The assumption is clearly that experience leads to mastery.

Sometimes it does.

However, there is a reason we still interview and that is that a number of years of experience does not necessarily translate linearly to a particular level of expertise: One person with ten years of experience does not necessarily equate another person with ten years of experience, not even when that experience is matched to the same keywords. What matters more than years of experience is what this experience actually entailed and what sort of growth was fueled, if any.

We expect that experience leads to growth, and it often does, but the growth curve can be shaped very differently depending on what was experienced and if you managed to learn something from what transpired. When I got hired by Google in 2006, I had 18 years of experience already. However, for most of that time my personal growth curve was kinda flat in the areas that are really important for being successful in Big Tech.

In the 18 years since I graduated and before I joined Google there was not a lot of rhyme or reason to my career. I mostly worked as a consultant on projects with a variety of customers; sometimes for a few days, sometimes for a few months, usually adding knowledge or hands-on experience to whatever was going on. I typically did not have any project responsibility other than fixing some technical problem or explaining some technical thing. In these roles you get an enormous amount of exposure to different platforms and technologies. You also spend a lot of time solving technical problems, from which (if you do it the right way) you gain a lot of in-depth knowledge and practical (hands-on) experience.

My other big gig in the 1990s and early 2000s was teaching courses. My company provided trainers for the education centers of HP, Sun, Digital, and a few other institutes, teaching whatever needed to be taught to generations of programmers and system administrators. The list of courses I taught is impressive and includes esoteric ones such as NIS+ Administration, HP-UX kernel Internals, Visual C++ (with MFC), Programming with XLib, Microsoft System Management Server, Netscape Certificate Server, and Managing MC/ServiceGuard. As you imagine this also did wonders for my knowledge of, and hands-on experience with, lots of different systems and programming languages. It also ensured that we kept our knowledge up-to-date, because as soon as something new came out there was a course for it, which we needed to teach.

It all was a lot of fun, but ultimately not very fulfilling. All of that work fueled my growth as a technologist, but it was very one-sided. Additionally I was typically not exposed to the best people in the field as I was often hired to be the best technical person in the building.

Remember: It is not hard to shine in a dim room. 

Here is what I did not get any experience in during my pre-Google days: Working in an organization with great people to set goals and deliver on a big and complicated project.

Because of the nature of my work, there were also some strange gaps in my technical knowledge. For instance you can teach all the C++ classes you want, but that will not give you a lot of practical exposure to testing. I also knew next to nothing about version control systems or release engineering. I could totally write a device driver for HP-UX, but really had no idea how CVS worked. 

All my technical knowledge and experience helped me ace the Google interview, which (at the time and for my role) focused entirely on Unix internals knowledge and on coding short snippets in C and shell script. Google ended up hiring me as an L4 SWE/SRE. An L4 is a skilled individual contributor to who you can give a complex task, after which you will only hear back from them when that task is finished or when things are seriously blocked. This might seem to be a very low level for someone with my level of experience, but (mostly after the fact) I considered it a fair leveling decision because, even though I was very knowledgeable and experienced with all sorts of technologies, I really didn’t know the first thing about being a tech lead or running a project.

I had all this knowledge and hands-on skills, but I had zero experience in using that together with other people to build something big and complicated.

The next few years totally turned the tables and fueled an incredible amount of personal growth. At Google I was exposed to very smart people and we were building and running very large and complicated distributed systems. I had few problems understanding the technology, but had quite a mountain to climb to become an effective team member and, later, effective tech lead and manager.

All of this taught me that people’s growth is a function of the challenges they face and overcome.

I am often jealous of much younger people who get hired into challenging environments right after college and who are immediately offered the kind of experiences that allow for a lot of growth. Consequently, many of them are at level 5 or 6 approximately 15 years before I got there (in terms of age/experience). Sure, level inflation works in their favor as well, but there is no denying that the opportunity to meet and rise to significant technical and organizational challenges early in their career leads to a very different growth curve.

So here’s this week’s wisdom: If you are interested in having a career, be conscious about where you work, what you do there, and who you work with. Spending time in easy jobs that pay good money lets your rack up some types of experience, but you do not actually grow that much; at least not in the areas that might matter more.