The Method of Research

Today I’d like to talk about my own method for doing research — a method that has followed me for many years and is still evolving and being refined. I never did a PhD (I hope to give it a try in this lifetime), but I’d say the method isn’t bad — at the very least, it lets me enter a new field efficiently and put down roots in it. If you’ve been reading my essays and wondering how this “programmer gentleman” manages to cover such broad ground (yes, I do love to flatter myself) while digging reasonably deep (I’m moved to tears by my own handsomeness), then read this piece carefully — as I always say, I hope it’s useful to you and gives you even a little inspiration.

Start by Asking Yourself “Why”

Simon Sinek says great leaders start with why. To enter a new field, you have to be clear with yourself about why you’re entering it — it could be love, or it could be fear; both emotions can push you a long way. Love is a positive emotion, expressing your interest; fear is a negative emotion, meaning you’re afraid of losing something. Of course we’d like positive emotions to drive us forward, but if you’re doing something out of fear, you shouldn’t worry too much about it or beat yourself up — because emotions transform as circumstances change. How many people genuinely love working overtime? It’s the fear of losing a promising job, the anxiety of falling behind the people around us in tech, that makes us work overtime. We put in the time, we produce results, and that better-than-expected feedback makes us happy, which makes us more willing to put extra time into technology. When my eldest daughter first started learning piano, she resisted practicing fiercely, crying and screaming and refusing to cooperate — it was the fear of her mother threatening to draw a big X on her homework if she played badly, and of the teacher criticizing kids with X’s on their homework and refusing them stickers, that forced her to finish her practice. Over time, the practice paid off; the pieces she played were beautiful and moving, and she gradually went from fear to love of the piano. Every so often she’d practice on her own initiative, even exploring different variations of the same piece, remixing several pieces together, trying to invent new ones. So we see: effort driven by fear, once it’s rewarded, has a very good chance of turning into love.

So a good research field is either sufficiently cutting-edge (to spark passion), or able to make up for what you currently lack (to dissolve fear).

Once you’ve chosen a direction, the next step is to understand the big picture and the status quo of that direction.

Grasp the Outline, Master the Whole

This step matters. Diving straight into details is not a good thing — it’s like painting: you first compose the picture from top-left to bottom-right, sketching out the large shapes, then recursing on them until the details you want are carved out.

Let’s take blockchain as an example. From a technical standpoint, the biggest picture might look like this:

Under this picture, some things are already familiar to you, like the TCP/IP stack — you can set those aside for now; others are new technologies, like open ledger — you can recurse into those and refine further. Throughout this process, ask yourself a lot of questions:

• Why is this technology needed? What known problems does it solve?
• What does it involve? (Recurse on this in the next step.)
• What does the history of this technology’s development look like?
• If there are multiple solutions, what are the pros and cons of each?
• Given a blank sheet of paper, can I draw the big picture that this technology covers?
• Where is this technology headed? What’s the latest direction?

These questions are all fairly intuitive, so I won’t elaborate on each one. They’re all important questions that you need to answer as you research — but more important is finding the questions you consider even more important.

Here I’ll cover three key points: ask questions, find the history, compare/analogize.

I forget who said it, but asking the right question matters more than finding the right answer. The ability to ask questions reflects a person’s scientific literacy; people who consistently hit the nail on the head tend to have higher scientific literacy. Asking the right questions depends on two things: 1) prior knowledge, 2) a method for asking questions. The former accumulates slowly; the latter has methods — for instance, The McKinsey Way discusses how to ask questions, and there’s the experience of those who came before, such as the list I gave above.

If you’re also reading Bitcoin, you might have questions like these:

Questions about the numbers:

1. Why is the block designed to be 1M?
2. Why is the total supply 21 million — not 20.48 million, not 40.96 million, but this strange number, 21 million?
3. Why one block every 10 minutes? Why is a block considered confirmed only after 6 blocks?
4. Why base58 (WTF)? Why not the base64 we all know?
5. Why is transaction speed so slow — only a handful of tx/s?

If you never ask why about the numbers, you can only be a slave to the numbers — someone who memorizes, hardly someone who understands.

Questions about ideas:

1. Why build an open ledger? Pros? Cons?
2. Why a chain?
3. Why PoW? Why aren’t existing methods usable? (Uh — what existing methods are there?)
4. Why give miners the room to generate seemingly meaningless empty blocks?
5. Why hash the wallet address once instead of just using base58 of the public key?
6. Why design UTXO?
7. Why is a Merkle tree needed?
8. Why ECDSA instead of RSA?
9. Why double hash?
10. Why little endian instead of big endian (network order)?

This list can go on and on.

Tracing history is an act of going back to the roots, and it makes your knowledge more systematic. Every piece of new knowledge and theory produced in this world bears the shadow of predecessors — as Newton said, he stood on the shoulders of giants; that wasn’t modesty, it was fact. If we study a single point, what we learn is isolated and hard to spark further thought. But if we bring history in and connect the scattered points into lines and planes, we can compare, synthesize, and abstract far better — and thereby acquire knowledge that is truly our own. For example, when you look at Bitcoin’s consensus and understand PoW, you can then look at the whole history of consensus, learning that Bitcoin’s PoW came from hashcash, and that the fundamental problem underlying consensus is the Byzantine generals problem. So what other consensus algorithms fall under this category? PoS (Proof of Stake), PoI (Proof of Importance), DPoS (Delegated Proof of Stake), PoD (Proof of Devotion), PBFT (Practical Byzantine Fault Tolerance)… And so on — these are all consensus in the blockchain world, that is, consensus in a trustless environment. Then, how is consensus solved in a trusted environment? So you learn about Paxos, Raft, and ZAB (Zookeeper Atomic Broadcast Protocol) used by Zookeeper, and so on. Now you have a tree-shaped body of knowledge about consensus.

One caution while tracing history: don’t get lost in details too early and lose your bearings. Find the big picture first, then refine — this always applies.

After tracing history, we’re left with a pile of new terms and new knowledge. Next we need to compare and analogize them, so as to induce and summarize. Comparison/analogy can be done along many dimensions, making knowledge truly yours — because in the process, more questions get discovered from more angles.

Below is a comparison I came up with while looking at blockchain — a fully unmanaged distributed system — against solo systems and managed distributed systems (cloud computing):

Though this comparison is only a few rows long, it condenses a lot of thinking — what dimension should the vertical axis use, exactly? I’m sure you and I would produce different lists — this is a very open-ended exercise with no standard answer; as long as you think and compare, you’ll gain something.

Although I lump comparison and analogy together, the two are quite different. Comparison emphasizes classification, induction, and summary; analogy emphasizes extension and deduction. These days everyone analogizes blockchain to the Internet of the nineties — so what successful directions emerged in the nineties Internet, and what successful directions has blockchain produced now? Can we analogize early Yahoo (an index of websites) to today’s Binance (an index of cryptocurrencies)? Then what does Sina analogize to? What does Google analogize to? And what does Geocities analogize to?

Many good ideas come from analogy. ArcBlock, which I mentioned in an article a few days ago, analogizes the hundred schools of blockchain contention to the flowering of database technologies — so what ArcBlock wants to do is what ODBC/JDBC did. The service ArcBlock provides is “AWS for blockchain” — clear and obvious.

Understand the Status Quo

Actually, if you’ve worked through the big picture along the lines above, the status quo falls out naturally. Still taking blockchain as an example — what is its status quo? The slide below lays it out clearly, and we can adopt a similar approach when we’re organizing the status quo of any technology:

(Image source: https://gomedici.com/an-overview-of-blockchain-technology/)

Teach to Learn

I’ve mentioned elsewhere that I’m a devoted adherent of, and beneficiary from, “learn by doing, learn by teaching.” Sharing (knowledge) is a joy, and it lets you gain even more — as the saying goes: “All under heaven know that taking is taking; none know that giving is taking.” Once I have a big picture of what I want to study, when I go deeper into the details I approach the learning from the angle of how to teach what I’ve learned to someone else. This method mainly helps me in these ways:

• It pushes me to take better notes and consolidate what I’ve learned.
• It forces me to restate the knowledge in my own words — which both reinforces it and prevents the awkward scenario of “I thought I understood it but actually didn’t.”
• When teaching it to others, either I’ll realize that somewhere I’m in “I don’t know that I don’t know” territory, or the audience will ask a “newbie” question that I’d never have asked myself, prompting me to realize “I don’t know that I don’t know” — and thereby patch the gaps in my knowledge.
• (Side effect) It improves my public speaking ability.

Stealing Lessons from the Masters

As I said earlier, every piece of new knowledge and theory produced in this world bears the shadow of predecessors. To make a breakthrough, it’s far from enough to exert force only at the point where you want to break through — we first have to steal lessons from the masters and build a complete tree of knowledge. “Stealing lessons” here means not just studying, but copying — deliberate imitation. When my daughter learns piano, she follows the fingerings the teacher taught, imitates the motions in the videos, works through sheet after sheet, practicing again and again — that is imitation, very, very deliberate imitation. Humans (or perhaps all living things) are terrible at imitation; no matter how much effort you spend, you only ever approach the original infinitely — for example, you can’t replicate my handwriting, and even I, copying “Ode to the Goose” ten times, produce thirty geese each with a different shape; you can always spot some small difference. Yet we should thank the Creator for giving us this incapability / imperfection — it’s what lets us live as ourselves. Kobe, who just won an Oscar, stole lessons from many people on his road to superstardom — stealing shooting from Jordan and Dirk, footwork from The Dream, and so on:

But Kobe found that his height, build, wingspan, muscle strength — all these attributes — differed from the predecessors he admired, so he couldn’t copy them precisely (even if the image above is nearly pixel-perfect). He had to adjust a great deal to make the techniques he copied fit his own body. Even if each refined move bore the shadow of the superstar he copied it from, taken all together it resembled no one — it belonged only to the name Kobe. This confirms the old saying: Copy from one author and it’s plagiarism; copy from many and it’s innovation. Of course, copying is not as simple as cut-and-paste. Like Kobe, greeting the sun at four in the morning, practicing relentlessly over and over, and constantly pondering: why does this move unfold this way? Why this angle for this posture? How do I make this move fit me better?

So what he copied was not just the style, but the thinking process behind it — this is part of internalization.

Imitate, copy, think (ask questions), internalize; look widely and take selectively; accumulate deeply and release with restraint. And then you have your own branch:

This is what we spend a lifetime doing from the moment we’re born (or from the moment we become a fertilized egg): after inheriting more than ninety percent of our parents’ genes, to light up a new branch — yourself.

Let me ramble a bit more on this topic. Lately, the terms “classical Internet” and “classical blockchain” have suddenly become fashionable. A friend messaged me privately asking what I thought of so-and-so’s whitepaper; I said I was still huffing and puffing my way through Bitcoin. My friend shot back: “We’re at 3.0 already — why are you still studying the 1.0 ‘classical blockchain’?”

WTF! Are u OK? Are u zhengde OK?

You can mock yourself with terms like “classical Internet” and “classical blockchain,” but you mustn’t negate yourself (if you’re in that space), and you shouldn’t crudely disdain things that aren’t on the crest of the wave. We should hold the wisdom of our predecessors in awe, and stay away from the behavior of spouting buzzwords and stacking up concepts without seeking real understanding — didn’t Dada always remind us: “When you see the good, pursue it as though you can never catch up; when you see the bad, recoil as though scalded by boiling water”? A canopy without roots, trunk, and branches to support it is a castle in the air; it cannot last.

Closing

Much more could be said, but I’ll stop here. One final point: give yourself a little patience, and then a little more. Shakespeare said: all the world’s a stage — sometimes you’re in the foreground, sometimes backstage. In research, most of the time is the huffing-and-puffing, slow-simmering work — it’s backstage, it’s the lining, it’s the silent drifting of the Kun fish before it transforms into the Peng bird. “Striking the water for three thousand li, spiraling up on a whirlwind to ninety thousand li” is certainly grand and magnificent, swallowing mountains and rivers — but before that, you have to endure solitude and keep the green hills intact.

But things don’t necessarily go the way you expect; by the time you step on stage, the feast may already be over. You have to accept that. Don’t you see Bitcoin miners burn countless hashes on empty computation and end up drawing water with a bamboo basket? And still they shake the dust off their sleeves, feel a second of pain for the electricity meter, and go on computing the next block, until their own moment arrives. Wong Kar-wai, in The Grandmaster, tells us: we live one life; some people live it as the face, some as the lining — all is circumstance. Neil Gaiman says: make good art. That’s the attitude research demands.