metacog

[metacog]

Herbert Simon On Competition

(This post was excerpted from Chapter 7 of Models of My Life by Herbert Simon. Simon won the Nobel Prize in Economics and the Turing Award; his biography is a wonderful recollection of the life of an academic). Two other considerations have been of much greater importance than money for the path my career took: my attitudes toward competition, and the criteria that, at choice points, directed me down one path rather than another. This is perhaps a good place to review the rules of play, as I conceived them. The record makes clear that I have been, and am, a competitive person, and in addition to the intrinsic satisfactions of academic work, I have never been insensitive to the implicit competition with others that pursuit of a career entails. A highly competitive person has a hard row to hoe. There is no satisfaction in winning a competition unless it is a stiff and fair one. Stiff is easy to define; it is stiff if one’s own realistic assessment of one’s abilities make the odds long—the longer the odds, the greater satisfaction on winning. Fair is harder to define, for if one wins a contest against long odds, there must be a reason. The odds weren’t really long; they only appeared to be so. Isn’t it unfair to appear to be an underdog when one really isn’t? Let’s start with some obvious distinctions: A professional gambler needs to win in order to earn his living. Fairness is not his concern. He tries to be unfair in various ways: Keeping cards up his sleeve is one way that the rest of us universally deplore; the morality of concealing his skill to attract dupes is hardly less questionable. Fairness means at least an honest deal (no hidden cards) and no intentional concealment of one’s abilities. How do these criteria apply to the life of science? I advise my graduate students to pick a research problem that is important (so that it will matter if it is solved), but one for which they have a secret weapon that gives some prospect of success. Why a secret weapon? Because if the problem is important, other researchers as intelligent as my students will be trying to solve it; my students are likely to come in first only by having access to some knowledge or research methods the others do not have. For example, in tackling the problem of understanding human thinking, which will be the topic of chapters 13 and 14, the secret weapon that my research partners, Al Newell, Cliff Shaw, and I had was access to a digital computer, and an idea—derived from contact with computers—that it could be used as a general processor of symbols. The computer and the idea were not available to Gestalt psychologists who otherwise might have written the first programs for heuristic search. We were very pleased in the spring of 1956 when we realized that we had won this competition, that we were the first to explicate the symbolic processes that enable people to think and solve problems. But hadn’t we been unfair to take advantage of our private knowledge and our private access to computers? What merit was there in winning such a one-sided contest? One can see from this example that “fairness” in science is a rather strange, even arbitrary, concept. It isn’t unfair to be smarter than other people (but be sure you aren’t deceiving yourself!). It isn’t unfair to work harder than they do. It isn’t unfair to happen to know relevant things that they don’t know. It isn’t even unfair to happen to have the most powerful piece of equipment in the world. Nevertheless, in the contests we design for ourselves, we always have in mind some implicit criteria of fairness, and our victory is spoiled if the criteria are violated. As a boy, I used my intelligence to win in academic competition, but somehow felt superior to those who reached the same scores with less intelligence but by dint of more effort. Hence, when I was not valedictorian in my high school class, but graduated third (and shortly thereafter was also third in the University of Chicago Freshman Week examinations), I was not bothered by my ranking, for I knew that I had worked much less hard than my victorious competitors. They were overachievers! In my subsequent career, I have certainly had no aversion to being a workaholic, and have not enjoyed my successes less for having worked for them. In the high school environment, where bookworms were not suffered gladly, it was not “fair” to win by studying harder. In the world of science, with no holds barred, overachievement was the normal route to success. Nonetheless, I have probably never quite gotten over the “Look, Ma, no hands” syndrome. Success is especially pleasant when it is effortless—but it seldom is. To save appearances, one simply redefines work as fun (which, unaccountably, it usually becomes). But then, how about the long odds—the special pleasures of an underdog victory? In reviewing the record, I observe that I have always been pretty careful in setting the odds, and have usually behaved like an honest professional gambler, if that is not a contradiction in terms, taking my advantages where I could find them, never eschewing a (legitimate) secret weapon that I found at hand. In giving up thoughts of a possible political career, I felt that being a nonveteran and a Jew was too much of a good thing as far as underdogging was concerned. In one respect, however, I have quite consciously played the underdog. I have never believed that I had to be at Harvard or Stanford or M.I.T. to win the academic game. While I was a student at the University of Chicago, the university still played Big Ten football, although it rarely won a game. When one member of the team, Jay Berwanger, nevertheless made All-American during a season in which every game was lost, there was no doubt that his achievement had special luster. It was a personal achievement that owed nothing to the organization he belonged to. Although I don’t believe I consciously thought of it in this way, that was my ideal: to win without conspicuous social support, whether from family or university. Then it would be certain that I had won “fairly,” and not just by using the hidden, or not so hidden, weapon of a superior environment. I was exceedingly reluctant to leave Illinois Tech even when tempted by schools of greater reputation, and when I finally did leave in 1949, I felt a little disloyal in abandoning the challenge of helping raise IIT in the ranks of academe. Fairness is a tricky concept. Evidently it is not unfair to win the raffle of the genes—with respect to either intelligence or industriousness. It is not unfair to have the experiences or to be at the places that provide one with a secret weapon. It is unfair to inherit merit from the prestige of one’s family or organization. Put this way, the distinctions seem highly arbitrary, and I am not prepared to defend them. I simply report the rules of the game that guided my career and conditioned my feelings of success in competition. As it turned out, they provided me with an enjoyable and winnable game.

[metacog]

What I've Been Up To

Some of you might have noticed that I’m writing more often over at a blog named Commonplace recently. So what’s up with that?

The short answer: I quit my job in December and am starting a company of my own!

Longer answer: oh, good lord, where do I start.

When I joined my previous company, I did so with a three year bond to Singapore called the Tuition Grant Scheme. This was a grant given to foreign students studying in a Singaporean university; the terms were to work for three years in Singapore, or three years in a Singapore-registered company anywhere in the world. I agreed to help my ex-boss grow his company before leaving to do my own thing — and I left Singapore to go to Vietnam to do it.

When I left late last year, the company was doing well — I’d built a capable engineering office in Vietnam, and the business had grown from nearly 0 to doing $4 million in annual revenue. We built this up from the remains of a consulting business. I found and trained managers to replace me, documented all the systems I’d managed over the three years, and then transitioned myself out of the company.

I’d saved up some money from my employment to buy me two years worth of freedom. And that’s how I started on my current journey.

*

It’s been rather enlightening for me to look at my old essays and evaluate what I got right and wrong about the move to Vietnam. I wrote in Saigon:

(This is not an argument I’m going to make now, because I’m aware of my lack of historical knowledge, but my gut feel is that picking Silicon Valley over Asia is like picking Manchester at the tail end of the Industrial Revolution. You’re likely to get a couple decades more of innovation, and the people there are likely to do very well for themselves, but given the span of a human life - you’ll probably be better off attempting to be an industrialist or a robber baron in America, the rising power of the time. Cue: reference to China, or the other developing markets around the world.)

This is partly true, and partly false. A shift to China has happened in the three years I’ve been in Vietnam; in fact, the year I moved to Ho Chi Minh City was the year protests broke out across Vietnam in response to Chinese claims over the South China Sea. New protests broke out this year in response to a Vietnamese special economic zone law that was perceived to benefit Chinese companies; it’s clear that great power conflict is on the agenda again (if it ever was off it). And it’s also clear that Silicon Valley has started taking notice of Asia — Western VCs sat up and took notice when news reached them that China was a super lucrative world of its own, with a world-class digital payments infrastructure, and same-day delivery in all the seaboard cities (and in some rural areas!) way before the US.

(With some embarrassment, I should note that they’re also way ahead of Singapore).

What I’ve gotten incredibly wrong is that none of these predictions have been useful. So what if I’d gotten some of them right? Or if I’d gotten some things wrong? These predictions weren’t actionable. Getting these things right or wrong have had very little to do with the shape of an individual career. What I should have known is that you can only be good at something if you have a feedback loop; macro-economic shifts and geopolitical changes aren’t something with a feedback loop — or at least, not for a business person of my level. (If I were running a multinational corporation, on the other hand …)

What I’ve gotten good at are things at a much smaller level. I’d gotten fairly good at management, after treating it as a craft for a number of years. I’ve gotten better at product, but only within the context of the B2B world. I’ve learnt that I can survive the expat horizon in Vietnam, I’ve learnt to make pragmatic technology choices in my personal coding, and I’ve learnt that I’m very, very bad at dealing with clients — I do too much for them, for free — though I’ve gotten slightly better at it over the past two years.

Anyway. I’ve learnt pretty much everything I wanted to learn from running a company in Vietnam, and I’m as prepared as I’ll ever be. So what am I doing now?

My plan is to live cheaply in Vietnam and to build a sustainable small business as a solo entrepreneur. It’s scary in all the usual ways you’d expect it to be.

The solopreneur path isn’t one that’s new; you can read about it over at IndieHackers or at Microconf. The things that I’ve read that I recommend is Rob Walling’s Start Small Stay Small, as well as anything by Amy Hoy.

I happened to have taken a detour earlier this year to participate in an entrepreneurship program called Entrepreneur First. The program works like a speed dating app: it takes qualified individuals from startups, industry, and universities, and gets them to match up in the hopes that they’ll find a problem and do a startup by the end of the program. While I ultimately washed out, I recommend it to anyone who wants to give entrepreneurship a try — they de-risk it by giving you a S$5000 stipend a month for three months.

But now I’m back in Ho Chi Minh City, and I’m busy building things.

What have I learnt so far?

I’ve learnt that all creators go through the same emotional journey. I wasn’t prepared for this; I’m still working out ways to fight it. (I plan to write about this at some point — but more on that in a bit).

I’ve also learnt that a lot of my current procrastination stems from a fear of failure. This was a surprise — it took me two weeks of procrastinating before two close friends detected it and called me out on it. Then I meditated. I isolated the bug in my mental processes. I guess it was a surprise to me that my procrastination could stem from a fear of failure; it is completely irrational for me to fear failure right now, not with the amount of preparation I’ve done in order to take this shot. On top of that, trial and error is the best way to find out if I’m right, and if “you don’t try, you won’t succeed” (insert various other cliches).

But here we are.

I’ve gotten my ‘oh I’m procrastinating!’ detection algorithm down to one day now, which is great because it’s down from the previous one week detection period. But I’ve got a bit more to go before solving this problem, and I’m actively trying out techniques from this, this and this.

Last, but not least: I’m writing again. I currently write two posts a week at Commonplace, and it’s going to be the eventual place where I write about my procrastination, as well as the creating-as-emotional-journey post that I mentioned above.

Some background on the site: Commoncog is the thing I was building at EF; it was intended to be a drop-in replacement for Instapaper/Pocket. Development on that has stalled (due to aforementioned emotional journey), but I got it in my head that using it to write a blog on career strategy would be a great way to build an audience for the tool.

And I think some of the stuff I’ve written at Commonplace is actually pretty good. It’s what has been keeping me sane, and preventing me from spiralling into despair in response to the doubt of the solopreneur life. A short list of things I’m proud of:

The Principles Sequence — in which I summarise a book that has changed my life

A Nuanced Take on Preventing Burnout — which does what it says on the tin, and lays out the algorithm for preventing burnout that I’ve documented on this blog before, but now with 100%! More! Science! (Actually just a proper lit review lah).

Optimise for Usefulness — a first draft of my life philosophy (basically: do what works, reject what doesn’t … and all the downstream implications of this belief)

The ultimate guide to reading a book a week for your career — again, what it says on the tin. (I’m also more than halfway to my 48 books for 2018 goal!)

If you like my writing on Metacog, you’re probably going to really enjoy Commonplace. The best way to follow along is probably to sign up for the newsletter — I send it once a week on Fridays. But there’s also Twitter and RSS if you’re so inclined.

Thanks for reading this. I’m probably going to keep updating this Tumblr/tumblelog/blog with more personal stuff, restricting the idea stuff to Commonplace instead. So don’t worry, I guess, Metacog’s still going to stick around.

So that’s all for now! Till my next update!

[metacog]

I wrote another thing I'm proud of over at Commonplace, and I'll go out on a limb here and say that this is the closest thing I've got to a life philosophy right now. It sure explains how I've been approaching life for the past eight years.

[metacog]

I found my last post on stubbornness to be rather imprecise. I've expanded on it in this rewrite, which I think is clearer, and more useful. (I've also merged in the feedback of a half-dozen friends; special thanks to Paul who came up with the name). If you enjoyed my last post, read this. It's better.

[metacog]

Stubbornness

Update: I've got a rewrite of this post that is better in every way over at the Commoncog blog. Read that version here: Dismissive Stubbornness.

The Oxford dictionary defines stubborn as "having or showing dogged determination not to change one's attitude or position on something, especially in spite of good arguments or reasons to do so." For the duration of this post, I want to stick to this strict definition of 'stubborn'.

I can't work with stubborn people. This is not a new realisation; it's an old one. I can work with people who disagree with me, who argue loudly with me, and who hold vastly different opinions from me. But stubborn people don't last in my team. I actively find a way to show them the door. At my last company, I iterated on our hiring process in an attempt to catch stubbornness early, and to filter it out.

This is a pretty charged statement, so I want to colour it in. Provide nuance.

One of the most important qualities I look for in a colleague or subordinate is whatever property it is that's the opposite of stubbornness. Call it 'flexibility of thought', if you will. This doesn't mean that you have to agree with me when we disagree. It merely means that you should adopt my position when it is clear my argument is the better one. In return, I promise to hold myself to the same bar: if you present an argument that is clearly superior to mine, I should adopt your position as quickly as possible.

Notice that the condition here demands clarity: it only applies when one argument is clearly superior to the other. An example of this is if I back my argument with data. "Ten people were confused when presented with design A, but none were confused when presented with design B. Therefore we should adopt design B." You'd think that there's no way to argue against this statement, but you'd be surprised. Stubborn people find a way.

Can an argument be clearly superior to another in the absence of data? Yes, it certainly can. "Don't put that tank of water on that ledge by the servers, someone might knock it down as they pass by."

Stubbornness shows itself in how people respond to arguments. A non-stubborn response to the tank of water argument above would be "it's only going to be here for 5 minutes", or "the odds of someone knocking it down is low since nobody comes here anyway". Notice that there's an implicit acceptance that spilling water on servers are bad. A stubborn person's response would be to ignore the argument and its worldview entirely: "I want to put it here because it's closer to the flowers right outside the server farm."

This is the root of some extremely unproductive, frustrating arguments.

"But if the water falls, we'd lose $20k worth of servers and potentially a week of downtime!"

"I want to put the bucket here because I'm tired of always carrying the bucket of water up from the toilets."

"It's too dangerous to put it there, why not put it downstairs, near the stairs instead?"

"That's still too far. I'm sick of carrying the bucket that far." And on it goes, in circles.

If this seems ridiculous to you, replace "don't put the water near the servers" with "don't code that component that way; embedding the model in your view would cause the two to be tightly coupled." A non-stubborn response would accept the implicit worldview in that statement — i.e. that embedding a model in a view results in a tight coupling, and that coupling is bad. So I'm perfectly fine with an argument that goes "we don't have time to code this better, this fix is due tomorrow", or even "I don't see how this causes tight coupling". I may still think it's wrong, but I won't think you're stubborn. We can have a lively debate about it, which means that we're making progress. And if I lose that argument, no matter. It means that the better decision prevails.

The response that I cannot accept: "I think doing it this way is easier." Any response that ignores the main thrust of my argument is one where both parties talk past each other. More often than not, this devolves rapidly into a frustrating circular disagreement, where both parties go round and round unproductively.

I don't really understand why people react like this. Over the years, some of my friends have told me that such stubbornness is caused by pride or insecurity. But frankly I can't be bothered with the underlying reasons. My approach has always been to kick such people out of my organisation if possible, or to minimise the damage they can do.

I strongly suspect stubborn people are incompetent. Their inability to adapt to the realities of the world results in suboptimal decision-making. But regardless of whether it's caused by insecurity or ego, I find it too difficult to help them improve — or at least too difficult in a professional context. And so I avoid them like the plague.

[metacog]

Wonderful Twitter thread on 4 questions to ask when interviewing at a startup:

1. “How much money does the company have in the bank?” Or, rephrased: “How strong is the company’s financial position”. 

Acceptable answers: “here’s what % of our Series B is still in the bank.” or “here’s how many more months of runway we have.” 

Unacceptable: a founding/senior member of the team isn’t willing to give you ‘some sort of answer’. 

You need to know because this would affect your work directly, as well as the company’s goals. 

2. “Tell me about a time the founders disagreed. What happened?” This is phrased very specifically. Don’t ask a question that allows for an abstract answer (e.g. don’t ask “How do founders handle disagreement?”)

Acceptable answer: specific, concrete and real answer that demonstrates no big founder problems. 

Unacceptable answer: the founder keeps trying to be vague, or to answer this question in the abstract. 

3. “What is the role of the company’s board of directors?” Can have a material difference in startup outcomes. 

Acceptable: from a senior exec/founder, look for words of alignment and respect. From a junior employee: “No idea, only seen them in the office once.” Implies that the relationship is healthy: the board is out of the way operationally, and helping behind-the-scenes but not interfering. 

Unacceptable: snark and disgust, or any sign there is a unresolvable conflict with the board. 

4. “Tell me about the changes you’ve experienced at the company over the last year?”

Acceptable: Thoughtful answer about the ways the company is growing is good. Another positive is: “wow I can’t believe how much we’ve done/grown/changed/built when I think about it”

Worrisome: “Honestly, it’s about the same.” When venture-funded startups stagnate they die. 

[metacog]

Remember Bilahari Kausikan? I summarised his first IPF Nathan lecture early last year, and then covered his follow up. Well, I’ve summarised a talk he gave late last year (Oct 2017) on Singapore’s foreign policy (don’t act like a small state!) and it’s relationship with China. 

The reason it’s important is because of the latter issue. It’s become increasingly clear that China’s ascendence and Chinese influence is one of the great dangers we’ll have to reckon with in SEA. It’s a very small jump from saying ‘China is superior geopolitically’ to ‘the Chinese race is superior, and we belong to a great and ancient civilisation’. And the scary thing is that the Chinese may already be working the latter narrative into our thoughts. 

If you’re of Chinese origin, and you live in South East Asia, read this. I’ve saved you the trouble by summarising the piece, so you can cover all the main points in 6 minutes, instead of reading the full 21 minute speech.

[metacog]

Optimising for Impact vs Minimising Regret

I recently came across a time management idea that seems oddly familiar (I've probably come across it before, in some other form). The idea is that if you focus on the macro stuff — e.g. what you work on — you can skip most of the micro-optimisations for time management and still turn out to be more productive than the average person.

This is tied to two other ideas:

You should obviously use a metric like 'impact' of any activity you're doing. If you're a manager, this impact metric is probably better defined as managerial leverage.

Optimising for impact in everything you do obviously can't always work. The other thing to think about is to minimise regret.

It's not clear at first glance that the two are in direct conflict with each other. And yet they are. For instance, I burnt two weeks of work in Entrepreneur First by going back to my hometown in Kuching to visit my grandparents. This was important to me; I wasn't planning on flying back for the rest of the year in order to save money and extend my runway. This decision has likely cost me the opportunity to build a go-big-or-go-home startup in EF. But I don't regret it one bit.

If you're grappling with optimising your time for impact, remember that regret minimisation is the other framework that's important to consider. And understand that both frameworks are in direct conflict with each other.

The wisdom of picking which framework to use is something I wish for all of us.

[metacog]

Imagination: the overlooked startup ecosystem ingredient

One of the most annoying things about incubators in non-SV environments is the lack of imagination we seem to have. Founders must work on plausible-sounding ideas. Food delivery? Aye. Last-mile logistics? Sure thing! Insurance CRM with a dose of machine learning? Go right ahead. But 'platform that rents out spare air beds for conferences'? OMG wtf that's such a terrible idea. Ditto for 'online forum for everyone' and 'let's strap a camera on some dude and let him livestream his life' and 'yet another file syncing service' and 'a social network for college students'. This is a complaint post, and not one where I have a solution I can write about at the end. This is more difficult than fixing just one thing. As Alex Crompton writes: 'the best way to get a startup ecosystem going is to have successful startups' ... which strikes me as true and a solution to most complaints about non-SV startup environments. Presumably, the more successful startups are created in an ecosystem, the more imaginative everyone involved will be. Till then, we just have to slog along doing plausible-sounding, derivative ideas.

[metacog]

You don't need business school if you play board games

I was on a motorbike in Vietnam with a Taiwanese colleague, Roy, discussing board games, when he made an interesting observation: "I don't like Istanbul," he said. "If you're losing, it feels like you're being left further and further behind, and there's no way to catch up."

We had stopped at a red light, on our commute home. I downshifted and turned my head so he could hear me: "That's weird – Splendor's exactly the same, but you don't feel that way about Splendor."

"Yes."

"Hmm." I said. The light changed and we started moving. "I think it's because in Splendor, you always feel like you have lots of options even if you don't. But in Istanbul, the further you get left behind, the lousier your options are, and everyone knows it."

"Wow!" Roy said, "So that's like life! You're ok if you're poor but you feel you can do many things to improve your situation, but if you're poor and there is nothing you can do to improve your life, you feel very unhappy."

I laughed. "I guess that also explains countries, doesn't it? In Malaysia and Taiwan, people don't feel like their kids would have a brighter future compared to themselves, while in Vietnam and Singapore people do. And it makes a difference."

"This is so deep. And from a board game."

"Yes it is."

*

I've gotten into serious board games over the past year at my old company, and I've been thinking about the business skills that these games teach you. For the uninitiated, when I say 'serious board games', I mean board games that are typically known as 'Eurogames'. These games have mechanics that are richer and more engaging than the old, 'American-style' games (think: Monopoly, Scrabble, Risk), are usually played in groups of 2-5, are deeply satisfying to play repeatedly, and have made something of a comeback in recent years.

I'm going to list some of the business/life skills I've learnt from board games in this post, but I don't want to spend that much time explaining the rules and the gameplay of the various board games that I'm going to talk about. I urge you to play the games if you'd like to see if I'm making any sense.

(This is an inherently risky thing to do! I know I'm probably not going to make sense to many people – I can already imagine people playing these games a number of times, shaking their fists at me, and saying I can't possibly know what I'm talking about, and I fully expect this to happen because one's experience of a board game is heavily coloured by the dynamics of your particular gaming group. But no matter.)

The last caveat is that I'm not, of course, going to talk about the obvious life lessons from board games. This lifehacker article talks about learning to negotiate, learning to think strategically, learning to work in a team and fostering a sixth sense for reading people. Blah. These are table stakes for any kind of decent game. I'm talking about the deeper lessons, the kinds of things you learn from experiencing a large variety of board game mechanics, over a span of repeated plays from a large enough collection of games. Here goes.

The metagame of life

I think one of the most interesting aspects of board games is that the rules don't fully capture the experience of playing these games. Rules can range from simple to complex, but the emergent strategies, the interactions, and the emotions from play cannot possibly be captured from reading the rulebook alone.

Most gamers are familiar with the idea of a 'metagame' – the game of playing the game. In games like DOTA and League of Legends, constant tweaks to in-game items, character abilities and spell buffs lead to an evolving understanding of dominant strategies. Teams come up with new strategies around these game changes all the time, causing competing teams to develop responses to these strategies, which then cause teams to look for new strategies, and so on.

In trading card games, the meta is influenced by introducing new cards – with new spells, abilities, and items. In board games, however, the rules and game elements are fixed, so the meta is mostly driven by the gaming group itself.

An example of this is Splendor, a relatively simple game where you buy points (on expensive cards) with chips. The most obvious strategy is to build an 'engine': that is, buy cheap cards with no points that give you discounts for buying more expensive cards, eventually working your way to buying lots of expensive, high point cards, now made cheap due to the numerous discounts you've accumulated, and winning. But the metagame for Splendor evolves quickly, as soon as someone realises they can save up chips to buy the expensive cards, skipping the lengthy engine-building process of the first strategy. The response to this strategy, in turn, is very interesting; Splendor becomes a very different board game by the 10th play as compared to the 1st play, assuming a sufficiently competitive gaming group.

The most interesting thing about the metagame, to me, is that the experience of playing board games quickly becomes about finding and building an edge in the metagame, instead of playing the game itself. A sufficiently experienced gaming group should experience something like the following when encountering a new board game:

What are the basic rules of the game?

What is the first (usually most obvious) viable winning strategy?

Are there other viable winning strategies?

Is there a response to each winning strategy?

How can we know which strategy to use and when?

The better the game, the more complex the game, the more viable winning strategies there are.

After a couple of games, though, it becomes hard to not see the metagame in the world of business. To quote Ben Horowitz, from The Hard Thing About Hard Things:

Technology businesses tend to be extremely complex. The underlying technology moves, the competition moves, the market moves, the people move. As a result, like playing three-dimensional chess on Star Trek, there is always a move. You think you have no moves? How about taking your company public with $2 million in trailing revenue and 340 employees, with a plan to do $75 million in revenue the next year? I made that move. I made it in 2001, widely regarded as the worst time ever for a technology company to go public. I made it with six weeks of cash left. There is always a move.

When you see the business world as a metagame of strategic moves, the same generic approach to the metagame applies, and your approach becomes 'learn the rules', 'learn the strategies', and then finally 'find the dominant strategy'. Mastery in the basic elements of a specific industry gives you the ability to see which of yesterday's unworkable strategies have become viable today; I think board games give you a taste of what that feels like.

Do well in everything

I find the farming survival game Agricola to be a lot like building a company. In Agricola, you control a farmer and his wife, and you have to ensure that you end up with a good farm by the end of the game. This means executing well on a large number of dimensions: you want a large, upgraded farmhouse, a big family, a sufficient number of sheep, pigs, cows, vegetables and grain in your holdings, and you want to minimise the wasted space on your land by tilling enough field tiles, or fencing them in to become pastures for your livestock. Oh, and you have to make sure your family doesn't starve while doing so (which in turn eats into your reserves of vegetables, grains and animals).

What makes this doubly hard is that you're competing with every other player for a central pool of resources and actions. Being denied access to a particular resource or action prevents you from completing the necessary improvements in time, which then blocks the development of other elements of your farm. For example, feeding your family with livestock is a very efficient way of generating food, but this strategy requires a cooking hearth, which in turn requires clay and a build action, and of course an assortment of animals (sheep/pigs/cows). Collecting livestock requires fencing in portions of your farm to hold them, which in turn requires wood, which in turn requires taking turns to collect the wood, which prevents you from developing other parts of your farm you'll be scored on like tilling land and sowing grain/vegetables.

This is very much like business. Building a company requires you to execute well on a sizeable number of dimensions, roughly all at the same time. You need to hire sufficiently well, figure out product development, watch costs and cash flow, maintain inventory, build out various parts of the company (support, product, engineering, sales), figure out sales strategy, execute sufficiently well on marketing, build up a healthy sales pipeline, and pay attention to company culture, employee morale and employee growth, so as to minimise employee turnover and increase your efficacy of pursuing whatever high level strategy you're banking on.

And you have to do all of this with limited money and limited time.

In the early days, this feels very much like everything being broken all the time, and you're frantically rushing around putting out fires. (In Agricola, it usually means you have to get food from the fishing pond – something that isn't scalable, doesn't contribute to your farm or your score, but prevents your family from starving). Both Agricola and company building forces you to learn to prioritise: you might have a schism between two generations of employees right now (thanks to aggressive hiring you needed for the growth of the business), leading you to bleed key employees, but you need to close a deal with a major customer or your entire company is toast; so you set aside the problem of a toxic culture and close the sales deal, hoping that by the time you're done you'll have enough of a team to deliver to the customer.

Like Agricola, building a business is exhausting, but the exhilaration comes from playing well, and building something you can be proud of. It's no accident that Agricola is one of my favourite games.

What's overlooked?

One key component of finding a viable strategy is the idea of picking up on what's overlooked.

Race for the Galaxy is a civilisation card game that has four viable strategies to winning. The first skill level of playing RftG is to learn what these four strategies are. This is actually rather difficult, as nothing in the rulebook hints at what these viable strategies might be, and players are expected to figure it out, which means playing the game enough times and thinking about the many possible interactions between the 114 cards in the deck. Thankfully, at around 30 minutes per game, this is very doable.

The next skill level, though, is to learn which of the 4 strategies one should pick during the course of a game. And how does one do that? Well, you do it by looking at which of the 4 strategies are overlooked in your current game.

For example, if during a game the other players are obsessed with a producing/consuming strategy, a player that switches to a military/colonising strategy early in the game can take advantage of the many ignored military world cards to conquer a collection of high value worlds over the course of the game, hopefully ending the game early before the producer/consumer players produce large points.

This element of 'choose a strategy that is overlooked' shows itself in many other board games: in Ticket to Ride, where a player with few point-scoring tickets could make up for it by going after high-value but longer, riskier routes, or in Splendor, where you can build an edge by going after a set of relatively uncontested gem colours.

In life, however, this strategy takes the form of picking alternative competitions, instead of only going after those that are unambiguous and hotly contested. Peter Thiel tells a famous story of failing in the unambiguously prestigious, highly competitive race to be a Supreme Court clerk. He tells this story in the context of his lecture on competition: if he had become a clerk, he wouldn't have had started Paypal or become the billionaire he is today.

His conclusion was the pithy "competition is for losers", which – while perhaps not entirely accurate in the world of competing businesses – is a pretty strong argument against blindly going after competitive pursuits without first considering overlooked, alternative paths.

What are the hidden sub-skills?

I struggled when playing Splendor for a long time. By that I meant that I lost every game I played with my Vietnam colleagues, something that was to be expected given how much they'd played (and how much the meta had evolved) while I had been away to Singapore.

What made this extra puzzling to me was that the game had deceptively simple rules. I understood the rules and I understood the shape of the game, and I had been driven to desperation to google for working strategies. But I had played more than 10 games now, and it was clear that the better players in my company were able to see something I wasn't able to. They had mastered a bunch of sub-skills that were critical to playing well.

The three final pieces of the puzzle came to me around my 20th game. (I'm afraid I'm a slow learner when it comes to Splendor). The first was my colleague Tuan taking apart the level 3 and level 2 decks to show me that certain gem colour combinations were better than others. White, blue and black, for instance, tended to do better, as several high-scoring cards in the level 2 and level 3 decks cost smaller amounts of gems of those colours.

It turned out that when my skilled colleagues played, the first thing they did was to evaluate the different cards and nobles in the tableau, before picking what they thought would be the best mix of colours.

The second sub-skill was to realise that I had to keep a reserve of different coloured chips. Before I realised this, I went after one card at a time, collecting just enough chips to purchase that one card that was critical to my strategy. Naturally, when another player took the card, I was ill-suited to purchase others and had to waste turns rebuilding my chip composition. The right move was to instead build a collection of different coloured chips, to preserve my optionality, and to keep an eye on a small set of possible purchases that contributed to my overall strategy.

Finally, the third sub-skill was my observation that the good players would know when to switch from 'engine building' mode to 'end game race' mode. I haven't yet figured out how to do this, so I can't say much, but I know this skill exists; I've seen it at play.

This process of discovery was incredibly interesting to me for 2 reasons. First, it meant that the higher-level strategies mentioned in various online guides were useless until I had these sub-skills. Without the right mental frameworks to evaluate my moves, I would be so inefficient so as to render any macro strategy useless.

Second, I noticed that few of my colleagues were able to explain these smaller sub-skills to me. They were things that you were expected to pick up, naturally, as you played the game. My group of colleagues were divided into 'players that got this' and 'players that don't', and it was clear when one got it enough to make the jump from the former group to the latter, and start winning.

I believe there's something similar going on here when it comes to the other valuable skills one finds in life. Proficiency at management, for instance, comes easier to those with good people skills. This explains why management training makes good managers better, and does nothing for bad managers. Without sub-skills like 'is a good listener', 'can build trust', 'can build rapport' and 'can motivate a suitably large set of personality types', higher-level management skills like training a team or prioritising according to 'managerial leverage' whizz right over the bad manager's head. The bad manager therefore looks at his fellow good managers, who improve at a rate quicker than he, and struggles to find an explanation for his poor performance.

The idea that sub-skills aren't easily explainable is an intriguing property. My current hypothesis is that if you're naturally suited to a particular skill-set (e.g. you take to something like 'a duck takes to water'), then the sub-skills necessary for you to do well in that skill are so deeply ingrained that you experience it as intuition. (Intuitions are, by definition, difficult to explain to other people). Whereas if you're not particularly good at it, your path to greatness is to grind the various sub-skills that are necessary for you to even start using the higher-level, necessary-for-winning skills and strategies.

I see this in games: I regularly trounce people in Ticket to Ride, where I can't explain how I know to make the moves I do; but I suck at Splendor and to a lesser extent Istanbul and have to piece together various sub-skills or mental frameworks in order to have a shot at winning.

I see a similar sort of thing happening with my life. I'm an average programmer, and have had to come up with tricks to get started on a large, complex program; for writing, however, I sit down to write and find myself with 2000 words of mostly coherent argumentation a short while later.

Board games as business school

When I first started this hobby, I remember watching mathematician Gordon Hamilton talking about designing his board games:

Whenever I'm talking to parents, I tell them their number one job is not to go home and do worksheets with their children ... their number one job is to adopt a board game. And that's because the core of mathematics is problem solving, and games are the most joyous excuse for problem solving.

(Hamilton, by the way, is the designer of Santorini, one of my group's most enduring and well-loved games. I describe it as 'chess, but in 30 minutes, and with special powers').

I'm convinced that there are useful lessons hidden in playing sufficiently elegant, well designed board games, especially when you play them with a group of motivated, competitive players. These lessons are doubly effective when compared to something you learn in a business school, because you have to apply them to gameplay. The same application should hopefully make the jump to real life: the benefits of being able to map real-world situations to a simplified game is more helpful than you'd think, especially when most people have never experienced 'doing what is overlooked' or 'execute well on every dimension' in their personal lives.

I suspect Eurogame mechanics encourage strategic thinking and – like good art – imitate aspects of life that are real and true. But the best thing about board games is that you play them with other people. Hanging out over a game is fun. Playing games for lessons is just icing on the cake.

I urge you to go out and buy some today.

[metacog]

The First Date Payment Algorithm

I can't remember where I originally got this from, but there's an algorithm I've followed for paying for first dates that's worked out pretty well for me. I detail it as follows.

First, the context: I am a Chinese heterosexual male. I've lived in Vietnam, Malaysia and Singapore.

Second, the premise: there are many possible optimal matches that one can have. (Conventionally, this is also known as 'there are many fishes in the sea', or 'there is no such thing as The One'; for a humorous treatment of the latter, see this). If you're dating, you're looking for a good match for you. Therefore it follows that being rejected is a good thing. Anything you can do to filter out women who aren't interested in you is a good thing. Finding out quickly that there's no chemistry is a good thing. It frees both of you up to find a good match for yourselves.

The next premise is that first dates are fraught, nervous affairs, and anything you can do to standardise it a bit is good.

Third, the algorithm:

When the time comes to pay for the meal, if the lady does not offer to pay for her half, then you should get the bill. Don't make any remarks about it if she doesn't.

If she does offer, graciously accept and – again – don't make a fuss.

Move on with the date.

Fourth, why does this work? (Or more accurately, why does this work for me?)

There are a few things at play in this algorithm.

The first is that it smoothens over the payment for the first date. This is normally a point of stress for both parties, so by using the above process, you're removing some of the tension for yourself, and hopefully for the other party as well. Note the bit where it says don't make a fuss. The quicker you can make this a non-issue, the better the rest of the date will go.

The second is that this algorithm follows another principle I hold dear: that you should always take a person at their word (or, perhaps more accurately, you should only get involved with people who say what they mean and mean what they say). There are women who offer to pay but expect you to fight for the bill and secretly expect you to pay. I don't want to get involved with women who do this. This algorithm filters them out.

(If you don't mind women who expect you to double-think, then this algorithm does not work for you, and you should stop reading here).

Third, this algorithm side-steps the thorny issue of interpretation. Women have a dazzlingly diverse number of interpretations for this first-date payment issue. There are women who believe in egalitarian relationships, and would only desire men who let them pay for their share. There are women who expect a man to pay for all dates, because of traditional gender roles. There are also women who think that a man should pay for dates, but that one should split in the beginning when there is no relationship, as it is only 'fair' to do so in case you don't end up together. There are also interpretations where women don't want to owe a man anything, and they pay in order to avoid this feeling of debt.

This algorithm avoids all of this. You let the woman pay her share if she requests for it, otherwise you pay. You make no fuss either way.

Fourth, note that this algorithm has nothing to do with your preferences for egalitarianism. Some men prefer women who adhere to traditional gender roles (guy pays for everything). Others prefer women who are more independent, or who prefer an egalitarian relationship. Whichever you prefer is a separate issue from the 'first date payment issue'. If you discover, through subsequent dates, that the woman you're dating only ever wants you to pay for your dates, then you can decide to break it off quickly if you are the egalitarian sort, or continue if you prefer traditional gender roles.

The truth is that Asian societies are still modernising, and you're likely to meet women from both sides of the traditional/liberal divide. This algorithm comfortably straddles both sides, and makes a normally fraught exchange less stressful. I hope it helps you as much as it has helped me.

[metacog]

Work Life Balance

Professor Ben Leong’s old post on Work Life Balance has been on my mind recently.

To summarise crudely, “work life balance is a privilege that should be earned at old age; it doesn’t excuse you from working hard to earn that privilege when you are young.”

From talking with friends, one of them said:

Desmond Ng, [20.09.17 21:46] I think striving for a work and life balance even when you are young does not mean that you cannot maintain a good lifestyle as you get older

Desmond Ng, [20.09.17 21:47] Working a lot of hours does not guarantee you work life balance as you get older, as he has rightly pointed out

Desmond Ng, [20.09.17 21:48] Likewise, the working with having a good balance in mind does not mean you can't have it good as you age

Of course, Desmond’s just saying ‘it’s not so simple, more nuanced than that’ and yes, I agree, it is nuanced. 

It seems like there’s a middle ground between “work so hard until your face falls off, that’s the only way to win, you have to earn your work/life balance!” vs “strive for work life balance because nobody says ‘I want to spend more time in the office’ on their death beds.”

This is very nuanced territory, so I’m just posting this to remind myself that I should write about it to explore all the nuances sometime in the future.

[metacog]

Follow Up To Generality And Power

Cedric Chin: if i reflect on the way you use 'spoonfeeding' as an accusation

Cedric Chin: it's more like

Teacher - nah, X

Student - ok, X

later, when coming across thing that is directly implied by X,

Student - huh really meh

and I guess this is what you're accusing me of?

Shawn Tan: ya

Shawn Tan: if I write X down in my notebook

Shawn Tan: and didn't think of at least some of the implications of X

Shawn Tan: I wouldn't see how X now interacts with the other things i already know

Shawn Tan: it's just a disconnected node

Cedric Chin: huh

Cedric Chin: yeah i don't think i'm very good at this

Cedric Chin: as in all of uni feels like a slow slog to learn to do this

Shawn Tan: this is in fact what you told me Michael told you when you ask him how he learn things fast

Cedric Chin: huh. All I remember is he said 'keep the feedback loop small'

Cedric Chin: or at least that's what i remember most of it

Cedric Chin: i can't remember this

Shawn Tan: and i guess to add on to that

Shawn Tan: when you encounter something you think is new, you should test it against what you already know, and if you realise you could've deduced it from what you knew by some process

Shawn Tan: then the outcome of that whole thing is to now learn that process

Shawn Tan: so you're not "surprised" by something you could've inferred again

Yee Sian: but sometimes connecting the dots can be hard, or time-consuming

Yee Sian: and it might be more efficient to batch the process

Yee Sian: like, learn an entire new cluster of dots, and how they're connected within themselves first

Yee Sian: before attempting to connect that cluster to the other clusters you have

[metacog]

Reversing 'Top Five Regrets of the Dying'

Some years ago a palliative care nurse, Bronnie Ware, recorded the top 5 regrets of the dying (Guardian coverage). Paul Graham then turned these into 5 commands:

Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; choose to be happy.

I put them at the top of my todo list, where it's stared at me every day since 2012.

I recently looked at them again and thought that it would do some good to make them more precise. I don't remember what each of them meant, specifically – for instance a platitude like "choose to be happy" isn't very useful. What formulation of happiness did it mean? What did Bronnie Ware originally thought it meant, when she recorded it?

Don't ignore your dreams

Minimise regret. Unfulfilled dreams is one form of regret. Therefore minimise unfulfilled dreams. When your health gets bad, it is too late to pursue your dreams.

Don't work too much

Make more time for your kids and loved ones. The extra income won't matter as much in the end as the time spent with kids and loved ones. Simplify to create this time.

Say what you think

This is vague. Bronnie Ware says:

Many people suppressed their feelings in order to keep peace with others. As a result, they settled for a mediocre existence and never became who they were truly capable of becoming. Many developed illnesses relating to the bitterness and resentment they carried as a result.

We cannot control the reactions of others. However, although people may initially react when you change the way you are by speaking honestly, in the end it raises the relationship to a whole new and healthier level. Either that or it releases the unhealthy relationship from your life. Either way, you win.

Perhaps a better formulation of this is: 'express your feelings'. If you suppress your feelings to keep the peace with others, you will settle for a mediocre existence (presumably due to bitterness and resentment).

I think there's a principle in Ray Dalio's Principles that goes something like 'build your ideas of a person from talking directly with them'. (I could be misremembering this, of course). Instead of building up a fake edifice in your head (e.g. he or she acts in a certain way, and you don't know why so you invent reasons), speak your mind and find out why from the person. This should reduce friction and bad relationships.

Either the relationship will be strengthened as a result of this, or the relationship will die and you would be free.

Wow, this is a good reminder. I think I should change this to 'overcommunicate in relationships'.

Cultivate friendships

Loneliness kills (meta analysis). Men are more susceptible to dying alone and becoming friendless in old age.

Therefore, to be more precise, as a man: share emotional intimacy with male friends, don't just stick to abstract topics. Make an effort to keep in touch. This matters.

Choose to be happy

Also unclear. Bronnie Ware, in the original:

This is a surprisingly common one. Many did not realise until the end that happiness is a choice. They had stayed stuck in old patterns and habits. The so-called ‘comfort’ of familiarity overflowed into their emotions, as well as their physical lives. Fear of change had them pretending to others, and to their selves, that they were content. When deep within, they longed to laugh properly and have silliness in their life again.

When you are on your deathbed, what others think of you is a long way from your mind. How wonderful to be able to let go and smile again, long before you are dying.

I guess this means choose to be happy, regardless of what's happening to you. There are known techniques for this. Write down what you are grateful for. Meditate. Remember to be silly. Takes risks once in awhile. Do new things instead of giving in to the monotony of life. All the usual things for taking yourself out of your own existence.

There's no good way to reduce this piece of advice to something short and snappy. I guess the best I can come up with is 'choose to be happy with known mindset hacks'.

So, the new list is now:

Don't ignore your dreams; don't work too much; over-communicate in relationships; cultivate friendships; choose to be happy[1].

[1] with known mindset hacks.

[metacog]

Why can't you just spend more time debugging?

Slightly frustrated rant ahead: I believe that programmers with a bias towards banging their heads against the terminal become better programmers faster than the ones who don't.

While that sounds like a d'oh statement, the implication here is that maybe programmers who ask for help tend to improve slower.

This isn't fair, of course. And I'm not convinced it's true. But it's a chicken-and-egg problem: the programmer who debugs and sticks with it does so because she is confident in her ability to eventually solve her bug. Newbie programmers don't have this confidence. So where does such confidence come from in the first place? From successfully debugging, of course!

How one becomes the other is beyond me. Perhaps you have to like debugging enough. Or perhaps you have to be supremely confident in your ability to get out of shit.

I've recently been annoyed at subordinates who ask too many questions. My friends – stuck in similar roles in other companies, in a variety of geographical locations, with differing responsibilities – have rather similar opinions on this. We meet once in awhile and complain to each other over drinks, the complaints punctuated with grunts of commiseration. Which is why I've been thinking: is this really our problem?

When programmers don't bang their heads against their terminals long enough, they don't develop the intuitions necessary to debug future, similar problems. And so they continue to ask questions. Asking questions and getting answers are an easy out: you get to move on from your bug or quit your debugger, but at the expense of developing a better understanding of your work.

Maybe one way out of this is to ask questions, but then to also put in the time to develop a deeper understanding. But I'm not convinced this works; I've never found myself to benefit from deliberate studying of large systems. Instead, I've found that I learnt best from banging my head against bugs as I modified stuff, or tripping on myself in the terminal, or learning to listen to the idiosyncratic complaints of my compiler. In this way, programming is like getting to know a lover: when your SO says she doesn't like your fixation on work, what she really means is that you were too busy checking Facebook on your phone on your last date and she's now feeling insecure. And when your program complains about a nil pointer exception, maybe you forgot to declare a variable properly. Either way, there's no easy way to link one complaint to the recommended fix until you've spent enough time Debugging. Your. System.

The upshot here is that I don't know what to do about all this. I only know that I get frustrated (and often very curt) to subordinates who ask too many questions. Perhaps this is a personality flaw, one that I need to fix.

I wrote this in a chat with a junior programmer today:

Tangential feedback: the reason I could quickly debug your problem earlier is because I spent 5 hours frustrated and trying to get things to work as a student. I still remember that session. It was over the summer holidays and I wanted to go do something else but I was stuck. But because I had put in the time to bang my head against the terminal, I gained an intuition of how such problems happen. Those 5 or so hours has paid for itself in the years since.

You haven't spent the time to build such intuitions of the systems you are building. In the future, if I say to you "keep at it", I mean keep working the problem because I want you to gain this intuition.

Right now your bias is to ask many questions without sufficiently trying hard at it. This is not good because your growth will be stunted.

But there is also a balance. If you are stuck too long, you can't finish your tasks on time and that is bad for you and your team. But if you ask too often and too early, you are wasting your manager's or senior's time, time that is more valuable than yours because their dollar-hour is higher than yours. (And of course you aren't learning nearly as much)

Right now your bias is towards asking too much. There are others whose bias is to ask too little.

I want you to time box yourself in the future. If there is bug, keep at it for 1.5 hours, with no distractions. No FB, no Twitter, no random things. Then when you ask, say "I have this problem, I have tried X, Y, Z because I think it is caused by A, B, C". That proves to your senior that you have tried, and you have thought through the problem, and you are able to communicate where your understanding of the problem is at.

I don't know if that message would make any difference. I don't think I was particularly rude, but maybe I was. Tell me if I'm missing something.

[metacog]

Don't Yuck Someone Else's Yum

This is a personal reminder. I don't like Rails. But that doesn't mean one can't be productive in it. It also doesn't mean that Rails can't be used to solve business problems. And solving problems is why I got into programming in the first place.

[metacog]

Debian Stretch 64

Two years ago I started a side project, created a Vagrant file, and started coding. The base image I used was Debian Wheezy. Less than a month later, Debian Jessie came out. I had to switch, and I broke things. This made sense given that I didn't know how to use Vagrant properly at the time. Two years later, the side project still not launched, I decided that I would redo the Vagrant box with lessons I've learnt since. So I wrote a new Vagrantfile, based off my old Jessie one ... and discovered Debian Stretch had been released. Debian releases come out at a glacial pace. This was as strong a signal to me that the project was dead, and that I hadn't built what I told myself I'd built. I'd been telling myself another lie.