He Learned to Code in a Prison Library. Now He Builds the Software That Runs Them.

The library at the correctional facility was open on Tuesday and Thursday afternoons, and on Saturday mornings if the staffing allowed. It held maybe two thousand books, a handful of donated magazines, and a small rotating collection of educational materials that arrived sporadically from a nonprofit in Chicago. Most inmates used the space for legal research or paperback fiction. He used it to teach himself how to build software.

He had time. That was the one thing the system gave him in abundance.

How You End Up With Time You Didn't Ask For

He grew up in a mid-sized city in the South, the kind of place where the gap between the neighborhood you were born into and the opportunities available to you is wide enough to swallow whole futures. He wasn't a bad kid — that framing never quite captures the complexity of how young men in under-resourced communities end up in front of a judge. He made decisions that made sense inside the logic of his circumstances and that looked very different from the outside.

At twenty-two, he was sentenced to eight years. He served six.

The first year was about survival — learning the rhythms of the institution, figuring out who to trust and who to avoid, managing the particular psychological weight of having your days structured entirely by someone else's rules. The second year was when he found the library.

A volunteer who came in twice a month to run a basic computer literacy class had left behind a box of programming manuals when the class funding ran out. They were outdated — some of them significantly — but they were there. He picked one up on a Thursday afternoon mostly because he'd already read everything else on the shelf that interested him.

By Saturday he was back for the others.

Learning Without a Teacher

Self-directed learning in a prison library is nothing like self-directed learning with an internet connection and a laptop. There are no Stack Overflow threads to bail you out when you get stuck. There are no YouTube tutorials, no Discord servers full of helpful strangers, no way to run the code you're writing to see if it actually works. You read. You reason. You work problems out on paper. You develop a kind of theoretical understanding of programming that most working developers never have to build, because they can always just test their way to an answer.

He credits that constraint with making him better at his eventual job than many people who learned conventionally. When you can't run the code, you have to understand it. When you have to understand it, you build a mental model of how systems work that stays with you long after you have access to a keyboard.

He also started paying attention to the software systems around him in ways that most incarcerated people don't — or don't have the vocabulary to articulate. The facility used a case management platform that was, by any reasonable measure, terrible. Information got lost. Scheduling errors created conflicts that resulted in missed court dates and delayed releases. Staff spent hours doing manually what a properly designed system would handle automatically. He noticed all of it. He started writing down observations in a notebook he kept under his bunk.

He was, without knowing it, conducting a user experience audit of a system he was trapped inside.

The Gap Between Release and Relevance

Getting out was supposed to be the hard part. In many ways it was. Reentry is brutal in America — the combination of a felony record, limited job prospects, disrupted relationships, and the psychological aftershock of institutionalization sends a staggering percentage of formerly incarcerated people back through the system within three years.

He had advantages that many people in his position don't. He had a family member willing to let him stay. He had six years of self-education that had given him a skill the market actually wanted, even if he couldn't initially prove it. And he had that notebook.

The first job took eight months to get. He applied to dozens of entry-level developer positions and got rejected — sometimes without a callback, sometimes after a promising interview that ended when the background check came back. He eventually found a small software firm run by a founder who'd done time himself decades earlier and made a point of hiring people the industry reflexively passed over.

He was paid modestly. He worked hard. He got better fast.

Building Something That Shouldn't Have to Exist

The pivot to correctional facility software wasn't planned. It grew out of a conversation at a reentry advocacy event where a nonprofit director was venting about how dysfunctional the technology infrastructure in American prisons had become — outdated platforms, vendor lock-in, systems designed around administrative convenience rather than human outcomes.

He pulled out his phone and showed her the notes he'd been keeping for years. The conversation lasted three hours.

What he eventually built — through a small company he co-founded with a partner who handled the business side while he handled the code — was a case management platform designed with the people inside the system in mind, not just the administrators running it. Interfaces that were legible to people with limited formal education. Scheduling tools that reduced the kind of errors that cost incarcerated people court dates and good-time credits. Communication features that made it easier for families to stay connected during incarceration, because the research on family contact and recidivism is unambiguous.

The system is now in use in facilities across several states. The contracts aren't enormous — correctional technology is not a glamorous market — but they're real, and they're growing.

The Expertise You Can't Fake

What he has that no Ivy League computer science graduate designing correctional software will ever have is fluency. He knows what it feels like to be on the wrong side of a broken system. He knows which failures matter and which ones are merely annoying. He knows the difference between a design flaw that costs a corrections officer ten minutes of paperwork and a design flaw that costs an incarcerated person a year of their life.

That knowledge doesn't come from research. It doesn't come from interviews with formerly incarcerated focus groups, though those matter too. It comes from having lived inside the problem — from having had nothing to do on a Tuesday afternoon except sit in a library and notice everything that was wrong with the world around him.

The system gave him time. He used every minute of it.

Now the system runs on what he built.