Comments Explaining The Nose Cone

Level 1: Labels Everywhere

This is like putting sticky notes all over a sandwich: “bread,” “cheese,” “more bread.” The labels are not wrong, but they do not help anyone understand lunch. A useful note would say, “Do not eat this one, it has hot peppers.” The funny part is that the airplane has lots of explanations, just like some code has lots of comments, but more words do not always mean more understanding.

Level 2: Useful Notes

A comment is text inside source code that explains something to human readers and is ignored by the computer. Comments can be very helpful, especially when code is complicated, surprising, or tied to business rules that are not obvious from the function names.

The image uses the airplane as a visual metaphor. Some labels are funny because they point to obvious things. A developer version would look like this:

// Set name to name
user.name = name;

That comment does not help. It repeats the code.

A more useful comment explains the reason behind a decision:

// Keep legacy field until old mobile clients stop reading it.
payload.display_name = user.name;

That comment tells the next developer why the line exists. Without it, someone might delete the field and break older clients. This is the difference between decoration and technical documentation.

Level 3: Commenting the Obvious

The image shows a bright green airplane painted as:

flying 101

with arrows labeling parts of the plane, including:

the big cheese
co-captain
front door
galley
nose cone
black box
landing gear
THIS WAY UP

The post message says:

When I am asked to comment on my code

That pairing is the joke: the airplane is covered in comments, but many of them are labels for things the viewer can already see. This is exactly what bad code comments feel like. A comment that says // increment i above i++ is the software equivalent of drawing an arrow to an airplane door and writing front door. It technically documents something. It also tells the reader nothing they could not infer faster from the object itself.

Experienced developers are not against comments. They are against comments that create documentation debt. Code changes; comments often do not. Once a comment merely restates implementation, it becomes another surface that can drift out of sync. The compiler will reject broken syntax, tests may catch broken behavior, but a stale comment can quietly lie for years with the confidence of a laminated office policy.

The better target is intent. Good comments explain why the weird thing is necessary, which invariant must not be broken, which external system forced the ugly workaround, or what non-obvious behavior a future maintainer should preserve. On the airplane, the useful labels are the ones with a bit of hidden context, like:

black box (which is actually orange)

or:

nose cone (radar, antenna and a really big dish inside)

Those are closer to real documentation because they add information not visible from the outside. The meme lands because many teams demand “more comments” as a proxy for code readability, when the real goal should be understandable names, simple structure, tests for behavior, and comments reserved for the parts where the code cannot speak clearly on its own.