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 this second.

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 your reputation.

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 about.

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.