Chirp

Last week I spent a lot of time at Twitter's first ever developer conference, Chirp. What an event!

A handful of my favorite photos (full set here):

• @biz and @ev and @ev and @biz
• @goldman
• @jess
• @kevinweil
• @marissamayer
• Beanbag
• Showcase Crowd
• Coffee Bar

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: