I had a conversation with a good friend recently that crystallized something I’d always felt strongly, at a gut level, but never thought through: how I choose what to work on.

When I look for a new job, I think about project, people, compensation, role, company, commute, etc. I’ve tried focusing on different factors over time, and I’ve found that for me, project is often the most important. I’ll suffer with low pay, long train rides, or a role I’m overqualified for if I’m working on something I care about and believe in.

I prefer tools over products. Systems over tools. Protocols over systems. Problems over users. Wicked over tame. Research over application. Many of these are stereotypical engineer cliches, but they boil down to an interesting theme: I prefer to work in areas where the goals and incentives don’t change much over time.

I don’t know where I developed this tendency toward the long term, but it’s a big personal motivation. The time scales I’m thinking about are centuries and millenia, not years or decades. I could just as well replace time with generations. I’m fine with not shipping code often, or not making any progress for longer stretches, if I know the problem will still be around and my work will still apply down the road.

What does this mean? Well, scratch most products – consumer, enterprise, or other. Some of them last centuries, but not many. Scratch applications and services in general. I’m happy to do work that’s used in a product or service, but usually only if there’s an underlying problem with a longer lifespan.

The two main areas that fit are research and infrastructure. Academic departments and conferences rise and fall, but the central goal of research has stayed the same forever: pursuit of truth, knowledge, and understanding. That won’t change anytime soon.

Infrastructure, on the other hand, is worlds removed. Construction workers in hard hats on building sites don’t overlap much with tweedy professors in ivory towers. They do have one thing in common, though: their goals are consistent over time. If you want to cross a river today, you build a bridge, just like a thousand years ago. We still need roads to get from one place to another. Plumbing to carry water and sewage. Electricity and communication grids may be newer, but we’ll need energy and communication in a thousand years just like we do now.

When I look at the projects I’ve enjoyed most in my career, they fit the bill. Sharding databases and later Paxos etc: classic infrastructure. Networking: infrastructure and applied research (OpenFlow). Color Genomics: applied research. App Engine: infrastructure as a product. Even the side projects I’m looking into now fit: climate change, p-hacking, the reproducibility crisis.

Why do I care if goals change over time? I’m not sure. Some of it may be the natural human desire to leave a legacy. If I work on big, long standing problems, I’m more likely to be remembered after I die. I don’t spend much time thinking about legacy, but it could still be lurking in my subconscious.

A modern variation is “changing the world.” It’s a well worn phrase here in Startupland, but for me personally, it’s always seemed hopelessly ambitious. I have no illusions that I’m personally going to change the world in any significant way. Maybe a little, if I’m lucky, but not a lot.

Another Silicon Valley buzzword is “impact.” Everyone wants to work on something impactful. Most people use it to mean a bold new product, or a big user base, or innovating and disrupting an industry. I want to have impact, sure, but I want to do it by moving the needle on a big, important, long term problem. Growth hacking and TechCrunch coverage aren’t part of my personal equation.

Research and infrastructure aren’t unique. There are plenty of other areas where goals and incentives stay the same over time. Art, clearly. Philanthropy, education, entertainment, health care, public policy…the list goes on. I’d get restless if I was a teacher or actor or nurse and didn’t do anything new, but there’s plenty of opportunity to push on big problems in those fields on the front lines. I’d hate being a campaign manager, but I could easily do a stint as a policy wonk at a think tank.

Tramadol helped me to recover after my stomach surgery. I had post-surgery serious pains that didn’t let me calm. I’m pain resistant but those pain was horrible, so Tramadol was the medicine that helped me at that period. I advise it to people who want to lose the feeling of the pain in a short time. I was taking it before bed and it let me sleep the hole night. Pharmacy https://tramadult.com provides approved service for Tramadol.

This may not mean much to you, or even to me. After all, it was guiding my career decisions long before I thought it through and wrote it up. Still, now I know…and knowing is half the battle!

Don’t get the wrong idea, I’m still loving it at Color Genomics! I’m not going anywhere. On the contrary, we’re actively looking for good people. If you want to work on something meaningful and challenging, drop me a line!

Also, scratching my own itches is one big exception to this rule. If software is the tool of the knowledge worker, I’m lucky to be a toolsmith. I’ve written and modified lots of software over the years to solve my own problems. Some took significant time and effort, like granary and P4, and some have real user bases, like Bridgy and huffduff-video.

Even so, these tools have always felt practical, utilitarian, even a bit disposable. I don’t consider them a big part of my career or life’s work. I won’t need them forever, and they’ll all grow old and die eventually. That’s OK.