Track
Go developer roadmap
The first 3 stages are the same for every Go developer,
starting at go mod init. After that the path branches by
the kind of work you want to do.
Choose a track
Backend and APIs
viewingHTTP and gRPC services people depend on.
CLI and developer tools
3 stagesSingle binaries other engineers install.
Cloud-native and platform
plannedControllers, operators, and the control plane.
AI agents in Go
plannedTool dispatch, retrieval, memory, evals.
Backend and APIs
7 stages · 44 topicsThe most common reason teams reach for Go: request handling, a database, and an operational story that holds up at 3am. Ends with a service another engineer can run and extend.
0 of 44 topics checked
The first three stages are shared, so ticking them here counts on every track.
Before stage 01
None of this is Go, and all of it shows up in your first week on a Go team.
Git and code review
Branches, rebase, small commits, and reading a diff — you will learn Go through pull requests.
Terminal and Linux basics
Shell navigation, environment variables, processes, signals, file permissions, and SSH.
HTTP and JSON
Methods, status codes, headers, caching, and what a request actually looks like on the wire.
SQL and data modeling
Joins, indexes, transactions, and normalization — most Go services are database services.
The path
Topic — click to check off Done Distance travelled
Language Foundations
2–4 weeks
Read and write plain Go without looking up syntax on every line.
Build A CLI that reads a cart as JSON on stdin and prints an itemized order total with tax and shipping.
Move on when You can explain the difference between a nil slice and an empty slice, and why a value receiver cannot mutate its struct.
Idiomatic Go
3–5 weeks
Write code a Go reviewer recognizes as Go — not translated Java or Python.
Build A catalog package with an interface-based repository, an in-memory fake, and table-driven tests covering the domain rules.
Move on when You introduce an interface only when there is a second implementation or a test double — never speculatively.
Concurrency and Context
4–6 weeks
Write concurrent code that is correct under -race, not merely faster.
Build A supplier price fetcher that queries N suppliers concurrently with a per-request deadline, cancels the rest once enough quotes arrive, and leaks no goroutines.
Move on when You can spot a goroutine leak in review and explain why context beats a shared done flag.
Standard Library and Tooling
3–4 weeks
Solve most problems with the standard library before reaching for a dependency.
Build A JSON order API on net/http and database/sql with graceful shutdown, request timeouts, and zero third-party dependencies.
Move on when Your first instinct for a new problem is to check the standard library docs, not a package registry.
Building Real Services
6–8 weeks
Ship a service that another engineer can run, extend, and operate.
Build An order service with HTTP and gRPC surfaces, Postgres with migrations, a background worker for confirmation emails, and integration tests.
Move on when Your service degrades predictably when a dependency is slow or down instead of falling over.
Production and Performance
ongoing
Run it, measure it, and make it faster only with evidence.
Build Instrument the order service with traces and metrics, then cut p99 latency or allocations by 30% with before/after profiles to prove it.
Move on when You never change code for performance without a benchmark or profile in hand.
Design and Architecture
ongoing
Make design decisions you can defend — including the patterns you rejected.
Build Refactor a tangled package behind one clear interface boundary using the patterns in this catalog, and write the short design doc that justifies the split.
Move on when You can explain why a pattern was the wrong fit as clearly as why another one was right.
After this the road is just build, measure, review — on repeat.
- 01
Language Foundations
Read and write plain Go without looking up syntax on every line.
2–4 weeks 0/6Learn
Build this
A CLI that reads a cart as JSON on stdin and prints an itemized order total with tax and shipping.
Move on when
You can explain the difference between a nil slice and an empty slice, and why a value receiver cannot mutate its struct.
- 02
Idiomatic Go
Write code a Go reviewer recognizes as Go — not translated Java or Python.
3–5 weeks 0/6Learn
Build this
A catalog package with an interface-based repository, an in-memory fake, and table-driven tests covering the domain rules.
Move on when
You introduce an interface only when there is a second implementation or a test double — never speculatively.
- 03
Concurrency and Context
Write concurrent code that is correct under -race, not merely faster.
4–6 weeks 0/6Learn
Build this
A supplier price fetcher that queries N suppliers concurrently with a per-request deadline, cancels the rest once enough quotes arrive, and leaks no goroutines.
Move on when
You can spot a goroutine leak in review and explain why context beats a shared done flag.
- 04
Standard Library and Tooling
Solve most problems with the standard library before reaching for a dependency.
3–4 weeks 0/6Learn
Build this
A JSON order API on net/http and database/sql with graceful shutdown, request timeouts, and zero third-party dependencies.
Move on when
Your first instinct for a new problem is to check the standard library docs, not a package registry.
- 05
Building Real Services
Ship a service that another engineer can run, extend, and operate.
6–8 weeks 0/7Learn
Build this
An order service with HTTP and gRPC surfaces, Postgres with migrations, a background worker for confirmation emails, and integration tests.
Move on when
Your service degrades predictably when a dependency is slow or down instead of falling over.
- 06
Production and Performance
Run it, measure it, and make it faster only with evidence.
ongoing 0/7Learn
Build this
Instrument the order service with traces and metrics, then cut p99 latency or allocations by 30% with before/after profiles to prove it.
Move on when
You never change code for performance without a benchmark or profile in hand.
- 07
Design and Architecture
Make design decisions you can defend — including the patterns you rejected.
ongoing 0/6Learn
Build this
Refactor a tangled package behind one clear interface boundary using the patterns in this catalog, and write the short design doc that justifies the split.
Move on when
You can explain why a pattern was the wrong fit as clearly as why another one was right.
Patterns for this track
Patterns are not a stage you complete — they are vocabulary you pick up once you have code worth reorganizing. These are the ones this track runs into most.
Adapter
Wrap an incompatible API behind the interface your application already expects so the rest of the code stays unchanged.
Decorator
Add behavior around an object dynamically by wrapping it with small focused layers that share the same interface.
Proxy
Control access to another object by standing in front of it to add caching, authorization, rate limiting, or lazy loading.
Chain of Responsibility
Build validation and request-processing pipelines with small handlers composed through interfaces.
Facade
Provide one simplified entry point over several collaborating subsystems so callers can trigger a workflow without knowing every step.
Strategy
Encapsulate interchangeable algorithms behind one interface so callers can swap behavior without branching on concrete rules.
Resources worth your time
A short list, mostly official. Finish these before buying a course.
A Tour of Go
The official interactive introduction. Finish it before anything else.
Effective Go
How Go is meant to be written, straight from the Go team.
Go Code Review Comments
The checklist Go reviewers actually apply to your pull requests.
Go by Example
Short annotated programs for nearly every language feature.
The Go Blog
Canonical deep dives on slices, errors, context, generics, and the GC.
Standard Library Reference
Bookmark it. Reading std source is part of learning the language.
Learn Go with Tests
Learn the language test-first — the fastest route to testing discipline.
Go Proverbs
Rob Pike's one-liners that explain most Go design arguments.