Working knowledge, in six lines
A reusable format. Take it, fill it, use it again — for yourself, for a handover, for deciding who does what. Nothing in it is specific to one trade.
What this is for
Working knowledge is what you can actually do, as against what you know about. The two are easy to confuse from the inside and impossible to tell apart from a description, because both are written in the same words. I know Postgres. I've worked with sound. I'm comfortable with qualitative research. Every one of those is a claim, and none of them says whether the person has done the thing, when, or how far they got before they stopped.
This format asks for instances instead. It cannot be filled in from a feeling: you either have times you did it, with dates, or you have not got working knowledge yet — you have read about it, watched somebody, or done it once with help. Those are real and useful states, and none of them is this one.
The line that does the work is WHERE IT BREAKS. Anybody can list what they can do. Naming the point where you stop knowing is what makes the rest of it believable, and it is the only part of this document that is hard to write.
The format
THE THING what you can do, as a task somebody could set you
I HAVE DONE the times you actually did it, with when
WHERE IT BREAKS the point at which you stop knowing
WHO I ASK who or what you go to when it breaks
HOW LONG SINCE when you last did it
NOT THIS what people assume follows from this, and does not
A claim above, a refusal below, and four lines between.
What each line is asking
THE THING. Stated as a task somebody could set you, not as a subject. Databases is a subject. Take a slow query and make it fast is a task. If it will not go into the imperative, you know about it rather than know how.
I HAVE DONE. The times you actually did it, with when. Two or three instances, each with a date and enough of the thing to be checkable. Not several projects — the projects. This is the line that cannot be filled in from a feeling, and if it is empty the honest reading is that the rest of the document is about something else.
WHERE IT BREAKS. The point at which you stop knowing. Not a weakness and not a modesty formula — a location. I can get it to run; I cannot tell you why it is slow. I can interview; I cannot code the transcripts. Everybody has one and the people who cannot name theirs are the expensive ones to work with, because the boundary gets discovered by a project rather than by a sentence.
WHO I ASK. Who or what you go to when it breaks. A person, a book, a forum, a model. This is not an admission; it is part of the capability. Knowledge with a known escalation path is worth more than the same knowledge without one, and a blank here usually means the breaking point above is optimistic.
HOW LONG SINCE. When you last did it. Working knowledge decays and the rate is not uniform — some things come back in an hour, some are gone. Say the date and let whoever reads it judge.
NOT THIS. What people assume follows from this and does not. Being able to build a website is assumed to mean you can secure one. Being able to run an interview is assumed to mean you can analyse the transcripts. The assumption is other people's and it is yours to head off, because it is how you end up owning something you cannot do.
A worked one
THE THING Set up a small Linux server and keep it running.
I HAVE DONE Two: the studio's file server, March 2025, still up.
A Pi doing sensor logging, August 2026, ran six weeks.
WHERE IT BREAKS When it is a network problem rather than a machine
problem. I can read a log; I cannot read a packet.
WHO I ASK A friend who does this properly, and the Arch wiki
even when it is not Arch.
HOW LONG SINCE Three weeks.
NOT THIS Not security. People assume that somebody who can set
one up can tell whether it is safe to expose, and I
cannot. Ask somebody else before it faces outward.
Note that this document would not survive somebody asking when? — every line answers it in advance. That is the test: a working-knowledge sheet you can query is one you did not write about yourself.
How to use it
- Write I HAVE DONE first. If it will not come, stop — the rest of the sheet will be about something you have read.
- Write WHERE IT BREAKS second, and make it a location rather than a feeling. If it comes out as I could be better at it, you have not found the edge yet.
- Do not soften it for the reader. The whole value is that it is checkable, and a sheet written to impress is a self-description again, which is the thing this exists to replace.
- Date it, and re-read it in six months. HOW LONG SINCE will have moved without you touching the page.
- 🔴 Never write one of these about somebody else. You can record what you saw them do, with dates, and that is a different document. What they know is theirs to say.
Three ways it fails
It is a subject list. Python, research, sound design. Nothing in it can be checked, nothing can be wrong, and it will be read as a claim about competence because there is nothing else to read it as.
WHERE IT BREAKS is a modesty formula. I'm still learning, I'd want support on the harder bits. This is politeness where a location was asked for, and it leaves the reader to find the boundary the expensive way.
It is written to be read by somebody deciding. As soon as that is the audience, every line drifts upward and the instances get vaguer. If it has to go to somebody who is choosing, write it for yourself first and hand over that version unedited, or do not hand it over at all.
Prayas Abhinav. Licensed CC BY 4.0 — copy it, change it, build on it, including commercially. Say where it came from, and if you changed it.
Take a copy: working-knowledge-format.md. Yours to alter.