Moments Of Invention
What can a Mark Twain quote and a simple fact about how inventions happen teach us about day-to-day problem solving?
Recently I was reminded of Stigler’s Law of eponymy and found this quote, attributed to Mark Twain:
It takes a thousand men to invent a telegraph, or a steam engine, or a phonograph, or a photograph, or a telephone or any other important thing—and the last man gets the credit and we forget the others. <…> These object lessons should teach us that ninety-nine parts of all things that proceed from the intellect are plagiarisms, pure and simple; and the lesson ought to make us modest. But nothing can do that.
On one hand it sounds pretty grim to have 99% of everything be plagiarised, but the reality is that success is rarely a solitary achievement. Edwin Hubble was not the original inventor of Hubble’s Law. Elon Musk did not found Tesla. Sometimes people are not even acknowledged for their intellectual proceeds. Rosalind Franklin is just one example.
And yet, when we think of these stories, we think of people with pages on Wikipedia or in school, or university textbooks. Never does it cross our mind that it could also be us, if we chose to actively try and exploit this effect. Not in some inspirational way where we find ourselves writing a cosmological physics PhD, but every single day, at work.
How many times have we been facing a technical obstacle, and jumped on solving it using open-source libraries and tools that were written by thousands of people before us. Most day to day software engineering is just permutations of the same problems being solved over and over again. Rarely do we find ourselves inventing something new. Plagiarism, whether intentional or not, comes with the territory.
On the other hand, those moments when the obstacle has not been seen before, we cherish. We don’t know how to overcome it. We give it names like tech debt, or maintenance work. We put processes and people around it to guard us and tell us when it makes the most sense to invest time to solve it. Because it is an unseen problem and we are solution focussed - it will take time for someone to sit on it in solitude, before they succeed.
What if we took Mark Twain’s advice and accepted the fact that most moments of invention are preceded by compounding the incremental insights of a thousand people? Can we apply it as a strategy for problem solving? With 100 people, or 10? Our own teams? As a matter of fact we can.
Imagine, the next time you run into a problem at work, something not urgent, but problematic enough. Instead of keeping it to yourself, or just writing an empty ticket “X is broken” you write down the context: the current situation, the problem, the impact of not solving it, and any relevant metrics and links - diligently; then just leave it there to “ferment”. It takes you 15mins to do this. Time passes, maybe the problem persists - you make a comment on the ticket each time, 5mins spent on this - insignificant. From time to time you mention this ticket to your colleagues without any obligation to address it - some would say useless, but…
After some more time an interesting thing happens. You read a Hacker News post with relevant information, a dependency package gets updated with a relevant feature, a new colleague joins who knows the answer, because they saw the problem before. Overall you spend maybe an hour, spread out over months, but you can claim credit for the resolution. Not because you took a ticket and tried to solve it all at once, but because you diligently made notes, kept the context in text, and were on the lookout for the input from your own team or thousands of others on the internet solving similar problems.
Every company has some sort of system to track features to implement, analysis to be done, and problems to solve. You could ask what’s so different here? It matters where the emphasis is. Most of the places I have been at put it on active problem solving. Someone would pick up a ticket, read the description, do the research (often alone), and then try to implement a solution. My point is that a passive (you could even call it continuous), problem solving approach, when more emphasis is put on the context building not the solution, yields better results.
My favourite example is from Genus AI, where I had a habit of making detailed descriptions of any problems I could not justify working on immediately. In this particular case we had a class of errors that crashed the website briefly. Think circular Python imports that manifest in production, but not on local development machines. It didn’t happen often enough to justify hours of work. Recovering from it also took 5 minutes (read more about the build and deployment system here).
There was no way I could spend a proper amount of time debugging and thinking of a solution in one go. But I could spend hours spread over months. Sometimes I would just make a note when that problem repeated, with a theory why and a log snippet, sometimes I would fiddle for an hour with some idea of a solution, fail, write it up and move on. Then one day a new colleague joined, during some conversation about our tech debt the ticket surfaced and he asked if I heard about a Python package that would help mimic the production environment in a brutally simplistic way. I hadn't until then, but after I knew - it took me 15mins to plug it into a test suite and have a working regression test. Deployment followed and we did not have that class of issues ever again.
How To Repeat It
I bet that everyone had a similar experience at least once: you have a non-urgent, but impactful problem, that you gave yourself time and space to think about, build context, and experiment with, that resulted in a positive outcome. What’s missing is the reflection that this process is repeatable. I have seen it work enough times that I claim it works and can be exploited strategically to solve a certain class of problems.
First, don’t make lazy tickets (just "fix broken deployment") with the context in your head (e.g. “because I’ll probably work on it myself anyways”). Write the current situation (how things are now), the problem (why things now are not good), and any reference material: links, ideas, metrics, log snippets, etc. Should not take more than 15 mins, but to anyone reading the ticket it will give enough information to know if the situation is still relevant, and whether the problem still exists.
Second, if the problem repeats - write a comment. If you read something relevant - drop a link. If you have an idea, but no time to do it - write a summary. It should take no more than 5-10mins, but for anyone stumbling onto the ticket, they don’t have to start from scratch, but can pick up from where you left off. When I say they - it can be your colleagues or yourself three months later. It also helps to keep track how often and what impact the issue has.
Third, once in a while give yourself a time-boxed slot to try the ideas. Success is not mandatory. What is mandatory - a summary of how far you’ve got and what you’ve learned. It should take no more than an hour, but for anyone, again, stumbling onto the ticket it shows what you tried and not repeat the same mistakes again, or notice how to do a better experiment next time.
Of course, this is not a bulletproof strategy. It works best with those non-urgent, but impactful problems that are hard to prioritise because no one can tell how long it will take to solve them. But when it does work - I swear it looks like a miracle. It requires almost no time but the impact is disproportionate. It requires no extra tools, just culture and discipline.
This is in no way a unique approach too. The scientific community has been using it for centuries. Those of us who went to university, are often quick to forget the process of research, as soon as we get the diploma and throw the graduation cap into the air. Sadly, to our own detriment and frustration later. I hope this serves as a reminder; the next time you stumble into a problem that fits the definition, maybe you will feel inspired to try the Mark Twain approach. I would like to hear how it went.