Where you are. You have a shipped artifact with honest numbers in it. This lesson is about the prose that carries those numbers to people who will never open your repository.
One in the morning
Two hours in. The symptom is precise: your node publishes, the other node subscribes, both processes report themselves perfectly healthy, and nothing arrives.
You search the exact phrase in quotes. Nine results. The official documentation page, which does not mention this case. Four forum questions with no answers, the most recent from 2023. An issue closed as stale by a bot. Two pages that restate the documentation at greater length and were obviously generated by something that had never run the code.
You solve it yourself at ten past four, by reading source.
Now hold the interesting fact. The page you needed did not exist, you are currently one of very few people on earth who has just spent three hours discovering what is on it, and you could write it tomorrow in forty minutes.
That is the entire method. Everything after this is formatting.
The idea in one paragraph
Writing travels when it closes a gap somebody is standing in front of right now, not when it is well written. The unit that travels is a specific problem, a specific number, and the conditions under which that number holds. Robotics is unusually good territory for this, because the published record is nearly all successes: every reported success rate was produced by the party being evaluated, on hardware they chose, with a task definition they wrote, and the results that came out badly were mostly never published at all. You have the missing half. The discipline this course has drilled since orientation, which is that a number without a denominator and a condition set is not a number, is exactly what turns a short honest post into the most useful page on its subject.
The gap test
Wider than the screen; scroll it sideways.
Before writing anything, run one test. Search for the piece you are about to write, as a reader would, using the words a reader in trouble would actually type.
If it already exists and is good, do not write it. A tutorial that duplicates a good tutorial gets no readers and costs you a weekend, and there is no version of “but mine explains it better” that survives contact with search rankings.
If what comes back is the shape from the scene above, an unanswered question, a stale issue, generated filler, then the gap is real and you are holding the thing that fills it.
What robotics is missing, specifically
The gap is not random. It has a shape, and the shape is systematic.
Success rates get published; failure rates get mentioned in a hallway. Conditions get omitted, because a number without conditions looks stronger. Latency gets quoted at its best. Negative results, meaning the approach you tried for three weeks that did not work, go in a drawer, since nobody feels that a failure is publishable. And the cost of a thing, in hours and in money and in how many times you had to rebuild the fixture, is almost never written down at all.
Every one of those is a page somebody is currently searching for.
Lead with the result
A reader arriving from a search has a problem and roughly fifteen seconds of patience. A reader arriving from a link a peer sent has slightly more. Neither of them wants your journey.
Wider than the screen; scroll it sideways.
So invert the natural order. The result first, in the title and the first two sentences. Then the conditions under which it holds. Then the method, compactly. Then the story, which is where the debugging narrative and the three wrong theories go, and which is genuinely worth reading once somebody has decided to care. Then what you would do next.
The chronological order is the one everybody writes, because it is the order the work happened in. It buries the finding under two thousand words of setup, and the reader who needed the finding left at word two hundred.
Every number carries three things
Wider than the screen; scroll it sideways.
A number in your prose needs a denominator, a condition set, and where possible a comparison. Miss any one and the reader cannot use it.
“It works” is not a claim. “82%” is a claim you cannot check. “82% over fifty trials” is checkable but unplaceable. “41 of 50 on three objects under fixed overhead light, against 22 of 50 for the baseline on the same set” is something a stranger can act on, argue with, or try to reproduce, which is the point.
The parts people leave out are the two least flattering: what stayed the same, and what you did not measure. Both belong in.
The negative result is your differentiator
The piece nobody else will write is the one about the approach that did not work.
It is also the easiest one to write, because you already have the material and there is no pressure to be impressive. Structure it as: what I expected, what I did, what actually happened with numbers, what I now think the cause was, and how confident I am in that diagnosis. The last clause matters. “I believe it was the timestamp alignment, but I did not isolate it cleanly” is a stronger sentence than a confident wrong diagnosis, and a reader can tell the difference.
Negative results travel further than positive ones in a field this young, because the positive results are marketing and everybody knows it.
Short, several, and then one
Length is not what makes something worth reading, and long pieces are read less. A tight eight hundred words solving one specific problem outperforms a five thousand word survey almost every time.
Which of your pieces will travel is not predictable, by you or by anyone. The reasonable strategy is therefore volume with a floor on quality: publish four to six real pieces over a few months, each closing one gap, and expect one of them to carry disproportionately. You will usually be wrong about which one, and the one that carries is often the smallest.
Write it while it still hurts
The notebook you kept during the capstone is the raw material, and it decays fast. Within a week you remember that the timestamps were wrong. Within a month you no longer remember what you tried first, why it seemed reasonable, or what the wrong output actually looked like, and those three details are the entire difference between a post that reads as lived and one that reads as summarised.
There is a second reason to write, and it holds even if nobody reads a word. Writing the explanation is how you find out whether you understand your own system. The sentence you cannot finish is a component you do not own, and it is far better to discover that at your desk than three levels into somebody’s follow-up question.
Check yourself
1. What is the gap test, and what does a failed test tell you to do?
Search for the piece you are about to write, using the words a reader in trouble would type. If a good version already exists, do not write it: a duplicate tutorial earns no readers and costs a weekend, and “mine explains it better” does not survive contact with search results. If what comes back is unanswered questions, stale issues and generated filler, the gap is real. The test is about the reader’s situation rather than your interest in the topic.
2. Why is robotics unusually good ground for someone willing to publish honest numbers?
Because the published record is a biased sample. Every reported success rate was produced by the party being evaluated, on hardware they chose, against a task they defined, with the freedom to publish selectively. Failure rates, omitted conditions, real latencies, and approaches that were tried and abandoned mostly go unpublished. That leaves a large amount of genuinely useful writing unwritten, and you hold exactly that material, because your capstone produced it and you did not discard it.
3. Rewrite “the model performed well after fine-tuning” so that a stranger can use it.
Give it a denominator, a condition set, and a comparison: for example, 65% success over twenty trials on transparent lids against 25% before fine-tuning, with camera position and lighting held fixed, and no change on opaque objects, which stayed at 85%. That version can be checked, argued with, or reproduced. The original can only be believed or ignored, and an experienced reader ignores it, the same way you would ignore a benchmark number with no configuration attached.
4. Why does the chronological order of a technical piece lose readers, and what replaces it?
Because it puts the finding last, and a reader who arrived from a search with a live problem has about fifteen seconds of patience. Chronology is the order the work happened in, not the order a reader needs it. Replace it with result first, then the conditions under which it holds, then the method compactly, then the story with the wrong theories in it, then what you would do next. The story is worth reading; it is just not worth reading first.
5. What is the loudest tell that a technical post was smoothed into generated fluency?
The complete absence of a moment where the author was confidently wrong. Real debugging accounts contain a paragraph explaining what the writer was sure of and why, immediately before it turned out to be something else. The supporting tells are no specific decision ever named, risks that any project would share, uniform hedging, and adjectives doing work that numbers should do. Readers detect the pattern in seconds and stop, because the pattern predicts an absence of first-hand experience.
6. Why publish four to six pieces rather than carefully engineering one?
Because which piece travels is not predictable by the author, and the one that carries is often the smallest. The workable strategy is volume with a quality floor: several real pieces, each closing one gap, published over a few months, with the expectation that one lands disproportionately. Engineering a single breakout instead concentrates all the effort on an outcome you do not control, and it typically produces a survey, which is the format that travels least.
Do this
Two sittings, about four hours total, and it should end with something published.
1. Mine the notebook. Go through the log you kept during the capstone and list every moment where you were stuck for more than an hour. For each one, write the search phrase you used at the time. That list of phrases is your candidate pieces.
2. Run the gap test on each. Search the phrase. Mark each candidate as covered, thin, or absent. Anything covered by something good is dead; do not argue with it.
3. Pick the most specific survivor and write eight hundred words in the inverted order: result, conditions, method, story, next. Put the number in the title. Set a timer, because a first draft that takes a whole day will not be repeated and repetition is the actual strategy.
4. Audit every number. Go through the draft and, for each figure, check that a denominator and a condition set are attached and that you have said what stayed the same. Add one sentence naming something you did not measure.
5. Run the tell check. Find the paragraph where you were confidently wrong. If there is not one, you have summarised rather than reported, and the fix is in the notebook rather than in the prose.
6. Publish it, and write down the date. Then start the next one before you find out how the first performed, because waiting for feedback is how a cadence turns into a single post.
What you can now do
You can tell the difference between a piece that duplicates the record and one that closes a gap in it, name the specific shape of what robotics does not publish, invert a technical piece so the finding arrives before the story, attach a denominator and a condition set to every number you put in prose, write the negative result that nobody else will write, and recognise in your own draft the tells that make an experienced reader stop reading.