About the Practitioner
I’m Shane DuBois, a technologist and practitioner working at the edge where infrastructure stops being abstract and starts becoming personal.
My background runs from the copper pair to the cloud: telecommunications, higher education IT, local infrastructure, community technology, and the ordinary human reality of helping people when the system in front of them has stopped making sense. I’m as interested in a 5ESS switch and a good local loop as I am in AI workflows, support systems, and what happens when automation starts pretending to be judgment.
I care about open systems, honest tools, and keeping humans in the loop.
A lot of my work comes down to one question: what kind of world is a system teaching people they live in? Is it legible? Accountable? Durable? Does it preserve uncertainty when uncertainty is real? Does it support the person at the edge of it, or punish them for being confused?
I write as a practitioner because that is what I am. My knowledge comes from building, breaking, maintaining, observing, documenting, caregiving, troubleshooting, and staying close to real systems long enough to see what they do to people. I am not interested in technology as theater. I am interested in technology as a lived structure.
I believe care can be architectural. I believe infrastructure is never neutral. And I believe some of the most important technical knowledge still lives with the people closest to the floor.
Why I Publish Practitioner Reports
I publish practitioner reports because not every real thing begins as a paper.
Some ideas start as repeated observations. Some start as field notes. Some start as a pattern you keep seeing in production, in support work, in governance, in human behavior, or in your own life with systems. You may not yet have a formal study. You may not yet have a clean dataset, a polished framework, or the institutional language to make the idea feel safe. But the thing is still real enough to name.
That is where practitioner reports live.
I use them to put a stake in the ground, to make a careful public object out of something that would otherwise stay trapped in conversation, and to give other practitioners something they can point to, question, test, disagree with, or build from. A practitioner's report is not a claim to final truth. It is a claim that something has been seen clearly enough to be worth sharing.
I also publish them because I believe practitioner knowledge matters.
A lot of what gets called innovation is really just abstraction with better marketing. The people who work closest to actual systems often see the failure modes first. They see what breaks, what gets hidden, what gets normalized, what gets sold too early, and what kind of workaround becomes necessary when the official story stops matching reality. That knowledge deserves a form.
For me, practitioner reports are that form.
They let me write honestly about what I know, what I suspect, what I can support, and what I cannot yet prove. They let me keep the limits visible. They let me publish without pretending certainty I do not have. And they let me build a public trail that others can follow.
That matters to me.
I do not want my work to sound more final than it is. I want it to be useful, legible, and real. I want someone else sitting in a support chair, a machine room, a help desk, a telecom closet, a classroom, or a call center to read it and think: yes, I have seen that too.