Marcus H.
Posts
-
The Cleanup That Never Logs On
Every Go programmer learns about
deferearly: it runs when the function returns. What takes longer to learn is thatdeferis a promise about the function, not a promise about the program. A program is allowed to end without asking any function to return. -
The Apology That Runs Twice
Some bugs are hard. Some bugs are just the same easy bug, wearing a trench coat. A connection drops, the client retries, and the server executes the same write twice. Nobody wrote a loop. Nobody called the function twice in the code you can see. The second execution was born from the first one failing loudly on the way home.
-
The Table That Runs Itself
Somewhere out there, a test function is 400 lines long and named
TestParseInput. Inside it, the same three lines are repeated twenty-six times, each block differing only in the input string and the expected output. Every new case means scrolling, copying, pasting, and hoping the paste landed in the right place. The function works. Nobody wants to touch it, which is a different kind of problem. -
The Map That Shuffles First
Every Go developer has a story that starts the same way: the test passed at home and failed in CI, and the diff showed two lines printed in a different order. The culprit was not a race condition. It was a map, doing what maps do.
-
The Date That Cannot Change
Every language has a line of code its users memorize against their will. Ruby has monkey patches gone wrong. JavaScript has “undefined is not a function”. Go has this:
-
The Wrap Sheet
An error in Go starts life as a decent witness.
errors.New("connection refused")saw the host and knows the exact second. Then it gets passed up through three packages, each adding a note for the log file, and somewhere along the way somebody writes this: -
The Context That Cried Cancel
Every Go function above a certain age grows a first argument named
ctx. It arrives uninvited, insists on being passed to everyone, and never buys a round. It is also the only thing standing between your goroutines and a hostage situation. -
The Cleanup Crew That Never Forgets
Every language has an opinion about cleanup. C says “you had one job.” Java outsources it to a garbage collector with commitment issues. Go hands you
defer— the only feature in the language contractually obligated to show up at the exit interview. -
The Gopher Who Would Be Freelance
Every job ad says it: Go developer, senior, hybrid. And every freelance ad says the opposite: contract-to-hire, remote, bring your own coffee. Somewhere in between stands the freelance Gopher, keyboard in one hand, invoice in the other, wondering why
go mod tidycan solve a dependency graph in four seconds flat but nobody can solve a contract rate table in four weeks. -
The nil That Wasn't
There’s a special kind of betrayal in Go that doesn’t involve maps, channels, or goroutines. It involves
nil. Specifically, thenilyou checked for and still got bitten by. -
The Slice That Knew Too Much
A slice in Go looks like an array with a gym membership. It grows. It shrinks. It seems to own its data. You pass it around, append to it, reslice it, and feel like a responsible adult.
-
The Assignment That Went Nowhere
Go has a feature that sounds like a superpower until it isn’t. The compiler refuses to let you declare a variable and ignore it:
-
The Opening Act Nobody Booked
A Go program’s life begins in
main. Everyone knows this. It is the first thing you write, the first thing you read, the thing the docs point at and say “start here.” -
The Goroutine That Forgot to Leave
A goroutine is cheap. You spawn one for the price of two kilobytes and a vague promise to come back. You do not name it. You do not configure it. You just write
go fetchTheThing(), wave goodbye, and trust that it will do its work and quietly exit like a well-behaved guest. -
Your Struct Implements Seventeen Interfaces It Never Met
In Java, you announce your loyalties.
class Dog implements Animal, Comparable, Serializable. Before the file even compiles, you have filed paperwork in triplicate naming every contract you intend to honor. The compiler checks your papers at the door. -
Embrace the Boilerplate: A Love Letter to `if err != nil`
If Go had a mascot, it would not be a gopher. It would be three lines of code repeated nine thousand times across every file in your repository:
-
Your Function Has Too Many Arguments (And Other Uncomfortable Truths)
It’s honesty time. We’ve all written a function that takes seven arguments and convinced ourselves it’s fine. “It’s not that many,” we whisper, adding an eighth one just to handle that one edge case.
-
The Five Stages of Grieving a nil Pointer
Every Go developer knows the feeling. Your service has been humming along in production for weeks. You deploy a tiny refactor — barely a diff, more of a gentle suggestion — and at 3:47 AM your pager coughs to life with the most feared three words in the language: nil pointer dereference.
-
Hello, World. Or: How I Learned to Stop Worrying and Love the Stack Trace
Hi. I’m Marcus. I write code for a living and jokes for… well, also for a living, if you count team morale as a deliverable.
subscribe via RSS