If you spend hours a day in your editor, your setup stops being a cosmetic preference and starts becoming part of how you think. Mine has evolved into a very opinionated VS Code environment tuned for the work I do most often: Go, Python, PowerShell, Ansible, Terraform, Markdown, YAML, JSON, and a steady stream of GitHub-driven automation.
This piece includes themes of violence, childhood trauma, and emotional neglect. Please proceed with care.
Reflection
Some houses hold warmth; the one I grew up in held its breath.
Tension lived in the walls, and even the floorboards carried the weight of something left unsaid.
This is a song about the kind of trauma that weaves itself into the grain of a life, and the impossible weight of an apology that arrives decades too late.
Lyrics
HOLE IN THE FLOOR
I showed up in the summer of '76 Born into a house of broken bricks You mortared the cracks with the debt and the kids And a ledger of things that the memory forbids Four little children learning to read the air Knowing when to vanish and when not to stare By the time I packed up my bags to leave There was nothing left in that house to believe
I remember that Tuesday, the air was thick The sound of your footsteps making me sick I stepped to the center and I drew the line Seventeen years and I’m out of time I stood like a stone while the room turned to ice Done asking permission, done taking advice I’m lucky I left when the moment was right Before the fire in my blood finally caught light
I was miles away, I was safe and gone While you were in the hallway carrying on With a heavy hate and a .38 A bitter man snapping beneath the weight Now there’s a piece of lead in the cold and gloom Lodged in the floorboards of my upstairs room
The youngest was standing there, frozen and small The others were listening through cracks in the wall I didn’t find out 'til the smoke had cleared That you finally became what we always feared Mama changed her name and she walked out the door But you stayed the same man you had been before
Repeat Chorus
I sat by your bed when the breathing got thin Watching the light slowly leave your skin You looked at me through the morphine haze And apologized for the rest of your days You said, “Son, I’m sorry for hurting your Ma” But a hole in the floor was all that I saw
Oh, there’s a piece of lead in the cold and gloom Lodged in the floorboards of my upstairs room Yeah, a hole in the floor Was all that I saw
I am a songwriter and a musician, but I am not the voice meant to inhabit these verses.
I've used AI to bridge the gap for the concept demos, crafted to serve as blueprints that capture the genre, tone, and weary soul I hear for each song.
They exist as an invitation, offered in the hope that these lyrics will eventually reach the hands of an artist and storyteller who can bring them fully into the light.
Until then, they remain as they were born: quiet reflections on the grit and grace found just north of the county line.
A pull request template improves the quality of proposed changes, but it only helps after someone has already made it to the solution stage. GitHub issue forms solve the earlier problem: they shape the information you collect when someone reports a bug, asks for an enhancement, or suggests a documentation fix. In that sense, they're the natural companion to a pull request template, and for many repositories they do even more to reduce maintainer back-and-forth.
Pull request templates help contributors explain a proposed change.
Issue template help contributors explain a problem, an idea, or a gap before any code has been written.
That distinction matters, because most maintainer time is lost much earlier in the process: missing reproduction steps, missing environment details, vague enhancement requests, and documentation issues with no concrete suggestion.
This piece includes themes of loss, grief, and hard mercy. Please proceed with care.
Reflection
Published in tandem with What the Red Clay Keeps, which reflects on these tangled roots of affection and grief that defined my Southern experience.
Lyrics
SOME THINGS STAY SMALL
I counted heads in the morning light Steam rising thick in the January cold The runt was pinned to the cedar slats Too thin to stand, too weak to hold Mama whispered, "Let him be" But Daddy just stared at the ground I learned right then, in the quiet air A breaking heart doesn’t make a sound
It don't pay to love what you can't save But you do it anyway You want to see 'em run the fields But the red clay wants 'em to stay And it’s a long, dark walk to the edge of the woods To give 'em the peace they crave Yeah, he wouldn't grow God, I know Some things stay small Then they go
Daddy weighed him with heavy eyes Same way he’d done a hundred times Said, "He ain’t gonna make the winter, son" Like reading a sentence for a crime The .22 rifle by the kitchen screen Morning quiet, sharp and clean There’s a kind of mercy that looks like a sin When you’re the one standing in between
Repeat Chorus
He was shivering where the others slept warm Reaching for a teat in the middle of a storm If mercy’s got a human face It ain't in the prayer, it's in the hard embrace
I still see him when the night runs thin When the radiator hums and the walls close in I don’t dream of the blood or the broken things Just a little life waiting on the peace it brings I don’t curse my daddy’s hands I don't hold a grudge for the debt he paid It takes a whole lot of love to kill something So it doesn't have to be afraid
It don't pay to love what you can't save But you do it anyway I still see him run the fields In a dream from a different day But he wouldn't grow Now I know Some things stay small And that’s okay Yeah, they go Yeah, they go
I am a songwriter and a musician, but I am not the voice meant to inhabit these verses.
I've used AI to bridge the gap for the concept demos, crafted to serve as blueprints that capture the genre, tone, and weary soul I hear for each song.
They exist as an invitation, offered in the hope that these lyrics will eventually reach the hands of an artist and storyteller who can bring them fully into the light.
Until then, they remain as they were born: quiet reflections on the grit and grace found just north of the county line.
This piece includes themes of loss, grief, and hard mercy. Please proceed with care.
There are places in the South where mercy rots before it ripens. You can feel it in the sag of a porch beam, in the black water holding still beneath the cypress knees, in the red clay that clings to a boot like a hand unwilling to let go. Even in winter the land keeps its fever. Spanish moss hangs from the trees like old church lace gone gray with grief. Cicadas are long dead by January, but their husks still cling to fence posts and bark, the empty shape of a thing that sang itself raw and left its shell behind.
This is the country of crumbling sheds and cedar slats silvered by weather, where small lives are counted at daybreak and losses are folded into chores before breakfast. The air smells of ping, wet straw, heat, stale prayer, and the sour sweetness of something too long confined. Somewhere a mother lowers her voice because the truth sounds uglier spoken aloud. Somewhere a father studies the ground as though judgment might be written in the red clay. Before anything happens, you already know everybody here has inherited something they did not choose and will not escape.
A repository security policy is one of those documents that people often add because GitHub expects it, not because they have thought through what it needs to do. That is how you end up with policies that say little more than "email us if you find a problem" or, worse, tell researchers to open a public issue for a vulnerability report. An effective security policy is not a box-checking exercise. It is an operational document: it tells security researchers how to contact you safely, tells users which versions you still support, and tells everyone what kind of response process they can reasonably expect.
This post walks through how to write a security policy that is actually useful on GitHub: what sections it needs, how specific to be, which mistakes to avoid, and a practical SECURITY.md template you can adapt for your own repositories. The goal is not just to help you publish the file, but to help you publish one that will still read as clear, credible, and operational when someone actually needs it.
Useful beyond GitHub, too!
Although this post focuses on GitHub, most of the guidance applies equally well to GitLab and other source hosting platforms. The platform-specific details, such as where the policy is surfaced and how private vulnerability reporting works, may differ, but the core job of a security policy stays the same: define a private reporting path, set expectations, and make support boundaries clear.
A GitHub repository does not become a healthy community just because the code is useful. The moment other people begin opening issues, commenting on pull requests, or submitting patches, you have a social space to maintain as well as a technical one. A code of conduct is the document that defines what kind of community you are trying to build, what behavior is expected, and what happens when those expectations are ignored.
The best code of conduct files are not there for optics. They are there to reduce ambiguity. They tell contributors what respectful participation looks like, give maintainers a clear basis for moderation, and provide a reporting path when something goes wrong. Done well, they make a project safer, more predictable, and easier to contribute to.
This piece includes themes of depression, hopelessness, and suicide. Please proceed with care.
In Loving Memory
Written to process the death of my nephew. Rest in Peace, Phin.
Phineas Harvey Alexander Tillman June 4, 2001–January 11, 2026
Lyrics
I'M JUST A RIVER
I’ve been carving through the valley Long before they built this town I’ve watched these waters rise And families settle down I’ve carried off the mountains Every stone of joy and pain I catch the ones who fall to me And hold them year to year
The bridge has swallowed prayers From quiet hums to raw-boned cries I’ve seen the tired at midnight Walking beneath a heavy sky The moon hid behind the clouds Too faint to see you leave You fractured something in my depths Searching only for relief
I’m just a river, I don’t choose What the tired and hurting do But I’d trade every drop of me If love could’ve pulled you through The hard days spoke like the Gospel And you believed every word they said I’d have carried you a thousand miles But I couldn’t quiet your head
Now your name moves upstream In your mother’s cry In the silence your father swallows When the house has lost its light Your family passes by the rail Holding breath inside their chests Learning how to miss you Without rehearsing how you left
Repeat Chorus
Standing on the bridge Believing rest is letting go A current only moves one way But a heart can still turn home
I am a songwriter and a musician, but I am not the voice meant to inhabit these verses.
I've used AI to bridge the gap for the concept demos, crafted to serve as blueprints that capture the genre, tone, and weary soul I hear for each song.
They exist as an invitation, offered in the hope that these lyrics will eventually reach the hands of an artist and storyteller who can bring them fully into the light.
Until then, they remain as they were born: quiet reflections on the grit and grace found just north of the county line.
golangci-lint is one of the highest-leverage tools in the Go ecosystem because it turns a loose collection of static analysis tools into a single, fast, repeatable code-quality gate. Used well, it catches real bugs, reduces review noise, and helps maintainers keep a project consistent without turning style preferences into endless pull request commentary.
For many Go teams, the mistake is not adopting golangci-lint. The mistake is adopting it without a strategy. Enabling too many linters at once, tolerating unexplained //nolint comments, or treating the default output as a substitute for judgment quickly turns a useful signal into background noise.
This post walks through how golangci-lint works, how I think about configuring it for a real project, and how to run it in ways that are practical for both day-to-day development and long-term open source maintenance.
Much of what I know about golangci-lint was learned the unglamorous way: maintaining Go-based open source projects where lint output has to hold up in front of contributors, CI systems, release processes, and real users. That includes work across HashiCorp Terraform providers, HashiCorp Packer plugins, and Go SDKs.
That context matters because this is not an abstract "here are the docs" walkthrough. It is an opinionated maintainer's view of what actually keeps linting useful in a long-lived Go codebase.
There is a kind of performance that no longer feels like performance because you have been doing it so long that it has settled into your bones.
Each morning arrives with its own familiar ritual: the steady voice, the practiced calm, the expression that says, "I belong here." After enough years, it becomes automatic. People hear you speak, ask for your judgment, trust what you have to say. Your name appears on work that matters.
From the outside, it can look like certainty.
But beneath all of that, there can still be a quieter voice saying something else entirely:
"Today will be the day they figure out I don't belong here after all."
It has a name, of course: Imposter Syndrome. That old habit of treating your own record like disputed evidence.
That voice is stubborn. It doesn't yield easily to experience, praise, or proof. It survives accomplishment with an almost insulting ease. It can sit in the same room with a long career, meaningful work, and the respect of other people, and remain completely unimpressed.
I've spent most of my professional life inside the orbit of very large institutions, places whose names carry their own kind of weather.
On paper, my record isn't especially mysterious. I've held serious roles. I've contributed to products and open source projects people actually use. I've written extensive designs and documentation that helped people do their jobs. I've even written a book. I've earned certifications and accreditations, sometimes less out of ambition than out of a private need to quiet the voice that keeps insisting I've not done enough. I've stood in rooms where others came to listen, and I've spoken at more technology conferences than I could name without stopping to count, somehow managing not to waste their time.
