31 Hard‑Earned Lessons After 10,000 Hours of Coding – Insights from a Google Engineer

Matt Rickard works at Google on Kubernetes open‑source projects, maintaining developer tools such as Minikube and Skaffold, and also contributes to Kubeflow’s machine‑learning pipelines.

He has deliberately spent 10,000 hours honing his programming skills, with about 15 years of experience, previously working at a private‑equity firm and spending university years writing code in the library. Earlier projects ranged from a RuneScape botnet to an iPhone Latin‑translation app, a custom configuration language, a network clipper, and deep desktop customizations.

During these 10,000 hours he has worked on distributed systems and many tech stacks, using languages like PHP, JavaScript, Go, Ruby, Python, C#, Java, Swift, and has contributed to front‑end, back‑end, mobile, kernel, cloud, and operations domains, including large open‑source projects like Kubernetes.

The following are his 31 reflections after a decade of coding:

Reading source code often yields answers faster than searching Stack Overflow.

If a problem cannot be found online, it is likely hard or important—or both.

Delete as much code as possible.

Syntactic sugar is usually undesirable.

Simplicity is often the hardest to achieve.

Possess a variety of tools and know when to use each.

Understand the internals of common tools such as Git and Bash.

Build custom tools for repetitive workflows.

Learn from the best resources (e.g., reading the Go standard library).

If code looks ugly, it is probably a serious bug.

When non‑docstring comments are needed, consider refactoring the code.

Not knowing how your program runs in production means you don’t truly understand it; great engineers know their code’s behavior in all environments.

This principle also applies to building pipelines.

Use others’ code cautiously.

Most code found online is poor; writing a better version yourself is often easier.

Never directly depend on a small library you could rewrite, nor on a large library that should be small.

Know when to break rules; sometimes duplication beats abstraction.

Organize code into modules, packages, and functions; mastering API boundaries is an art.

Choose the most effective tools you know; Arch Linux may be the most efficient OS for some developers, but not for everyone.

Avoid cyclomatic complexity.

Avoid deep nesting of conditionals.

Name variables correctly; this is also an art.

Occasionally errors stem from compiler bugs.

Use obscure language features sparingly, but employ them when appropriate.

Technology diffusion is asymmetric; front‑end developers can learn low‑level concepts from engineers, cloud engineers can learn UX from JavaScript developers, but the reverse is less common.

Different types of engineers perceive the world differently.

Some programmers are ten times more efficient than others.

Being a ten‑fold programmer is not correlated (and may be negatively correlated) with being a ten‑fold employee.

Good APIs are easy to use and hard to misuse.

The “configuration heptagon” (a term coined by Matt) ranges from hard‑coded values, environment variables, CLI flags, config files, templated config files, DSLs, generic Bash scripts, back to hard‑coded values; developers should understand each layer.

All abstraction layers are mutable; when faced with a fundamental problem, diving deeper into abstraction can provide answers.