An ambitious young programmer asked me recently, “how do I balance learning
new specialties with producing good results?” It’s a great question, and a
hard balancing act.
It took me too many years to learn this. I hope the rest of you learn it much
faster than I did.
A Tale I Will Thee Tell
If you find a project that your management considers highly productive that
uses a new-to-you technology, then you can learn and be
productive. That’s a best-case scenario, but it happens semi-often.
Watch for it, just in case.
As you’d expect, those opportunities are often reserved for the programmers
who play the politics game best — if you do well, many of those will
mysteriously open up to you.
But let’s say you can’t get that, not yet.
Your Goal: Be Like Old Google
Next best is to have a perceived-as-high-value activity that doesn’t take all
of your time. This is much, much easier than it sounds. If you can do that,
you can declare your own old-Google-style
20% time, especially if you don’t declare it out loud. The keys to being
perceived as highly productive are, roughly:
1) Be sure to ask your managers, and occasionally their managers, what the
company values. Patrick
McKenzie’s article talks about doing this during your interview — and
yes, do that, but don’t stop doing it once you work there.
Also, ask business-critical groups (e.g. Sales, Marketing) and politically
powerful groups (e.g. Product, Finance) what they get from Engineering. You
ask because they remember the stuff they value and forget the stuff they
don’t. So their answers will not be a good match for what Engineering
thinks that Engineering gives them. Their answer tells you what you
want to be working on. Those are projects they consider valuable and
noteworthy. If you do a good job on projects like that, they will remember you
personally. At least, they will if you do steps 3 and 4 correctly.
2) Make sure management and/or businesspeople consider a big win on your
project to be important. This is hard at first, but gets much easier
with practice. Don’t be a prima donna, sure. But you almost always have some
choice about what to work on — whether they say you do or not.
If your manager says “project X is important”, you can say “if a spot opens up
in project X, I’d love to work on it.” If a spot opens up, he’ll remember
that you were interested.
Or mention the same thing casually even if you didn’t just ask him
about it: “I’ve been looking for a chance to do something in analytics or big
data” (or Clojure, or machine learning, or …) That’s a purely positive
thing to say to a manager. But make it clear you don’t necessarily mean right
Pick something that the company values when making this request. See
step one again, if necessary.
3) Give regular status updates. Few people do this. It’s
ridiculously useful and ridiculously simple. When you do something that
affects somebody, email them about it. When you make progress, tell your
manager. When you make a change that could affect another part of the company,
email that team. You are doing several things that way — you are being
perceived as making progress (very good.) You are subtly indicating that
you did this, and you consider it good work (also good.) You are
showing that you have good communications skills (very, very good.) If you
don’t have good communications skills, doing this will help you build them.
4) Give status to everybody, not just your own team. This applies to other
Engineering teams. It applies to nontechnical teams. It absolutely
applies to businesspeople on business-critical teams. When you give status,
email them at their own abstraction level. For engineers you’d talk about
languages, checkins and pre-release services. Talk to businesspeople in terms
of saved time, easier maintenance, return-on-investment and new
features. Often you’ll need more emails to smaller groups so you can talk to
each group differently. Good. That gets you more practice and improves
How Does This Help, Exactly?
So: how does this help with your initial question? No part of this requires
much time. You pick a reasonably important product and do a pretty good
job. Don’t do a ridiculously excellent job. That would take way more work and
way more time.
A pretty good job, communicated well, is usually more valuable to the company
than the best work of their best engineers. Amazing engineers’ work,
unfortunately, is usually lost and wasted because they don’t communicate it
well — or because they work on things the company doesn’t care at all
Since good-but-not-great work plus communication takes less time, you get a
bunch of spare make-your-own-luck time. That’s what learning new tools and
technologies is — it’s making your own luck. If you want to do well in a
company, use your time to learn more of its workings. If you want to do well
in a particular sub-field like machine learning, use the time to pick up new
technologies and read research papers. If you want to do well in business, use
it to gain practical business experience — talk to managers and
businesspeople, ask about what they need, ask what they get from engineering
and so on.
If you do this right, you can have a better, more enjoyable job and
give the business more and help your coworkers more. Everybody wins.