Following the detail
Reading a situation from the records up, noticing the one line that does not sit right, and staying with it until it explains itself. It is the part of the job that transfers to almost anything.

Derique Powery Welds
I am Derique Powery Welds, known professionally as Derique Powery. A born Caymanian, and since December 2022 a police constable with the Royal Cayman Islands Police Service.
The job suits me. It rewards patience, a steady manner and an interest in detail most people would call excessive. Much of it comes down to listening properly, writing it down accurately, and noticing when the account in front of me and the record that has to support it are not quite the same thing.
Away from it, I build things. I design systems, teach myself whatever the next one needs, and keep going until it works. Nobody asked me to and nobody pays me for it, which is exactly why it is any good.
It started as irritation. I kept watching sound processes fall apart at the precise moment somebody needed to prove what happened, and software that was technically fine and still miserable to use. So I started building alternatives to find out whether I could do better. Turns out I could.
There is no brief, no client and no deadline except the one I set, which means I can throw away a version that almost works. I read, take the courses, build it, break it and start again. It is a hobby in roughly the way running a marathon is a hobby.
Scope is where I collect the results. The systems, the thinking behind them, and notes on what makes a process still hold up a year later. All of it personal, built on my own time, and kept separate from my policing role.
Not how the manual says, and not how anyone would describe it in a meeting. The real version, workarounds included. Most of the answer is already in the room before anyone opens a laptop.
Which step depends on one person remembering. What gets written down twice and agreed once. What nobody could prove a year from now. Those questions are the specification.
Every feature past the necessary ones is something to maintain, explain and eventually remove. The version that does the job beats the version that demonstrates well.
Put it in front of the people who would use it every day and watch where they hesitate. Hesitation is a design fault, not a training problem.
Reading a situation from the records up, noticing the one line that does not sit right, and staying with it until it explains itself. It is the part of the job that transfers to almost anything.
Mapping how work really moves, then removing the steps that exist only because they always have.
Calm, plain spoken, hard to rattle.
Usable without a manual.
Designing software around the job it has to support. What it captures, how it behaves at each step, and what it deliberately leaves out.
Turning something messy into a page another person can act on without needing three follow-up questions.
Every feature past the necessary ones is something to maintain, explain and eventually remove. Leaving things out is the hardest part of the job.
If someone needs training to complete a form correctly, the form is wrong, not the person. Hesitation is a design fault.
Who, when and what changed are captured automatically. Nothing important should rest on a person remembering to write it down.
Someone unfamiliar should open a record a year later and understand what happened without asking anyone. That is the whole test.
Write-ups of systems I have built and the problems that made me build them. Project names are withheld.
The first write-ups are in progress.
All work →Short pieces on records, process, and the design of software people actually have to work in.
All notes →I am not selling anything. If something here was useful, or you want to argue with me about why so much software is technically fine and still miserable to use, I read everything that comes in.