Writing on xdg.me

Hacking the job interview

xdg@xdg.me (David Golden) — Mon, 09 Feb 2026 00:00:00 +0000

The best thing you can do in an interview is make the interviewer picture you already doing the job.

Once that image takes hold – you on their team, solving their problems, relieving their stress – they start to feel relief, maybe only subconsciously, at the idea of you being hired. And when it comes time to make a decision, loss aversion kicks in. It’s psychologically harder to say “no” to someone you’ve already imagined saying “yes” to.

AI conversations

xdg@xdg.me (David Golden) — Sun, 08 Dec 2024 00:00:00 +0000

I wrote this in December 2024 but it sat as a draft until I rediscovered it in early 2026. I’ve backdated it as a record of where my head was at the time.

I’ve always considered myself a great refiner of other people’s ideas. Tell me your idea and I can instantly tell you what works and what doesn’t and give you lots of suggestions for refinement.

But give me a blank sheet of paper and a general topic and I’ll struggle to get traction. Even when I do, I feel the burden. It’s not fun.

Unmarshal text with Go reflection

xdg@xdg.me (David Golden) — Sun, 02 Jan 2022 00:00:00 +0000

As much as I like Go, I sometimes really miss dynamically-typed languages. I find Go tedious when I have to parse some arbitrary text format or lines from stdin, which would be trivial with Python, Ruby or Perl.

Parsing JSON with Go is easy – just unmarshal it right into a struct. I wanted to unmarshal a line of text the same way, so I wrote a library, strum, to do exactly that.

How to mentor software engineers

xdg@xdg.me (David Golden) — Mon, 20 Dec 2021 00:00:00 +0000

A friend and fellow staff+ engineer posted a question to a peer group Slack:

Anyone have suggestions on how best to mentor software engineers?

At the time, I said a few things about radical candor and actionable feedback, but the question stuck with me. I mentor people, but I’ve never thought formally about what it is or how I do it. Like a lot of soft skills, we’re rarely taught how to mentor – most of us are left to figure it out on our own.

Use a career ladder for growth conversations

xdg@xdg.me (David Golden) — Wed, 29 Sep 2021 00:00:00 +0000

A “growth conversation” is a talk with your manager about how to get promoted. It might not be explained that way, but don’t be fooled.

I’ve written this for non-managers. But if you’re a manager, use this technique and your team will love you for it!

I’ve found that a lot of these talks wind up muddy and subjective. It’s easy to come out of them without actionable steps or with generic advice.

Best career advice: ask for feedback

xdg@xdg.me (David Golden) — Mon, 13 Sep 2021 00:00:00 +0000

The best career advice I ever heard was this:

“No one cares more about your career than you!”

If you wait for your manager or your company’s review process to give you feedback, it’s almost certainly going to come later than you’d like. There’s a good chance that you’ll have missed out on opportunities to improve and the review you eventually get will bake in the bad habits you could have fixed if only you’d known.

How to think about equity compensation

xdg@xdg.me (David Golden) — Thu, 29 Jul 2021 00:00:00 +0000

Many tech jobs pay a portion of employee compensation in the form of equity. This is a great deal for companies:

They get to defer paying you
They get to pay you without burning cash
If you quit before you vest, they don’t have to pay you
If you have a lot of unvested equity, you’re less likely to leave

How good a deal is this for employees, really?

Imagine that your employer only paid cash and said they wanted to pay part of your salary – still in cash! – in pieces over the next several years. You’d only want that deal if they were going to pay you more in the future than they would otherwise pay today to make up for the risk that you might never see the money.

Why I write

xdg@xdg.me (David Golden) — Sat, 29 May 2021 00:00:00 +0000

I was out for a walk. And as I often do on walks, I used the time to think about an article I was working on. Suddenly, though, I was struck with a deeper question:

Why do I write?

I realized there are two parts to the answer to this question. And the more I thought about it, the more I realized how important both were to keeping me motivated.

A better way to learn a new codebase

xdg@xdg.me (David Golden) — Sat, 15 May 2021 00:00:00 +0000

Some people work on the same codebase for years, developing deep mastery. The rest of us have to start from scratch as we switch projects or jobs. Being able to learn a new codebase quickly and effectively is a programmer superpower.

Most guides I’ve seen on learning a codebase boil down to “read and ask questions”. For a small codebase, that can work. But as the codebase grows, that isn’t enough.

80/20 is half-ass when value is logistic

xdg@xdg.me (David Golden) — Tue, 04 May 2021 00:00:00 +0000

80/20 is a great heuristic for power laws and asymptotic progress, but be careful when value accrues logistically.

My friend swyx wrote an article, “80/20 is the new half-ass”, that pushed my buttons. But on a second read, I realized that nothing he said is wrong. It bothered me because it dunked on one of my favorite tools without advice for using it well.

To me, the 80/20 heuristic is a mental model about diminishing marginal returns. 80/20 thinking works best in two cases:

How I broke the MongoDB Go driver ecosystem

xdg@xdg.me (David Golden) — Tue, 30 Mar 2021 00:00:00 +0000

I unintentionally broke the MongoDB Go driver ecosystem one March weekend in 2021. Dependency management systems are hard.

In late 2018, I moved all my Go libraries from github.com/xdg to github.com/xdg-go to keep my Go work separate from other projects/languages.

This seemed painless, because GitHub automatically redirects repositories after a rename. For example, in a project that was importing github.com/xdg/stringprep, a dependency resolver would try to pull from that repository, and GitHub would transparently redirect that to github.com/xdg-go/stringprep.

Interviewing engineers, part 2

xdg@xdg.me (David Golden) — Fri, 19 Mar 2021 00:00:00 +0000

Welcome back! In part 1 of this article, I said:

I think tech industry hiring is pretty broken. If you feel the same and are looking for inspiration, I’ll tell you what I did differently when I had the chance.

Part 1 covered my philosophy about interviewing and I described changes I made to the hiring process:

Using promotion criteria to guide hiring criteria
Having the hiring manager do the first interview
Saving synchronous time for interaction, not coding
Using take-home exercises as part of the initial screen

I also gave examples for effective non-technical interviewing.

Interviewing engineers

xdg@xdg.me (David Golden) — Thu, 18 Mar 2021 00:00:00 +0000

I think tech industry hiring is pretty broken. If you feel the same and are looking for inspiration, I’ll tell you what I did differently when I was a hiring manager at MongoDB.

Caveat: I don’t claim this only way to interview. It’s just something I tried that I think is better than the typical way it’s done. Take my ideas if you’d like, but do your own experiments and see what works for you.

Leading without managing

xdg@xdg.me (David Golden) — Fri, 12 Feb 2021 00:00:00 +0000

What does it mean to lead when you don’t have coercive power to get your way?

Good managers are often good leaders. But managers don’t have to be good leaders to get their way because they have authority to make decisions unilaterally.

What if you don’t have that authority?

Perhaps you’re an individual contributor. Perhaps you are a manager, but want to show leadership when you’re the junior person in the room. In both cases, you lack the authority that comes from coercive power.

A survey of git best practices

xdg@xdg.me (David Golden) — Tue, 01 Sep 2020 00:00:00 +0000

How do you know if something you recommend is a best practice?

At work, new college grads are starting and I volunteered to give a talk on git best practices. I have strong views, but I looked for articles I could use to give a more complete picture.

It was weirdly addicting. After looking at three or four, I kept going through page after page of Google search results.

I looked for two things. How often was a topic mentioned? And did people agree or disagree?

What xkcd tells us about dependencies and NIH syndrome

xdg@xdg.me (David Golden) — Tue, 18 Aug 2020 00:00:00 +0000

NIH. Not invented here. In software development, this means a preference for in-house code. People have strong feelings about this, but let’s try to ground ourselves in some actual analysis. When does it make sense?

A third-party dependency is code you don’t have to write, but it introduces risk. Some people say “if you can replace a dependency with an afternoon of coding, do it!”.

Is that right? Let’s ask xkcd.

Book review: The Coding Career Handbook

xdg@xdg.me (David Golden) — Tue, 11 Aug 2020 00:00:00 +0000

The Coding Career Handbook by Shawn Wang (@swyx)

tl;dr

The Coding Career Handbook is chock full of nuggets for aspiring senior engineers and beyond. It lightly covers a vast number of essential, mostly non-technical topics that senior+ engineers should know, and gives extensive hyperlinks for each.

Many of the career tactics offered are variations of Shawn’s learn in public theme for building a professional network via writing and social media.

Rewriting Go with AST transformation

xdg@xdg.me (David Golden) — Sat, 23 Nov 2019 00:00:00 +0000

At work, my team decided to switch our codebase from pkg/errors to Go 1.13’s native error wrapping. We used to wrap our errors like this:

var errBadStuff := errors.New("something happened")
...
err := errors.Wrapf(errBadStuff, "some context '%s'", label)

Starting in 1.13, we can wrap errors directly using fmt.Errorf and the %w code:

err := fmt.Errorf("some context '%s': %w", label, errBadStuff)

Rather than change hundreds of wrappings across tens of thousands of lines by hand or with kludgy string replacement, I wrote a program to rewrite our source files using Go’s AST instead.

Go as glue: JSON + XML + PNG = PDF

xdg@xdg.me (David Golden) — Wed, 13 Nov 2019 00:00:00 +0000

tl;dr: How I used Go to mash up card game data from the Internet into a printable PDF of card proxies.

Earlier this year, a friend introduced me to the Lord of the Rings card game. Like Magic the Gathering, you construct your own deck from a pool of cards. Unlike Magic, it’s cooperative (or solo): you compete against a thematic scenario rather than against other players.

Ideally, you need access to a big pool of cards to customize your hero deck to the specific challenges of each scenario. Unfortunately, many of the early expansion sets are out of print and ridiculously expensive on Ebay.

Schrödinger's Monad: A Maybe type experiment for Go

xdg@xdg.me (David Golden) — Tue, 23 Oct 2018 00:00:00 +0000

In the mid 1930’s, physicist Erwin Schrödinger published a thought experiment to critique the seeming-paradoxes in the new science of quantum mechanics.

The “Schrödinger’s Cat” problem imagines a cat locked in a box with a device that might or might not release a poison gas depending on a quantum effect, such as radioactive decay of an atom. According to quantum theory, the atom exists in a “superposition” of decayed and non-decayed states simultaneously until “observed”. Therefore, the cat must be both alive and dead until the box is opened, thus “collapsing” the superposition of possibilities to a single outcome.

Flaming people versus flaming code

xdg@xdg.me (David Golden) — Wed, 14 Mar 2018 00:00:00 +0000

I think many open-source communities suffer from two related flaws:

We think flaming someone’s code is an acceptable or useful form of technical critique
We react to flames against our code as personal attacks

When both occur, we have problems.

Statements like “this code is stupid” or “this code is insane” aren’t constructive because they don’t contain any useful information about what was seen as a problem and because most people reasonably take pride in their work and don’t like hearing it disparaged.

No more dirty reads with MongoDB

xdg@xdg.me (David Golden) — Mon, 07 Mar 2016 10:00:03 +0000

If you’re reading this blog, it’s a good bet that sometime in your life you’ve had a computer freeze or crash on you. You know that crashes happen.

If it’s your laptop, you restart and hope for the best. When it’s your database, things are a bit more complicated.

Historically, a database lived on a single machine. Writes are considered “committed” when they are written to a journal file and flushed to disk. Until then, they are “dirty”. If the database crashes, only the committed changes are recovered from disk.

Perl 5 and Perl 6 are mortal enemies

xdg@xdg.me (David Golden) — Thu, 07 Jan 2016 11:31:18 +0000

[Note: in 2019, Perl 6 renamed itself Raku.]

Did you grow up with one or more siblings? Are you a parent with two or more kids? Then you know that siblings often fight. A lot.

Perl 6 is described as Perl 5’s little sister

That metaphor fits. They share parentage. The languages are similar in philosophy. One is more mature, the other less so. Their communities overlap.

But like siblings, they are rivals. Like an only child confronted with a new baby in the house, they now compete for attention from their shared community. They compete for scarce resources to grow – in the form of volunteers who will contribute time and treasure.

Book Review: The Go Programming Language

xdg@xdg.me (David Golden) — Mon, 04 Jan 2016 21:50:07 +0000

[Disclaimer: I was provided with a free review copy by the publisher.]

tl;dr

If you’re looking to buy a comprehensive text on Go, “The Go Programming Language” is an excellent choice. But with so many free e-book introductions to Go, do you really need it? Maybe, but maybe not.

Overview

The authors “assume that you have programmed in one or more other languages” and thus “won’t spell out everything as if for a total beginner”. Yet the book weighs in at a hefty 380 pages (over 100 pages more than my venerable 1988 K&R 2nd edition).

Tip jars and open source

xdg@xdg.me (David Golden) — Mon, 03 Mar 2014 22:09:45 +0000

[This essay was originally titled "Why I finally joined Gittip and why you should, too", but with the demise of Gittip (later Gratipay), I've retitled and amended it to make a more general point.]

I was a Gittip skeptic.

Heck, I still am. But I signed up anyway and I’ll tell you why.

But first, I want to talk about money and altruism. Most people contribute to open source for free. They don’t do it for money. They do it for fun or self-satisfaction.