Published March 10, 2021 · 4 min read

Throughout the years I have worked on many software projects. In most of them, the code header included the authorʼs name. At first, it seemed natural to have the authorʼs name. In time I realized having a code author in the header is irrelevant, discouraging, and often negative. That realization changed how I think about authorship in teams.

Practically speaking, in many projects, the header file is dictated by the coding style for the company or the project itself. So, we donʼt really have a choice. It is better to stay consistent and follow the same pattern. Nevertheless, I believe the code author in headers should be avoided for new projects. The intent is not to erase accountability, but to move it where it actually lives: in commits, reviews, and ownership docs rather than in brittle header comments.

Code Author

Source Control Already Answers Who

First of all, we really donʼt need author information. In modern teams, itʼs a piece of information thatʼs easily reachable through source control. You can check out who the original author or subsequent authors were, when they made changes, and the intent behind them via change history and review notes. In most cases, nobody even touches the author line even if the whole code is rewritten. When it happens, itʼs even misleading as the original author didnʼt implement the new changes. Therefore, itʼs better to rely on revision control instead of manual updates. That way, authorship lives where it’s accurate and up to date.

In practice, the version control systems can easily show which changes were made by different authors over time, across releases, and alongside discussion threads. This keeps accountability searchable, contextual, and honest.

Collaboration Over Nameplates

Having a code author can discourage another programmer from changing the code. Even subtle nameplates create hesitation during reviews and refactors, especially in high-stakes or legacy modules. Programming is often a team effort. In practice, that means policies, tooling, and social norms should reinforce shared stewardship.

The code shouldnʼt belong to individuals. Everyone in the team should feel OK to change any piece of code regardless of the person who wrote it. This reduces bus factor risk and speeds up incident recovery. If thereʼs no sole author for the code, people would feel better when refactoring the code. Engineers approach changes with fewer social barriers, focusing on correctness and design rather than permissions.

I remember a time when a colleague furiously deleted all the code-author headers I had added. At first it felt awkward. He even sent the review directly to me and I wasn’t sure what to think. But when I read his pull request, it made sense: he had rewritten most of the module, and leaving my name on top felt inaccurate and unfair to him. That experience clarified how nameplates can distort credit, complicate emotions in reviews, and distract from the actual goal. It’s shipping the best version of the code.

When the author implemented the code, it probably solved a business problem. In time, the same code probably has to handle more cases. Requirements accrete, edge cases emerge, and abstractions need pruning. Thus, removing such friction is an important enabler for people who maintain the code. It turns ownership into a team capability, not a personal badge.

In Consequence

I see almost no value in specifying a code author in the header. From a practical point of view, we can have better information from source control. From a collaboration perspective, it can potentially become damaging. For new projects, try to avoid code authors and push back on people who want it. As a practical alternative, keep headers focused on the code itself: purpose, key invariants, and links to design notes or runbooks. Track ownership and review paths in source control and lightweight team docs rather than in brittle nameplates.

• Purpose: a single line stating what the module does.
• Invariants: rules that must always hold true (e.g., “IDs are immutable after creation”).
• Sharp edges: brief guidance like “call close() after init() to release resources.”
• Pointers: links to design docs, ADRs, or runbooks for deeper context.

A simple policy for new projects

1. No author nameplates in headers. 
2. Use source control history for authorship and review context. 
3. Keep a CODEOWNERS (or equivalent) file to route changes. 
4. Prefer small design notes for architectural intent. 
5. Let headers age well by focusing on purpose, invariants, and pointers.

Coding is a team sport. Move credit and accountability to where they stay accurate. It’s history and ownership docs. Let headers teach the next engineer what the code does and how not to break it.