Commenting For Lost Context

Level 1: Notes To Your Future Self

This is funny because it is like writing sticky notes while building something because you know you might forget what each part is for. The programmer was praised for helpful notes in the code, but the reason was not noble and serious: he kept losing his train of thought when the screen moved. The notes saved him, and later they saved everyone else too.

Level 2: Why Comments Help

A code comment is text inside a program that the computer ignores but humans can read. Developers use comments to explain tricky logic, important assumptions, warnings, or reasons behind a decision.

An 80x24 terminal means the screen showed 80 characters per line and 24 lines at a time. That is not much space. If the code moved upward while typing or scrolling, the programmer could lose sight of the earlier lines that explained what was happening.

In modern programming, this still matters even with better tools. Code can be long, complex, and full of hidden decisions. A comment can answer questions like:

• Why is this special case here?
• What bug does this guard against?
• Why does this use a strange format?
• What must not be changed without checking another system?

The funny part is that the developer in the anecdote did not comment only because of ideal engineering discipline. He commented because he knew he would forget what he was doing. That makes the joke relatable: everyone has lost their place in code, even without an ancient terminal helping them forget.

Level 3: Scrollback Driven Documentation

The screenshot is a Hacker News comment under:

Ask YC: how do you work for 8 hours straight?

The comment begins:

Back in the days of 80x24 terminals, one of the original authors of a popular unix game was often complimented on how well his code was commented.

Then it gives the reason:

He said that he had to do that because he always smoked pot when he coded and would lose his train of thought when the screen scrolled.

That is a beautifully unromantic origin story for good CodeComments. The usual mythology says well-commented code comes from discipline, professionalism, and respect for future maintainers. This anecdote says: sometimes documentation exists because the author knew his working memory was unreliable and the terminal had all the scrollback generosity of a brick.

The 80x24 detail matters. Old terminals often displayed 80 columns and 24 lines, so code context disappeared quickly as soon as the screen moved. Modern editors give us split panes, jump-to-definition, search, minimaps, blame annotations, language servers, and effectively infinite scrollback. Earlier environments made context physically scarce. If a function's assumptions scrolled away, you either remembered them, navigated back, or left yourself a breadcrumb.

That is why this lands as UnixHistory, TerminalLife, and CodeQuality all at once. Good comments are not just moral virtue; they are a response to cognitive constraints. A useful comment stores intent near the code so the next reader does not need to reconstruct it from memory, archaeology, or vibes. In that sense, the joke is accidentally profound: the best programmers document not because they have perfect focus, but because they know they do not.

There is also a maintenance lesson hiding under the drug joke. Comments age badly when they merely repeat the code, but they age well when they explain why the code exists, what invariant it protects, or what non-obvious constraint forced the shape. The comment author in the screenshot is praising that kind of survival note. The reason may be chaotic, but the result is exactly what maintainers want: local context before the screen, the sprint, or the human brain loses the plot.