To find a job you love, you can start by considering your career values, what specific job is compatible with those values, and what skills you need to do well at that job.
If you already have the job you want, you still need to decide what you want to work on. The job description that you might have perused before applying for the job could tell you something. For a programming job, that might include technologies you’ll be using, background you should have, and a general idea of the product you’ll be working on. But within those general boundaries, you have some control over your daily work. That allows you to customize a general job description to fit exactly what you want to do.
Find General Problems to Solve
In his famous lecture “You and Your Research,” Richard Hamming asks: What are the important problems of your field? One of his suggestions for finding the answer involves customizing your job.
Hamming tells the story of working on a method for integrating differential equations. At the time (mid-20th century), analog computers were still being used for this purpose. Hamming’s task was to get a digital computer to do the same thing.
His first approach got him the right answer, but the method was messy, and he wasn’t satisfied with it. This prompted the realization that his goal was not just to get the answer, but to get it in a way that others could understand and build on his approach. So rather than just delivering the method, he came up with a theory and an implementation that made use of it. The result was more elegant than his first attempt, and for several years it was the standard method for solving this problem.
In a commentary on the Hamming lecture, Cal Newport calls this idea “Transform isolated problems into general problems.” You can use this approach at work. When you start on a problem, think about how much effort it would be to solve the problem in a more general way. In your estimate, consider how much time you’ll save in the future if you can avoid solving similar problems one by one. And what about the time saved by others who can build on your approach? It may be more practical than you think to redefine problems in this way.
Make Your Job More Interesting
Turning specific problems into general problems isn’t just a way to find important problems, or free up time in other people’s schedules. It’s also a way to make your job more interesting. In that post from last year, I suggested two reasons why finding a general solution to a problem is more interesting than just solving a specific instance:
- Programmers want their software to be used. If you write a general solution, it applies to more problems, which expands your pool of potential users.
- Programmers like challenges. A general solution is more challenging: you can’t get away with making limited assumptions about your specific problem.
Hamming agrees that solving general problems is “much more satisfying and rewarding,” but he disagrees that it is more challenging. His opinion: “It’s just as easy to do a broad, general job as one very special case.” But that may only apply if you’re as smart as Richard Hamming!
Nasty Little Problems
In his 2004 talk on how to identify a great hacker, Paul Graham also takes up the question of what makes a problem interesting. Like Hamming, he suggests that redefining the problem can turn a boring problem into an interesting one. His examples include Google redefining web search, and ITA Software (now also part of Google) redefining airline fare search. These companies not only created wildly successful businesses, but also attracted engineers by providing them with interesting problems to work on.
Besides describing how to make a problem interesting, Graham also approaches the question from the other end: “It’s pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones.” His examples include writing an interface to a buggy piece of software and writing a complex application for a specific client who can’t decide what they want.
Hamming also laments having to solve lots of little problems. In his lecture, he says, “I went home one Friday after finishing a problem, and curiously enough I wasn’t happy; I was depressed. I could see life being a long sequence of one problem after another after another.” If engineers enjoy solving problems, why is it a bad thing to have lots of technical problems to solve? Here’s how Graham explains it:
The distinguishing feature of nasty little problems is that you don’t learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn’t teach you anything, because the bugs are random.
This distinction between problem types gets at the root of the issue. For a programmer, learning is a key part of work. The software industry moves fast, so you have to keep learning to stay competitive. If you’re solving a lot of little problems to get a specific project done, you’re mainly learning about that specific project. It doesn’t help you on your next project. This means that as you work on your current project, you’re falling behind in your career, which doesn’t do much for your motivation.
On the other hand, if you’re solving a fundamental problem, you can use that experience in your subsequent work. The fundamental problem doesn’t have to be a historic one, like developing the first search algorithms at Google. If you have never written a web user interface using JavaScript, then writing your first one is a fundamental problem for you. The knowledge you gain in figuring out how to do it will apply to similar projects in the future.
How to Find the Right Problems
In Hamming’s example, he turned a boring problem into an interesting one by making his solution more elegant and re-usable. Here’s an idea about how to apply that approach to your programming work.
As Graham suggested, the first step is to avoid projects with many small problems in favor of those with a few big challenges. That means the experience you get will be more useful in the future. The big challenges could involve learning something that is new to you, or they could be truly big challenges that no one in your field has yet solved.
As you solve these big challenges, think about them from the perspective of the next person who will need to solve a similar problem. Is there something you can create that will make that future programmer’s job easier? The history of programming is filled with advancements that improve programmer productivity. High-level languages made programmers more productive than when they only had assembly language. Integrated Development Environments reduced the need to consult manuals for syntax help. The jQuery framework made JavaScript more accessible to front-end developers.
You can even approach your work this way on a single project team. As you’re working on your feature, look for areas of friction that make it more difficult to get your job done. It’s likely that your colleagues run into the same issues. Can you write a tool or module that others can use? A Getting Started page to help new team members? Thinking this way will get you in the habit of solving general problems rather than just getting your work done.
(Image credit: Oleg Shpyrko)