A 36-minute working session on the tools fast teams take for granted: Git's model and workflows, CI/CD pipelines, build & dependency management, and the debugging/profiling kit that turns guessing into measuring.
The gap between slow and fast teams is rarely talent. It's feedback latency: how long from "I changed something" to "I know if it worked." Every tool ahead exists to shrink that loop and make it automatic, repeatable, and shared.
A bug caught at your desk versus in production can cost two orders of magnitude more to fix.
"Works on my machine" — the failure mode every tool here is built to delete.
command to clone, build, test, ship. The number a healthy repo aims for.
A green pipeline that runs in minutes is one people actually wait for. Slow CI gets bypassed.
You change something, build it, test it, and find out if it worked — then go round again. Every tool ahead exists to make one trip around this loop take minutes instead of days.
It's the wait between "I changed the code" and "I know whether I broke anything." A slow team might wait a day for that answer; a fast team gets it in a couple of minutes.
Master those two and the rest of engineering gets dramatically cheaper to do well.
Most Git confusion dissolves the moment you see the data model. Git is not storing diffs — it stores immutable snapshots linked into a graph. Branches and tags are nothing more than sticky notes on that graph. Learn the model and the commands stop feeling like magic.
a1c9f2. Once made, a commit never changes. Each one points back to the commit before it, so your history is a chain (that can branch but never loops back on itself). A branch is just a sticky note pointing at one commit; HEADis the sticky note for "where you are right now."main and feature are branches — labels stuck on a commit. Committing just moves the label forward.HEAD marks your current branch. Branching is cheap because it creates one pointer, not a copy.Commits link to parents; branches (main, feature) and HEAD are just pointers into the graph.
The actual files on disk. Where you edit. Nothing is tracked until you stage and commit it.
An explicit middle layer. git add picks exactly which changes go into the next snapshot — so commits stay focused.
Immutable. Identified by its hash. Carries a parent link, message, author, and timestamp. The unit of history.
Another repository (e.g. origin). push and fetch sync commits between yours and it.
revert, cherry-pick, and bisect powerful instead of theoretical.reflog for weeks — Git is a safety net, once you trust the model.The model is simple; the discipline is the workflow. The goal is to integrate often and in small pieces so merges stay trivial and review stays human-sized. Then a deliberate choice — rebase or merge — decides what your history looks like.
Fork at B, do focused work (f1, f2) in isolation, then merge back at M — main stays releasable the whole time.
git switch -c feature forks a private line off main; nothing you do can break it yet.main keeps moving independently.git rebase main (or merge it in) often, so you find conflicts in ones and twos, not all at once.A merge commit M has two parents — the branches stay visible. True to history, but the graph forks.
Rebase rewrites f1, f2 as f1', f2' atop main — linear history, but new hashes.
main, keep it short-lived, open a PR early.git rebase main (or pull --rebase) to keep your branch currentand tidy while it's still yours.main via a PR — squash or merge-commit, pick one and be consistent.main: required checks + review, no direct pushes. The branch everyone depends on is never broken.A pipeline is the team's definition of "working", written as code and enforced on every change. It removes the two worst words in software — "it should" — and replaces them with a green check or a red X.
One change flows through identical stages. The deploy is gated — a single red stage stops the line.
Like an assembly line with a quality gate — nothing moves to the next station until the current one passes.
CI baked into GitHub. Zero infrastructure, a huge marketplace of reusable actions, and config that lives next to the code (.github/workflows).
Best when your repo is on GitHub and you want green checks in minutes with nothing to operate.
One app for repo, CI, registry, and issues. Powerful pipelines (stages, needs, environments) with runners you can self-host for control over where builds run.
Best when you want an all-in-one DevOps platform, or must self-host the whole thing on-prem.
The veteran — open-source, runs anywhere, ~1,800 plugins, endlessly customizable. The flip side: you operate it — servers, agents, plugin upgrades and all.
Best when you have complex, legacy, or air-gapped pipelines that need total control and custom integrations.
Rule of thumb:already on GitHub/GitLab? Use their native CI — it's the least to run. Reach for Jenkinswhen you need self-hosted flexibility a SaaS runner can't give you.
A build tool turns source into a runnable artifact; a package manager resolves the libraries you depend on. The whole game is reproducibility— your machine, a teammate's, and CI must produce the sameresult, or "works on my machine" comes back to haunt you.
package.json); it then writes a lockfile that records exactly what you got — the precise version of every library, plus a checksum(a fingerprint that proves the downloaded file wasn't tampered with or corrupted).You install A and B; you also get C — a transitive dependency. The lockfile decides exactly which C.
^1.4.2means "1.x, anything ≥ 1.4.2" — you opt into future minors and patches.^1.4.2); the lockfile records reality (1.6.0 + checksum).Hash the inputs; reuse the output if nothing changed. The difference between a 20-second and a 20-minute build.
Track a dependency graph of tasks and recompute just the affected subtree — the heart of fast local loops.
A "sealed" build that uses only the inputs you explicitly listed — never some random tool that happens to be installed on your laptop. That's what makes it come out the same everywhere.
Combine your code and its libraries into a single file to ship, dropping any code nothing actually uses (called tree-shaking). One output, runnable anywhere.
These all do the same core job for the JavaScript world — install your libraries and write a lockfile. They mostly differ in speed and disk usage.
Comes bundled with Node.js, so it's already on every machine.
Pro Zero setup and universal — every tutorial and tool assumes it.
Con Installs are slower and copy each library fresh into every project, eating disk.
Keeps one shared copy of each library and links projects to it instead of duplicating.
Pro Fast installs and big disk savings — shines in large multi-package repos.
Con Its stricter folder layout occasionally trips up older packages that assumed npm's.
The tool that popularised lockfiles and workspaces; modern versions are fast and configurable.
Pro Strong monorepo features and a mature, well-known workflow.
Con Its newer "Plug'n'Play" mode can need extra config and fights some tooling.
How to choose: default to npm— it's already there and fine for most projects. Switch to pnpm when install speed and disk start to hurt in a big repo. Use yarn if your team already has.
A build runner is the tool that actually runs your build steps in order (compile, test, package). The two ends of the spectrum:
A decades-old tool that runs a list of commands you write down, skipping steps whose inputs haven't changed.
Pro Dead simple, installed almost everywhere, perfect as a one-command task runner.
Con No real caching or fingerprinting of inputs — it doesn't scale to large, multi-language builds.
Google's build system: sealed, cached, incremental builds designed for enormous codebases in many languages.
Pro Reproducible by design and very fast on huge repos thanks to shared caching.
Con Steep learning curve and heavy setup — real overkill for a small or single-language project.
How to choose: reach for Make(or your language's built-in tool) for small projects; only adopt Bazel when a giant, multi-language monorepo makes its complexity pay for itself.
Debugging is about correctness — why is it wrong? Profiling is about performance— why is it slow? Both replace opinion with evidence. The senior move isn't knowing the answer; it's knowing how to find it fast.
A flame graph: the widest bars are where time goes. deepCloneeats 45% — that's your one change.
Like a doctor ordering a scan before surgery — you don't cut where it doesn't hurt.
Pause, inspect, step, watch. Conditional and logpoint breakpoints catch the rare case without flooding output.
Binary-search history: mark a good and bad commit and Git walks you to the exact one that broke it — in log₂(n) steps.
In production you can't pause the program with a debugger. Instead you lean on logs (what happened), metrics (numbers over time), and traces (the path a single request took) to figure out what went wrong.
Your editor (or IDE— Integrated Development Environment, an editor with the debugger, search, and tools built in) is where most of this work happens. The three you'll meet most:
A free, lightweight editor from Microsoft with a huge library of add-ons for nearly every language.
Pro Easy to pick up, works well for almost anything, and the extension marketplace is enormous.
Con Loading lots of extensions can slow it down, and its deepest code smarts sometimes trail a full IDE.
A family of full IDEs (IntelliJ, PyCharm, WebStorm…) with deep language understanding built in.
Pro Best-in-class refactoring, navigation, and an excellent debugger out of the box — no setup.
Con Mostly paid, and noticeably heavier on memory and start-up time.
A keyboard-driven editor that runs right in the terminal and is configured entirely by you.
Pro Extremely fast and lightweight, and runs anywhere — even over SSH on a remote server.
Con Steep learning curve, and you assemble your own setup from plugins.
How to choose: VS Code is the safe default for most people. Pick JetBrains when you want maximum built-in power for one main language, and Neovim if you live in the terminal and value raw speed.
main."Make the loop short and the build boring — then speed is just the default."
— the whole talk, compressed
Five quick questions on Git's model, workflows, CI/CD, builds & debugging — instant feedback, no sign-in.
Navigate with ← → or scroll · back to library