Documenting, the third verb everyone skips

When people ask how I work, I answer with three verbs: I code, I test, I document. The first two surprise nobody. The third usually raises a smile, as if it were the chore you save for Friday afternoon.

The verb nobody claims

Nobody puts “documentation” forward on a CV. You put frameworks there, architectures, sometimes tests. Documentation shows up at best as the last bullet of a role, squeezed between two things that sell better. And yet it is often the deliverable I have been thanked for the most.

That is no accident: it is the only part of the work whose value only shows after you leave.

Remote: what I don't write down doesn't exist

I have spent six years working with teams I never meet: Texas, France, Cameroon. Six hours of difference on one side, one hour on the other. In that setup, a question asked at the end of the day gets its answer tomorrow, and a piece of information written nowhere is a piece of information lost.

It changes how you write. You stop writing for yourself, telling yourself you'll reread it later: you write for someone who will read it with no way to ask a follow-up. It stopped being a constraint long ago: it became my default way of working.

Ten applications, one set of docs

At OBOSSO I looked after a portfolio of five to ten of the group's applications at once: internal tools, SaaS products, brochure sites. Simultaneous demands for new features, corrective maintenance and stabilisation of what already existed, often in the same week, on different projects.

Memory does not hold up in that context. I wrote the technical documentation and the operating procedures for that portfolio. The team adopted them, and they are still in use. It is one of the contributions I am proudest of, and one of those that fits on a single line of a CV.

Documentation is the part of the job nobody brags about, and the one that decides whether your successor curses your name.

An admin guide is worth as much as the code

On Résidence Kesla I delivered a booking application with its back-office: units, stays, payments, gallery, newsletter. The owner is not a developer. Without a companion document he would have called me back for every unit to add. And the day I stop answering, the tool dies.

So I wrote an admin guide and delivered it alongside the product. It was not in the original brief. It is nonetheless what separates a site that was delivered from a site that gets used.

Three rules I follow

Document the decision, not the code. The code already says how things work. What it will never say is why this path was chosen over another, and what was ruled out along the way. That is what whoever picks up the project is missing.

Write for the newcomer, not for the person who already knows. Documentation only its author can read is not documentation, it is a memo. The real test: can someone discovering the project carry out the operation without asking a single question?

Ship the documentation with the code, not after it. Pushed to the end of the project, it never gets written: the budget is spent, the team has moved on. It is part of the deliverable or it does not exist.

What it costs, what it returns

Documenting takes time, and that time does not show in a demo. Which is exactly why it is the first thing cut when the schedule tightens.

But a team that has to reconstruct a procedure for every new joiner pays that time ten times over. A client who cannot administer their tool stops using it. And a developer who does not document becomes, without meaning to, a single point of failure, which is flattering right up until the day they want to move on to something else.