Researching an Unknown Technology
"What is Redis?" Do not read everything. Ask why you might need it, what problem it solves, what it guarantees, what the simplest example is and how it fails. Five answers on one page beat a weekend of reading, and they tell you what to learn next — or that you do not need to.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
A technology you have never used keeps coming up — in a code review, a job posting, a colleague's suggestion. How do you research it in an afternoon and come out with a decision rather than a vocabulary?
A reviewer on the store's cart pull request writes "why isn't this in Redis?" You have heard of Redis, you know it is fast and involves memory, and you have a browser tab open on its home page, which describes it as several things at once. You do not know whether the reviewer is right, and you do not know how to find out without a weekend.
Read about Redis. Start with the overview, then the data types, then a couple of blog posts on "Redis for caching", then a video. It feels like the responsible response to not knowing something — you are, after all, learning it.
The weekend produces a vocabulary — strings, hashes, sorted sets, pub/sub, persistence modes — and no answer to the reviewer, because the reviewer's question was about the cart and none of the reading was.
- The weekend produces a vocabulary — strings, hashes, sorted sets, pub/sub, persistence modes — and no answer to the reviewer, because the reviewer's question was about the cart and none of the reading was.
- Reading everything reads the general case, and the general case is everything Redis can do for anyone. Whether it should do anything for this cart depends on what the cart needs, which no amount of Redis reading reveals.
- Halfway through, the technology starts to look like the answer to problems the store does not have — sessions, rate limiting, leaderboards — and the pull request grows a plan to adopt it broadly. Motion, and the cart no better understood.
- The next unfamiliar technology gets the same weekend, because nothing about the method scaled: it was reading, and reading has no stopping rule.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Refuse the question "what is X?" and replace it with five that have stopping rules: why might I need it (what in my system would it touch), what problem does it solve (the one sentence it exists for), what does it guarantee (and what it explicitly does not), what is the simplest example (that I can run in a scratch file), and how does it fail (what happens when it is down, full, or restarted).
- Answer the first question before opening any documentation, because it is about your system, not the technology. "The cart is read on every page and written on every add; the reviewer thinks the reads are slow or the database is the wrong place for short-lived data." Now the research has a target.
- Answer the next four from the technology's own documentation, reading for the answer and stopping when it is found. Each answer is one or two sentences. The simplest example is run, not read. The failure modes come from the persistence and operations pages, not the overview.
- End with one of three outputs: a decision (adopt for this need, with the guarantee and failure mode that justified it), an experiment (the specific question the five answers could not settle, and the scratch test that would), or a "not yet" with the requirement that would change it. A vocabulary is not one of the outputs.
The research plan is an unknowns board
"I don't know Redis" is a feeling. The board turns it into five researchable questions with an experiment attached to each, and the board is the deliverable: when every row has an answer, the research is done whether or not the documentation has been finished.
Note what is on the known side before any reading: the store's own situation. That is the part of the research that only you can do, and it is the part that decides what the rest is for.
- ✓The cart is read on every page load and written on every add; it lives in the orders database today.
- ✓Nobody has measured cart read latency; the reviewer's concern, when asked, was clutter in the orders database rather than speed.
- ✓Carts are short-lived for guests and long-lived for logged-in customers.
- ~The database can serve cart reads fast enough with an index on customer id. To be measured, not assumed, if the decision turns on speed.
? What is Redis?
becomes What is the one problem its authors say it exists to solve, and does the cart have that problem?
experiment Read the one-sentence purpose on its own site; write the cart's problem next to it; compare.
? Is it safe for carts?
becomes With default configuration, what happens to a stored cart when the server restarts, and when memory is full?
experiment Set a cart, restart, get. Then set a small memory limit, fill it, and observe which keys vanish.
? Is it faster?
becomes Is the cart read on the product page measurably slower from the database than the page can tolerate?
experiment Time the cart query with an index; compare with the page's render budget before adding any component.
? What would we have to run?
becomes What does operating it cost — a process to monitor, a persistence setting to choose, a fallback when it is unavailable?
experiment Read the persistence and operations pages; write the three decisions a deployment would force.
Four rows, four experiments, one afternoon. The board ends with a decision, an experiment or a "not yet" — the three acceptable outputs of research.
Read for answers, not for coverage
The pipeline is the same five questions as a sequence, with the failure of each step named. The order is not arbitrary: the first question is about your system and must come before any reading, and the last — how it fails — is the one the overview will never volunteer and must be sought in the operations pages.
Each step has a stopping rule, and that is what distinguishes it from reading. When the answer exists in one or two sentences, the step is done, whatever else the page says.
- 1Why might I need it
Name the component, the operation and the measured or specific problem in your system.
fails by Answering with the enthusiasm of whoever suggested it, or with "it seems slow".
- 2What problem it solves
The authors' one sentence, placed next to your problem.
fails by Reading the feature list and finding something for every problem you have.
- 3What it guarantees
What is promised and what is explicitly not — atomicity, durability, ordering, delivery.
fails by Assuming that a well-known tool guarantees the thing you need.
- 4Simplest example
Install, one write, one read, one restart, in a scratch file.
fails by Reading the example and calling it run.
- 5How it fails
Down, full, restarted, partitioned — from the operations pages.
fails by Stopping at the overview, where nothing fails.
- 6Alternatives, then output
Name what you already have; choose decide, experiment or not yet.
fails by Ending with a vocabulary, or with a plan to adopt the tool for problems you do not have.
The learning map at /thinking/learn-map runs the first step for a whole project: from "I want to build X" to the domains each requirement actually needs.
What the research may conclude
Research that can only conclude "adopt" is advocacy. The three legitimate outputs are listed below with the criteria that pick each one, and "not yet" is a full result, not a failure to reach one — it carries the requirement that would change it.
The cost column is what each output leaves undone.
What do the five answers support?
when The problem is specific and measured, the purpose matches, the guarantee needed is one it makes, the failure mode is acceptable or handled, and the alternative you have does not meet the need.
cost A new component to operate, with the complexity ledger owed: what it solves, what it introduces, what happens when it fails (The Complexity Ledger).
when Four answers are clear and one turns on something only a test can settle — a latency, a behaviour under restart, an interaction with your existing data.
cost A scratch project and a day; the decision waits on evidence, which is the point.
when There is no measured problem, or the alternative you already have meets the need, or the failure mode is worse than the problem.
cost The requirement must actually be written down and watched; a "not yet" with nothing attached is a "no" that will be re-litigated.
How to do it
Most important first.
- Write the "why might I need it" answer first, in terms of your system: which component, which operation, which measured or suspected problem. If there is no problem, write that; the research may be over (What Problem Does It Solve?).
- Find the one-sentence purpose on the technology's own site or docs — the sentence its authors use — and write it next to your problem. If they do not match, stop.
- Find the guarantees page, which is often called persistence, durability, consistency or delivery. Write what is guaranteed and what is explicitly not (Guarantees and Failure Modes).
- Run the simplest example in a scratch file: install, one write, one read. Then restart the thing and read again — the restart is the cheapest failure-mode experiment there is.
- Name the alternatives, including the one you already have. "Keep the cart in the database with an index" is an alternative, and the research is incomplete without it (Evaluating a Technology).
- Write the five answers on one page and choose an output: decide, experiment, or not yet. Put the unanswered questions on the board, not in your head.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Why might I need it: the cart is read on every page load and written on every add; nobody has measured whether the reads are slow; the reviewer's actual concern, when asked, was that carts are short-lived and clutter the orders database. What it solves: fast reads and writes of small values held in memory, with optional persistence. What it guarantees: an operation on a single key is atomic; persistence is configurable and by default may lose the most recent writes on a crash. Simplest example: set a cart, get it, restart the server — with default settings the cart came back, then a second run with persistence off lost it.
- How it fails: if it is down, every cart read fails unless the code falls back; if memory is full, it evicts keys according to a policy the operator sets, which for a cart means a customer's cart silently vanishes; if it restarts, whether carts survive depends on a configuration decision the pull request would have to make. Alternatives: a cart table in the existing database, cleaned up by a scheduled job; the cart in a signed cookie for guests.
- Output: not yet. The cart is not measured to be slow, the "clutter" concern is a cleanup job, and the failure mode — carts vanishing on eviction or restart — is a worse customer experience than the one being avoided. The requirement that would change it: a measured read latency on cart pages that the database cannot meet after indexing, or a guest-cart volume that makes cleanup itself a problem. That answer took an afternoon and is written on the pull request.
- The same five questions for the chat app's "should we use a message broker for delivery?": why (messages must reach recipients who are offline), what it solves (durable queues between producers and consumers), what it guarantees (at-least-once delivery, so duplicates are possible), simplest example (publish, consume, restart the consumer, consume again — the message was redelivered), how it fails (a consumer that crashes mid-message sees it again; a full queue blocks or drops depending on configuration). Output: an experiment — does the chat app's message store already give offline delivery by being a database? — before any broker is added.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The five answers fit on one page and each is in your own words.
- The simplest example ran, and you restarted it and observed what survived.
- The research ended with a decision, an experiment, or a "not yet" that names the requirement that would change it.
- You can say what the technology is not for, which is the sentence the overview never contains.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What in my system would this technology touch, and what problem there is measured or specific enough to justify researching it?
- ?What is the one sentence this technology exists for, in its authors' words — and does it match my problem?
- ?What does it guarantee, what does it explicitly not guarantee, and which of those does my problem depend on?
- ?What is the smallest example I can run, and what happens when I restart it?
- ?What is the alternative I already have, and what would have to be true for it to be insufficient?
What can go wrong
- The five questions become a rationalisation of a decision already made — "why might I need it?" answered with the reviewer's enthusiasm rather than the system's problem. The first question is about a measured or specific problem, and "it seems slow" is neither.
- The simplest example is skipped because the docs were clear. The restart experiment is the one that finds the persistence default, and the docs describe it in a sentence most readers do not notice.
- The alternatives are omitted because the research was about one technology. Research that ends with "Redis fits" without having asked whether the existing database fits has evaluated one option.
- The method is applied to a technology the team already runs, producing a page that an existing operator could have said in a minute. Ask them the five questions instead (Asking People).
- Five answers are a first evaluation; they can miss the sixth property that decides the case — a licence, a memory ceiling, an operational requirement. Depth is traded for a decision in an afternoon.
- Answering "why might I need it" first can end the research before it starts, which is correct when there is no problem and costly when the problem is real but not yet visible.
- Running the example and the restart costs an install; for a technology you are only trying to understand in a colleague's pull request, reading may be enough.
- "So never learn a technology unless you need it now." Learn what you like. The method is for research with a decision attached; curiosity has different rules, and a weekend reading about Redis for its own sake is a fine weekend.
- "Not yet means no." Not yet means the requirement that would change the answer is written down. When it arrives, the research is an afternoon, not a weekend, because the five answers already exist.
- "The reviewer was wrong." The reviewer asked a question. The research answered it with evidence; that is the exchange working as intended, and the next review will be sharper on both sides.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe five questions apply to any technology — a database, a library, a protocol, a cloud service, a language feature — because they are about the relationship between a problem and a tool, not about the tool.
- TEAM-SPECIFICA solo learner answers all five from the documentation and a scratch file; on a team that already operates the technology the fastest research is the same five questions asked of the operator, with the scratch example still run because the operator's answers are about their configuration, not yours.
- ILLUSTRATIVEThe cart pull request, the reviewer's concern and the observed restart behaviour are invented to show the shape of the research; the persistence and eviction behaviour described is the general shape of an in-memory store, not a statement about any particular version.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto at /manifesto/delegating: a cache library delegates the storage and the expiry; whether a vanished cart is acceptable stays yours, and no overview page will raise it.