Dispatches¶

Why I Use JetBrains GoLand and PyCharm Over VS Code

VS Code is a remarkable editor. It is fast, extensible, and free, and it has become the default tool for an enormous portion of the developer community. I use it myself for PowerShell, general Markdown, and lightweight editing. But when I sit down to write Go or Python, GoLand and PyCharm are where I do my best work.

This is not a condemnation of VS Code. It is an explanation of why, for language-specific work, purpose-built IDEs make me a more productive and deliberate developer.

Light and Dark Mode Images in GitHub Markdown

GitHub renders Markdown with either a light or dark theme depending on the user's system or GitHub appearance settings. A logo or diagram that looks sharp on a white background can disappear entirely when the same user switches to dark mode. GitHub provides two ways to serve the correct image for each theme without JavaScript.

If you are using MkDocs Material, the same problem has a pure-Markdown solution covered in a companion post: Light and Dark Mode Images in MkDocs Material.

Light and Dark Mode Images in MkDocs Material

The MkDocs Material theme has built-in support for theme-aware images using standard Markdown syntax. No HTML is required.

Toggle the palette icon in the header to see the logo switch between its light and dark variants:

If you are using GitHub Markdown instead, see the companion post: Light and Dark Mode Images in GitHub Markdown.

T.J. Came Running

I was 13 the day I learned that love and safety were different things.

For years afterward, I remembered it as sounds. Not the worst sound, not even the one that should have mattered most, but the smaller ones that came before it, ordinary details preserved in perfect condition.

The bus brakes hissing on the county road.

The car engine idling with that low, stubborn tremor old engines have.

Gravel and clay ticking under the tires.

It was an afternoon like a hundred others, so ordinary it seemed beneath notice. Which is often how disaster arrives: without warning, dressed as routine.

How to Write an Effective GitHub Pull Request Template

Most pull requests arrive with a title, a branch name, and nothing else. The reviewer is left to reverse-engineer the intent from the diff, hunt through linked issues that may or may not exist, and ask follow-up questions before they can even start. That back-and-forth is a tax on everyone's time, and it is almost entirely avoidable.

A pull request template shifts the burden upstream. It prompts contributors at the moment they open a pull request to provide the context that reviewers need: what changed, why it changed, whether it breaks anything, and what issue it resolves. Done well, a template makes the review faster, the history more useful, and the project easier to contribute to.

This post covers what a pull request template is, how to set one up in a GitHub repository, and how to write one that contributors will actually fill out.