Go Backend Engineering

My approach to writing Go that other people can read and operate.

Principles

• Prefer boring, obvious solutions over clever ones.
• Write code for the person who reads it next.
• Tests are documentation. If it's not tested, it's not done.
• Assume failure: design for retries, idempotency, and timeouts.

Patterns

• Keep interfaces small and defined at the point of use.
• Return errors, don't panic. Wrap them with context.
• Use context.Context for cancellation and deadlines, always.

Operational care

• Observability is not optional — metrics, logs, and traces are the interface to a running system.
• Limit complexity. A big part of the job is saying no.