What a repository proves, and what it stopped proving

The thing that lost its signal

A personal project used to carry information. It said: this person can hold a piece of work in their head for weeks, make a hundred decisions, and finish. The artefact was evidence of the process because there was no other way to get the artefact.

That inference is broken. A complete, tidy, well-tested application is a weekend, and every hiring manager knows it. Uploading one is no longer a claim about you; it is a claim about a tool that everybody has.

This is not a complaint. It is a change in which artefacts carry information, and there are several that now carry more than they used to.

Commit history beats the final state

The artefact is cheap. The record of getting there is not, and most people do not think to fake it.

A log that shows an approach taken, pushed, run against real data, found wanting and reverted tells a reader something a clean tree cannot. So does a commit message that says why, not what. So does a branch that was abandoned with a note explaining the dead end.

git log --oneline --graph --since=6.months

If that output is a straight line of forty green commits each adding a complete feature, a reader learns nothing except that you squashed. Consider not squashing on personal work, and writing the why in the body.

Somebody else’s gate is the strongest signal

One merged pull request to a project you do not control outranks an entire solo repository, for a mechanical reason: a maintainer who owes you nothing read it and said yes.

The same logic ranks the rest:

• A bug report with a minimal reproduction: the version numbers, the smallest failing input, the expected and actual behaviour. Maintainers can tell instantly whether somebody did the reduction work, and reducing a bug is the diagnosis skill in miniature.
• A code review you left on a stranger’s change, if it is public. This is visible judgment, which is the scarce thing.
• A documentation fix for the thing that confused you. Small, wanted, and it proves you read the source.
• A post-mortem of something of yours that broke. Timeline, cause, what you changed. Almost nobody writes these voluntarily and they read as unmistakably real.

Maintenance beats launch

A project with users has an issue tracker, and an issue tracker is a record of you handling other people’s problems over time. Three years of small commits to one thing that people actually use says more than nine finished-and-abandoned repositories.

If your project has no users, say what you learned from it instead of implying adoption. A README that says “I built this to understand how consistent hashing behaves when a node leaves; here is what surprised me” is honest and informative. A README that implies a user base you do not have is checkable and will be checked.

Write the thing down

A short write-up of one real problem (what you expected, what happened, how you found it, what you would do differently) is worth more than most projects, and it takes an afternoon.

It works because it is the one format that cannot be outsourced without becoming obviously generic. Specificity is the signal: the actual query plan, the actual 3am graph, the actual wrong assumption. Free hosting exists everywhere: GitHub Pages, Codeberg Pages, a plain markdown file in a repository. You do not need a domain and you do not need a design.

The part that is unfair, said plainly

Everything above rewards discretionary time, and discretionary time is distributed by luck. Somebody working two jobs or caring for a family cannot produce a contribution history, and treating one as a requirement filters on circumstance while feeling like meritocracy.

If you are hiring: a portfolio is evidence when present and not evidence when absent. Build a loop that works for a candidate with nothing public, because many of the strongest people have nothing public: their work belongs to an employer.

It is also getting harder to contribute. Maintainers of popular projects are receiving large volumes of low-quality generated pull requests and reports, and several have responded by tightening what they accept from newcomers. So the advice “go contribute to open source” is more expensive than it was two years ago, and you should expect a slower, more sceptical reception than the guides written in 2019 describe.

The limitation

This lesson is an argument about signalling, not a study. Nobody has measured what hiring managers actually weigh now, the answer differs enormously between a two-person startup and a bank, and plenty of screening is still done by keyword filters that read none of this. Take it as a reasoned account of where information survives, and ask the specific people you want to work for what they look at.