In the outstanding talk “You and Your Research” by Dr. Richard Hamming , he tells us that we need to be regularly asking ourselves two questions:
- What are the important problems in my field?
- Am I working on them?
If we want to make important contributions or produce outstanding work, we need to continually revisit these questions.
Good people, very talented people, almost always turn out good work. We’re talking about the outstanding work, the type of work that gets the Nobel Prize and gets recognition.
– Dr. Hamming
Dr. Richard Feynman also talked about having twelve favorite problems that he always kept in the back of his mind.
Every time you hear a new trick or a new result, test it against each of your twelve problems to see whether it helps. Every once in a while there will be a hit, and people will say, ‘How did he do it? He must be a genius!
Our problems don’t have to be impossible or grand, either. Dr. Feynman, in a letter to Koichi Manom, advises us that any problem we can help solve or contribute to is a valuable one.
The worthwhile problems are the ones you can really solve or help solve, the ones you can really contribute something to. A problem is grand in science if it lies before us unsolved and we see some way for us to make some headway into it. I would advise you to take even simpler, or as you say, humbler, problems until you find some you can really solve easily, no matter how trivial. You will get the pleasure of success, and of helping your fellow man, even if it is only to answer a question in the mind of a colleague less able than you. You must not take away from yourself these pleasures because you have some erroneous idea of what is worthwhile.
[…]
No problem is too small or too trivial if we can really do something about it.
Our Take on the Important Problems
These are the problems that we are currently thinking about:
- The Problem of Electronic Waste
- What would the “Body of Knowledge” for embedded systems look like?
- The most common approach to building embedded software makes it difficult to respond to change – so what can we do differently?
- One goal: for embedded software developers is to write less firmware and more software
- The pressure on software teams is increasing – how do we move fast but do a good job?
- What would it look like if an embedded system was designed “responsibly”?
- Design and planning have been de-emphasized in software development – how do we restore the balance?
Fundamental Problems
- The pressure on software teams is increasing – how do we move fast but do a good job?
- All software will age, but Firmware ages more quickly than software. What can we do to combat this aging tendency?
- It’s harder to read code than it is to write it – so how can we make code easier to read and understand?
- We keep rewriting the same software over and over again – what can we do to build a better corpus of reusable code for things like drivers?
- The people who create the system don’t stick around for maintenance. Instead, they move on to building new projects, leaving others to come after and clean up their mess.
- People who create the product are better at revising it– how can you keep a system maintainable after the original creators have moved on?
- Successful embedded product development requires well-rounded leadership – yet, leaders often to be biased heavily toward hardware or software.
Cultural Problems
- The Industry Prides Itself on Overwork
- Development teams tend to focus on the next milestone, not the long-term
- Not Invented Here Syndrome is a Business Problem
- What would it look like if an embedded system was designed “responsibly”?
- Code Is not the only thing that matters
- Design and planning have been de-emphasized in software development
- An ad-driven internet made everyone think things should be free, including source code
- Why do hardware disciplines dominate embedded systems development?
- Fantastical Schedules
Problems in Education
- What would the “Body of Knowledge” for embedded systems look like?
- We don’t do a good job teaching software maintenance
- “Proper” techniques are always easier to say than to do – how do we overcome this and encourage the adoption of beneficial techniques?
References
-
Building a Second Brain by Tiago Forte affiliate link
In other words, Feynman’s approach was to maintain a list of a dozen open questions. When a new scientific finding came out, he would test it against each of his questions to see if it shed any new light on the problem. This cross-disciplinary approach allowed him to make connections across seemingly unrelated subjects, while continuing to follow his sense of curiosity.
-
You and Your Research by Dr. Richard Hamming
Good people, very talented people, almost always turn out good work. We’re talking about the outstanding work, the type of work that gets the Nobel Prize and gets recognition.
It’s not the consequence that makes a problem important, it is that you have a reasonable attack. That is what makes a problem important.
- Definitely true for engineers and programmers too:
The average scientist, so far as I can make out, spends almost all his time working on problems which he believes will not be important and he also doesn’t believe that they will lead to important problems.
Most great scientists know many important problems. They have something between 10 and 20 important problems for which they are looking for an attack. And when they see a new idea come up, one hears them say ‘Well that bears on this problem.’
You should do your job in such a fashion that others can build on top of it, so they will indeed say, ”Yes, I’ve stood on so and so’s shoulders and I saw further.” The essence of science is cumulative. By changing a problem slightly you can often do great work rather than merely good work. Instead of attacking isolated problems, I made the resolution that I would never again solve an isolated problem except as characteristic of a class.
To end this part, I’ll remind you, It is a poor workman who blames his tools – the good man gets on with the job, given what he’s got, and gets the best answer he can.” And I suggest that by altering the problem, by looking at the thing differently, you can make a great deal of difference in your final productivity because you can either do it in such a fashion that people can indeed build on what you’ve done, or you can do it in such a fashion that the next person has to essentially duplicate again what you’ve done. It isn’t just a matter of the job, it’s the way you write the report, the way you write the paper, the whole attitude. It’s just as easy to do a broad, general job as one very special case. And it’s much more satisfying and rewarding!
-
Richard Feynman’s Letter on What Problems to Solve by Farnam Street, quoting a letter from Richard Feynman