Why would Go do this in its documentation?

Before diving in, let me be clear: this is not a critique nor a complaint about Go. It’s simply an observation that led me to an interesting question.

Go is my everyday work tool, and I enjoy using it like no other programming language.

The go command

If there’s one tool every Go developer uses constantly, it’s the go command. It’s the direct gateway to every aspect of a Go project, from module management to environment configuration.

Because of its importance, every serious Go developer should read the go command documentation, or at least be aware of its existence.

This documentation artifact covers all available commands, along with related topics. For example, the go test command and the Build and test caching topic, since they’re closely related. Everything feels intentional, structured, and very Go-like.

Which is exactly why something stood out.

The Observation

If you look carefully at the full list of commands, you’ll notice something unusual, something that feels almost out of place in a language known for its simplicity and consistency:

The alphabetical order breaks at the “work” command.

And it’s not just in the list. As you continue reading through the documentation, the order stays broken, until after the Workspace maintenance topic, where it quietly returns to normal.

That makes the work command the only command sitting in the wrong alphabetical position throughout the entire documentation.

Naturally, you might think: “Maybe the Workspace concept is a prerequisite for understanding the commands that follow?” It’s a reasonable guess. But when you go through those commands with that idea in mind, the connection simply isn’t there. The following commands don’t relate to workspaces, and understanding them doesn’t require any knowledge of the concept.

So the question stands: Why would Go do this?

Any Ideas?

No “official” answer has been found, at least not by me. But here are a few reasonable theories:

• The “late addition” theory: A previous version of the documentation didn’t include the commands that come after work. The alphabetical order was correct back then, and when new commands were added later, no one bothered to reorder everything.
• The “not worth fixing” theory: It’s a known inconsistency, but correcting it would require changes across many interconnected parts of the documentation and other artifacts. Not worth the effort for something that doesn’t affect functionality.
• The “Easter egg” theory: It’s a subtle joke, intentionally left there to “reward” the most observant and detail-oriented developers. Why not?

Final Thoughts

I haven’t done extensive research on this, and I don’t plan to. But I find it to be a genuinely fun discussion topic, especially in a language that prides itself on clarity and consistency.

If you know the “official” answer, or have a theory of your own, drop it in the comments. I’d like to read it.