Practical writing on learning to ship in a new stack

Error wrapping, sentinel errors, and the invisible anti-patterns that follow Python and Java developers into their first Go codebase.

Static rubrics miss half the signal. The concepts a developer already understands should change what feedback they receive on every new PR.

One developer's switch from Python to TypeScript, graded at each step. The concept gaps that persisted longest were not the ones you would expect.

Recognition is not production. A developer who can follow a tutorial is not a developer who can write idiomatic code in a new stack under deadline.

Experienced developers switch stacks differently than junior ones. The conceptual baggage is heavier but the diagnostic ability is sharper. Here is how that plays out in practice.

After grading 500 Go PRs from developers coming from other stacks, a clear picture emerged. Concurrency misconceptions persist much longer than syntax errors.

Code review finds bugs. PR grading for learning finds the concept behind the bug and tracks whether it recurs. The goal is different, so the output needs to be different.

The error is never about the goroutine itself. It is about ownership, lifecycle, and the mental model of what owns what in a concurrent program.

Experienced developers do not need to be taught from zero. The design challenge is detecting which specific concepts are missing and sequencing lessons to fill only those gaps.

The documentation plateau is real. Most developers hit it at the same point: three to five weeks in, when recognition outpaces production fluency.

Why we built HackQuest, what the first version does, and what we are still figuring out. The short version: most developer training does not touch real code.