Do these questions sound familiar?
What are the important problems of your field?
What important problems are you working on?
If what you are doing is not important, and if you don’t think it is going to lead to something important, why are you … working on it?
They come from a 1986 speech by mathematician and Turing award winner Richard Hamming. Hamming originally asked them in the dining hall at Bell Labs, but they have since inspired other people who are interested in finding the best way to spend their work hours.
“Important work comes from important problems”
Cal Newport, like Hamming, works on research problems. However, on his blog he writes for a general audience. Over the last few years, he has been focused on finding techniques that knowledge workers can use to do their best work.
One of the recurring themes in Newport’s writing is that knowledge workers (a category which includes software developers) tend to focus on urgent work, which is generally easier, while avoiding less urgent but more important work, which is generally more challenging. If you have ever spent the whole morning replying to email, you know what he is getting at.
“Good procrastination is avoiding errands to do real work”
Entrepreneur and venture capitalist Paul Graham wrote his own response to the Hamming questions in 2005. Like Newport, he points out the human tendency to procrastinate on important work. He advises against trying to prevent procrastination entirely. Instead, he says we should procrastinate on small things, which he calls “errands,” in order to free up large blocks of time to work on important problems.
“Big problems are terrifying”
It’s hard enough to ignore urgent incoming email messages and focus on your regular work, like that feature you’re supposed to be coding. But important problems aren’t just regular work. Graham compares them to “having a vacuum cleaner hooked up to your imagination.” Newport writes extensively about the “deep work” required to complete “deep projects,” which he defines as projects “that leverage your expertise to generate a large amount of new value” — for example, “writing a highly original book” or “introducing a new academic theory.” So while the productivity techniques that help you avoid wasting time on email can free up time to work on important problems, they’re not enough on their own.
Getting to the Edge
Besides a quiet block of time uninterrupted by email and other distractions, important problems also require deep expertise in a problem domain. Imagine that you just read an article in a peer-reviewed scientific journal about a new machine learning algorithm. It points to a GitHub repository containing an implementation of the algorithm, so you clone the source and start hacking on it. Unless you already know something about machine learning, it’s unlikely that you’ll be able to make significant contributions to the project. If you want to publish your own article in a scientific journal, the barrier is even higher. It might involve going to graduate school.
Paul Graham, speaking to a group of Stanford students of on the topic of startups, says: “If you think of technology as something that’s spreading like a sort of fractal stain, every moving point on the edge represents an interesting problem.” His advice for aspiring technology entrepreneurs on the lookout for promising ideas? “Get yourself to the leading edge of some technology.” This is essentially the business version of getting a PhD to push out the boundary of human knowledge.
Cal Newport, reporting from the world of academia, uses similar language: “Only when you’re at the cutting edge are you well-positioned to spot and conquer the most promising adjacent intellectual territory.” He also points out that, not surprisingly, there aren’t many people willing to do the difficult work of getting there.
The fastest way to get to the edge of a software development specialty is deliberate practice. Deliberate practice techniques are designed to get you from your current level of skill to any level that you want, assuming that you’re willing to devote enough time to the right kinds of activities. As an additional benefit, the habits that you develop during deliberate practice are the same ones required to push out the edge once you get there. Deliberate practice requires focus and self-assessment, which is only possible if you learn to ignore the urgent tasks of the day.
Although deliberate practice builds good general habits, getting to the edge requires a specific skill to work on. For the past few months, I have been writing about mastering software development, with an emphasis on coding. But coding is still a fairly general skill. The longer you spend practicing a skill, the more specialized you have to get in order to work on an important problem. This is because of the diminishing returns provided by practice. If you have never written any code, but you have access to a computer and the Internet, you can become a better programmer than 80% of the people in the world just by completing the first lesson on Codecademy. (About 20% of people worldwide own a computer. Many of them have never written code, but there are students who don’t own a computer who write code at school, and there are probably kids hacking on their tiny phone keyboards. Let’s assume they roughly balance out).
But it’s all downhill from there. The better you get at programming, the harder it is to continue to get better. Many developers reach an expertise plateau. At that point, if they want to get better, they have to decide whether they want to switch languages, leverage their technical skills in a non-programming area, or look for a way to keep developing their expertise.
The Benefits of Specialization
Let’s assume you want to continue building technical expertise using a programming language that you already know well. There are many options for selecting an area of specialty. For example, you could focus on:
- Algorithm implementation: find a useful algorithm that doesn’t have a good implementation in your language, and implement it.
- Communicating your expertise to others: find a better way to teach people how to use features of your language. This is especially effective with a less popular language that has fewer resources already available.
- Applications: use your implementation expertise to create a product or service. If you’re trying to build technical expertise, it helps to have a partner who works on the non-coding parts of the project.
By picking a specialty and focusing your efforts on a small area, you’re more likely to gain the expertise required to tackle an important problem in that area.
Finding Interesting Work
The benefit of a question like What are the important problems of your field?, or even What are the most important problems in your field? is that it makes you think big. The field of software development has no shortage of interesting problems. With the world increasingly running on software, there are plenty of opportunities to have a big impact. However, there are also plenty of boring problems that need to be solved. Companies need programmers for maintenance work, or for building components of a business application that have been built many times before. The Hamming questions can prompt developers who find themselves in these situations to think about what they really want to work on.
While the Hamming questions are intended to challenge people who are working on small problems that don’t stretch their capabilities, they can seem overwhelming to someone who isn’t currently in a position to work on the biggest problems available. Though the questions are valuable for everyone when it comes to long-term planning, Paul Graham suggests an alternate formulation that can work for more short-term concerns: What’s the best thing you could be working on, and why aren’t you? This question reminds us to keep choosing high-value work like getting better at programming over low-value work like replying to email.
Practice Leads to Interesting Work
If the Hamming questions turn up some interesting work, then the next step is getting to the point where you can work on it. If you’re working for someone else, that might mean getting assigned to an appropriate project. If you’re working on a project for yourself, whether part-time or full-time, then you get to choose what it’s about. In either case, a prerequisite is having the right skills. If your important problem is designing a better programming language, there are a number of skills you will need to develop if you want your language to be used by people other than a small group of enthusiasts. You can potentially develop the skills as you go, but you’ll have to get them one way or another.
The type of practice that I’m currently working on is good preparation for the implementation side of software development. You can use this type of practice if your important problem requires code to be written, you want to be the one doing the coding, and you think you need to be better at coding than you are now in order to see it through. There is a school of through that the best way to get better at coding is to work on the project itself. The deliberate practice hypothesis argues that we need to specifically practice our skills in addition to using them for work. If we apply that hypothesis to programming, then it’s not enough just to work on projects. We also have to work on skill improvement.
Idealism and Pragmatism
To make use of the Hamming questions, you need a combination of idealism and pragmatism. Idealism convinces you that you are capable of working on the most important problems that you can find. Pragmatism encourages you to practice until you are capable of working on those problems.
(Image credit: Steve Rainwater)