I remember reading Paul Graham’s essay What You’ll Wish You’d Known as a teenager, back when I had first discovered Graham as an essayist. One section of that essay has stuck with me in the years since:
If (Shakespeare and Einstein) were just like us, then they had to work very hard to do what they did. And that's one reason we like to believe in genius. It gives us an excuse for being lazy. If these guys were able to do what they did only because of some magic Shakespeareness or Einsteinness, then it's not our fault if we can't do something as good.
I'm not saying there's no such thing as genius. But if you're trying to choose between two theories and one gives you an excuse for being lazy, the other one is probably right. (emphasis mine)
“Heh”, I remember thinking, “That’s a useful idea.”
It’s been a couple of months into this blog’s life, and I’m starting to circle in on a core principle that’s driving all of my writing here. Call it Commonplace’s central thesis, if you will. I’ve written about it — badly — in How to Optimise for Success, A Theory, and I’ve also alluded to it when summarising Ray Dalio’s Hyperrealism. But I want to spend some time today hashing it out, in order to work out all the implications.
The philosophy is something I call ‘Optimise for Usefulness’.
The core concept is simple enough to state: if a belief is useful to you in achieving your goals, keep it. Otherwise, discard it. An extension of this is, per Graham, if you have to pick between two theories and one is less useful than the other, pick the more useful one regardless of the truth. I believe effective, successful people do some variant of this. Unsuccessful people don’t.
But this statement isn’t, in itself, very useful (hah!). If we want to apply it to our lives, we should work out all the implications for ourselves, and explore all the forms this idea can take. So let’s do that here.
Modifying Mindsets for Usefulness
I think it’s pretty clear to most people that there exists a set of techniques that are a) cheap to implement at a personal level, b) create no immediate improvement in knowledge or technique, but c) result in higher effectiveness nevertheless. I’m going to call these class of techniques ‘mindset tweaks’. To put it simply, a mindset tweak is a change to your worldview that allows you to better perform at something you’re doing. A mindset that helps you do so is useful. A mindset that doesn’t is not. It seems ridiculous that reframing an activity may change your effectiveness at said activity, but such techniques do exist, and they do work.
A concrete example will help illustrate this point: if you’ve done any long-distance running at all, you’ll be familiar with the idea of managing your mind. A runner fights the desire to stop throughout her run. This is understandable: when your lungs are bursting and your muscles are spasming and the burn from pushing yourself for an hour or two start to become unbearable, your brain begins to form all sorts of clever excuses to stop, to just lift the pain and to seek blessed relief from the agony of continued motion. Good runners know how to manage this desire. They put their minds elsewhere, or they focus on their breathing, or they use self talk like “hills are my friend” to get past the bad bits.
What interests me is that this mindset tweak doesn’t do anything in particular to the runner’s physical ability. Her lung capacity, stamina, and technique remain the same. But a runner with the same amount of talent and training will do better if they have this mindset tweak, when compared to a runner without.
Sports psychology-driven mindset tweaks are obvious, however. It’s not so obvious that mindset tweaks exist elsewhere. But similar tweaks exist for careers; Eugene Wallingford writes about one such technique in his blog post Get Attached to Solving Problems for People:
In Getting Critiqued, Adam Morse reflects on his evolution from art student to web designer, and how that changed his relationship with users and critiques. Artists create things in which they are, at some level, invested. Their process matters. As a result, critiques, however well-intentioned, feel personal. The work isn't about a user; it's about you. But...
... design is different. As a designer, I don't matter. My work doesn't matter. Nothing I make matters in the context of my process. It's all about the people you are building for. You're just trying to solve problems for people. Once you realize this, it's the most liberating thing.
Why is this mindset tweak useful? Well, if you’re able to see the goal of your work as ‘solving problems’, then criticism of your work becomes less grating, because it’s no longer about you. It’s about solving the problem. This allows you to learn more effectively from criticism, and it prevents you from quitting your field prematurely as the feedback — erroneously seen as personal attacks — wear you down.
I recently heard a journalist complain “if writers are artists, then what I deal with weekly is someone ripping apart the art that I’ve taken great pains to craft.” Optimising for usefulness suggests that this mindset isn’t useful at all, and should be discarded as quickly as possible. The journalist would do better instead if they thought of their work as ‘communicating information to an audience that needs such information.’
That isn’t to say that art doesn’t exist in journalism, just that the way to get to art is to adopt a mindset that gets out of the way in the first place. The optimal approach is to find a more useful mindset, something to help you stick around long enough to build mastery.
Discarding Bad Mindsets
Our example with the journalist suggests a different application of ‘optimise for usefulness’. It suggests that you can use this philosophy by inverting it: that is, if you find that you possess a mindset that actively hinders you in achieving your goals, then you should immediately begin a search for a more useful mindset to replace it with.
This idea has been surprisingly powerful for me. My first experience with it was at my previous company, during a period where I found it difficult to continue. When we first made the shift to selling products instead of consulting services, things got very difficult very quickly. I was pulling all-nighters, people were leaving due to the uncertainty, and customers were yelling at us every other day, as we had no idea what we were doing. I got quite discouraged, and spent a few months thinking about quitting.
The turning point came when I met with Dinesh Raju of ReferralCandy. I told him about my company’s problems, and he told me two things. First, he gave me some generic management advice, and then he told me to read High Output Management by Andy Grove. I remember thinking: what if I treated this experience as an opportunity to get really good at management? What would that be like?
It was like a light switch turning on. Everything, externally, was still the same, but I remember coming in to work the next week motivated to fix the terrible situation I was in. I treated the company as a way to gain mastery in management. And I did.
I think what was important about that experience was that I should have realised I needed a mindset shift earlier. It was important for me to stay at the company in order to achieve my goals. My mindset before meeting Dinesh was hindering me from achieving those goals; my mindset after meeting him was way more useful. I should have optimised for usefulness earlier.
Years later, I read Cal Newport’s book So Good They Can’t Ignore You, which explained what had happened to me. In it, Newport argues that picking a profession by following your passion is a terrible idea, because most people don’t know what they’re passionate about. Instead, Newport recommends seeing your chosen vocation as a craft that you can get better at. This ‘craftsman mindset’ — as he put it — is more useful, because it allows you to build mastery. And the literature suggests that mastery leads to passion more often than the reverse.
I think many of the techniques in The Principles Sequence are of the ‘mindset tweaks to help you achieve your goals’ category. Of particular relevance to our current discussion is Dalio’s mindset tweak to ‘see pain as reality telling you that you need to update your understanding of the world’. Adopting such a mindset helps in dealing with setbacks. It also implies changing mindsets if they actively hinder you.
Optimising Heuristics
One way ‘optimising for usefulness’ is clearly helpful is when you’re looking for good heuristics in life.
A heuristic is a big word that basically means ‘rule of thumb’. Cooking is filled with useful heuristics: for instance, once you know that bread dough is five parts flour to three parts liquid, you never have to look at a cookbook for bread again, and you can scale a recipe from four people to 400.
I think effectiveness in life is a search for similarly useful heuristics. For instance, my previous post on dismissive stubbornness is useful because it identifies a trait that I normally have trouble pinpointing. In the past, I‘ve had bad experiences with dismissively stubborn people, though I couldn’t adequately describe why they were so bad. So identifying this trait is good because it’s useful.
But it’s not useful enough. To optimise for usefulness, I need to find an effective test for detecting dismissive stubbornness. I wrote a hypothesis in the closing paragraphs of my piece — that polite debate might be one way to test for this trait — and I intend to test that through trial and error.
The truth is that polite debate may or may not work. I might have to try other approaches. But the point is that once I’ve found a good enough test, my goal is to incorporate it into my protocols for ‘do I want to work with this person or not’? Identifying a trait is good, but developing an efficient test for that trait is even better. Adopting such a test is optimising for usefulness; it should — I hope! — make me more effective in the future.
Another useful heuristic that I’ve learnt is the idea that debugging activity is indicative of broader programming ability. Or, to put this more accurately: a programmer with good debugging skills might not be a great programmer, but a programmer with bad debugging skills can never be a good one. It took awhile to come to this realisation, but then all sorts of useful implications presented themselves. One useful implication is that in order to become a better programmer, it pays to work on your debugging skills. But a more useful implication would be that we could use this insight for hiring.
As a result of this idea, we reconfigured our screening tests at my previous company and gave all candidates a buggy program to debug as a first test. If the candidate had real trouble debugging, we cut the interview short. It made our hiring a lot more efficient overall.
In Principles, Ray Dalio suggests that you write down your principles for dealing with different situations, because similar situations tend to appear repeatedly over the course of your life. Formalising your principles simplifies decision making. It also allows you to consider each principle explicitly, and to change them if they no longer appear as useful to achieving your goals as they used to.
Distilling Lessons from Experience
I was having lunch with a friend recently, when she complained that she was disappointed with a colleague of hers, and explained why. It was a pretty good story, and I could understand her reasons for being frustrated by the end of it.
“But don’t be disappointed,” I said, “I think that being disappointed isn’t useful.”
“So what’s the right approach?”
“I don’t know,” I said, “But what other things could you try?”
I think, looking back, that I would still have said complaining wasn’t good because it doesn’t optimise for usefulness. But instead of walking through the whole space of alternative reactions, I would have suggested sorting it in the order of potential usefulness.
It’s clear that disappointment isn’t a useful response. It doesn’t help my friend achieve her work goals. But what other reactions do we have available to us, and how may we order them?
A slightly more useful approach would be to see this as a challenge to figure out what works: that is, to figure out what motivates this particular colleague. Better still is using that experience as a way to build a library of personality archetypes, the same way an athlete builds a playbook of techniques.
This approach requires you to ask yourself: “what personality markers may I use to identify people who are like my colleague? Is my colleague lazy? How may I invalidate that hypothesis? Contra my current guess, are there areas in which she is motivated? If so, what are the common elements? How may I use that to motivate her? And how may I test these guesses?”
Each question above scales the ladder of usefulness. Finding the answer to “how do I motivate people with my colleague's personality” is more useful than “how do I tell quickly and accurately if someone is lazy?”, which in turn is more useful than “how do I know this particular colleague is lazy?” or “how do I motivate this particular colleague?”, which is, finally, more useful than “gosh, this colleague is so lazy, I’m so disappointed in her.”
Optimising for usefulness means climbing the ladder of usefulness and not settling too early. I don’t think we do this nearly enough. In this particular example, it’s clear that you shouldn’t settle for mere disappointment. But it also means not settling even after you find a method for dealing with the problematic colleague! A far better outcome would be to walk away with a generalisable rule for identifying people of this personality type, and a generalisable rule for dealing with them, which you may use for the rest of your career.
A common objection at this point is “how do you know your test works in the general case?” This is a legitimate concern. You might think that your conclusion is the right one (“my colleague is lazy and I should work around her!”) and then maybe it turns out that your test for laziness is wrong or your solution to work around her just happened to work this one time. But implicit in optimising for usefulness is the idea that you should continually reevaluate your heuristics. Discard your conclusions if you find invalidating evidence. Refine your approaches with continued experimentation.
Distilling the Wrong Lessons
There’s another aspect to this idea: that is to not jump to conclusions that are of limited usefulness. This is a subtly different point from our previous example.
In our previous example, you faced a problem and found a solution that worked, but failed to consider if the solution was generalisable. Here, you draw the ‘wrong’ lessons from your experiences. These lessons are ‘wrong’ in the sense that they aren't as useful as alternative lessons you could have learnt. But that, too, is nowhere near the worst outcome; the worse outcome is that you learn lessons that hinder you in the future — which are too easy to do if you continue to run your life on the basis of these unexamined conclusions.
I once had a fellow manager who concluded a reasonable but ultimately limiting set of lessons from a shared experience. We had been hiring a number of candidates from Taiwan. Our first candidate was a fantastic software engineer who came from a large, multinational hardware company; he joined us because he was looking to get into a ‘proper’ software company, and there weren’t a lot of those in Taiwan.
We had been assigning him to work on some frankly lousy projects, such as setting up a new internal CMS, as well as taking on low-value, dead-end enterprise deployments.
He left us after seven months of such low-value work.
My fellow manager and I concluded wildly different lessons from this experience. I concluded that we shouldn’t waste good software engineers from Taiwan on subpar tasks. My colleague concluded that the Singaporean software market was too competitive, and we should only hire lousy software engineering candidates from Taiwan, ones who couldn’t get jobs at competing software firms. He based his argument on the fact that the salary offered was higher than what we offered, and that we could not possibly compete when dealt with such offers.
I disagreed heatedly. My mental models for retention were dramatically different from his; I had good experiences increasing employee retention in Vietnam despite the fact that we didn’t offer the highest salaries in town. I suspected we could do the same with engineers we hired from Taiwan, which would give our company a huge competitive advantage, what with the limited supply of computer science graduates in Singapore.
The point here is not that I was right and he was wrong. The point here was that my colleague jumped to the least useful interpretation possible. His ‘lesson’ hampered our ability to hire from Taiwan — which remained an organisational hangup well after I left the company.
It could well be true that it is impossible to hold on to good Taiwanese software engineers in Singapore, and that the only solution is to recruit bad ones. But I believe it wouldn’t cost much to test an alternative interpretation, one that didn’t lock us out of hiring good Taiwanese software engineers. To this day, that company has not been able to recruit from Taiwan, despite my continued observation that retention strategies usually take a year or so to work out.
The Central Thesis
So let’s sum up.
Optimising for usefulness consists of four aspects: first, that mindset hacks exist, and that the good ones help you become more effective at life. Second, that we may invert this idea: if you possess a mindset that hinders you from achieving your goals, aggressively look for a better one.
Third, ‘optimising for usefulness’ also works when it comes to learning from experience: when something happens to you, prioritise learning the lessons with higher usefulness first. Verify that they work through trial and error. And fourth, prevent yourself from leaping to obvious (or convenient!) but ultimately less useful conclusions.
So what does this have to do with this blog? Why write about ‘optimising for usefulness?’
The answer: Commonplace’s central thesis is to write about ideas in a way that is optimised for usefulness.
It’s too easy to write about topics that are merely intellectually interesting, or to describe mental models in an abstract way, with no clear actionables in sight. But optimising for usefulness in the context of this blog means picking topics that are useful for the work of building career moats.
It also means that you should apply the test of usefulness whenever you read something here. Construct tests for everything I write about; take nothing at face value. And if an idea passes your tests — that is, if it demonstrably helps you on your journey to achieve your goals, then it’s useful and you should keep it. But if it doesn’t, then it doesn't matter if it's true. It's not useful for you, and you should pay it no mind.
Originally published , last updated .
