$ guide to success

A decoder ring for the curious, the new, and the vibers leveling up.

The shortest path between "I just learned what a PR is" and "I get taken seriously in any room of devs." No fluff. No condescension. Just the stuff nobody tells you out loud.

$ what's in here

$ git, the actual mental model

Git is not a backup tool. It's a graph of snapshots, where every snapshot points to its parent. A branch is just a movable label on a snapshot. A commit is a snapshot with a message. A merge joins two histories. A rebase rewrites your history to look like it grew on top of someone else's. Once you see the graph, every git command makes sense.

full chapter dropping soon the day-to-day commands · when to rebase vs merge · how to read git log --graph · undoing things without panic

$ the unspoken PR etiquette

Small PRs win. Draft mode is your friend. "nit:" means "I won't block on this." "LGTM" means "looks good to me — ship it." Reviewing a 2,000-line PR makes everyone hate you. Reviewing a 50-line PR makes everyone like you. The pattern is: split the work into reviewable chunks, write a description that explains why, and respond to every comment even if it's just "👍".

full chapter dropping soon how to write PR descriptions reviewers actually read · the comment vocabulary · when to push back · merge strategies

$ the stack devs assume you know

Most production systems run on a small set of "boring" tech that nobody hypes anymore. Postgres for the database, Redis for the queue or cache, Docker for "it works on my machine" being a real argument, and a CI pipeline that runs on every push. The choice between Node, Python, and Go is mostly cultural. The choice between Postgres and "something else" is rarely correct.

full chapter dropping soon the actual prod stack · why "boring tech" wins · what every dev assumes is on every server · the four things you must understand

$ phrases that get you taken seriously

"Ship it" — done, deployed, working. "Blocked on X" — I can't move until X is unblocked. "Yak shaving" — the unrelated work you have to do before you can do the work. "Bikeshedding" — arguing about trivial details to avoid the hard ones. "Tech debt" — shortcuts you took that you'll pay for later. Knowing these isn't enough — knowing when to use them is.

full glossary dropping soon 50+ phrases · usage notes · what they actually mean vs what people say they mean · when to never use them

$ workflows in the wild

Trunk-based development means everyone commits to main behind feature flags. GitFlow means long-lived branches that nobody touches the same week. Most teams pick one, then drift halfway between. Standups exist to surface blockers, not to perform productivity. Retros exist to fix the system, not the people. Code freeze means "stop merging, we're shipping."

full chapter dropping soon the four common workflows · async-first communication · how to run a useful standup · the meeting hygiene playbook

$ the small tells (signal vs noise)

Tier 8 devs don't need to tell you they're tier 8. Their commit messages explain why. Their PRs include tests. Their READMEs answer the questions you didn't ask yet. Their code does one thing per function. The signal is in the small stuff that nobody assigned them to do — and the noise is in the big things they did to look impressive.

full chapter dropping soon what reviewers notice · what hiring managers notice · the tells that travel · how to build them into your habit