Monday, April 12, 2010

Learning or Earning, Redux

A friend David provided some valuable feedback on my last post. He gives me a great opportunity to take a small step back and clarify some things. He also sets up the perfect segue into my continued thoughts. Read on.

From David:

Though I've learned a lot from my time working at other leading & famous tech companies, I've probably grown and learned more at Google than the other places... from a technical perspective. On the nontechnical side, I've probably learned more elsewhere. But from a tech perspective, it's absolutely totally worthwhile - as well as fun and productive.
I actually agree wholeheartedly, which makes me think I wasn't clear in my intentions last time. I had a great few years working at Google, had fun and learned a whole lot. I wasn't meaning to bash the place or indicate any regret at having been there (I have none). Quite apart from anything else I met a fantastic set of folks there, David himself amongst them.

It's inevitable, though, working at any one company, that there comes a point beyond which you're no longer becoming skilled in the kinds of things the company does and instead you're developing increasing expertise in the way the company does them.

In the beginning you're learning the principles of computing at scale; in the end you're the guy to whom people go when they need help debugging config files for the proprietary distributed software stack. You start off gaining an understanding of best practice for source control management across ten thousand engineers, and end up with a homegrown library of shells scripts which will only ever work for $COMPANY's system.

Having just changed jobs, I'm experiencing an acute sensitivity to transferrable and non-transferrable skills. The key discovery for me is that the general principle applies beyond the domain of software engineering. If you're developing a talent for getting things done organizationally, try to watch out for the point after which day by day you're getting better and better at getting things done in your company in particular rather than getting things done in general.

I had coffee the other day with a friend who estimated that in her job she spends more time going around getting approvals to do stuff than she spends actually doing stuff. She's amongst the very best where she works at getting approvals for things, but to what extent is that skill fungible in the jobs market? How might one expect her to perform in a new organizational context?

Ultimately this is, of course, only interesting to the extent that you care about the "jobs market" or becoming an attractive commodity within that market. To repeat myself: my facile philosophy on my accidental career is "be in a job where you're either earning big or learning big". The point of these posts, though, is that you should also consider what's actually worth learning.

Recent polaroid:

Apples

2 comments:

Jean said...

I always thought what one learns is really up to the individual. Every company has its own internal structure and dynamic, from both business and technical sides.

A typical software eng is very likely ending up working on a hybrid of both home-grown solutions and standard technology. Someone could either learn the source structure and knows when to copy paste from where when fixing bugs or to creating new features, OR, he/she could learn how the software is built, what are the architectures, what are the lessons learned, what are the pain points.

Often the failure is a lot more useful for ones future endeavor.

When i Interview someone, i always try to distinguish the former(the copy and paste kind) versus the latter(the one who is curious enough to learn the big picture along the way).

Certainly i agree with you that one has to decide when is time to move on, if your current company ceases to keep your curiosity up, then it is probably time to move on. I'm not sure sure it has that much to do with home-grown tech versus standardly available ones.

just my 0.02.

Unknown said...

I guess some of the sentiments have to do with where you are in terms of learning about the company. It's absolutely true that if you're new, everything is exciting and you'll feel "overwhelmed" with the amount of new things you can learn. The examples you gave below are very typical "learn, then contribute":

In the beginning you're learning the principles of computing at scale; in the end you're the guy to whom people go when they need help debugging config files for the proprietary distributed software stack. You start off gaining an understanding of best practice for source control management across ten thousand engineers, and end up with a homegrown library of shells scripts which will only ever work for $COMPANY's system.

The question I'd ask is: If the individual settles with just debugging config files and managing home-grown libraries, then of course the learning curve will become flat (or even trending down). Jean is right in that what one learns is up to him/her. And if the current company simply can't keep you excited, or the individual just loses momentum without changing environment, or the individual isn't feeling satisfied either intellectually and financially, then it's time to move on.