Archive
1290 posts · Page 15 of 108. ← Blog
You can build software for years treating the operating system as a black box — and then one day a production mystery (a service that's slow for no reason, a memory crash, a concurrency heisenbug, a server that won't scale) has an answer that lives entirely below your framework. OS knowledge is what lets you see down there. This closing post shows how everything in the series connects, through the system-call boundary and the diagnostic power it gives you.
You can build software for years treating the OS as a black box — then a production mystery has an answer that lives entirely below your framework. OS knowledge is what lets you see down there. How everything connects, through the system-call boundary and the diagnostic power it gives.
Knowing the algorithms is maybe 20% of doing machine learning. The other 80% is the workflow around them: framing the problem, preparing the data, iterating honestly, and getting a model into production where it keeps working. This closing post assembles the series into the end-to-end process real ML follows — and names the places where projects actually fail, which are almost never the algorithm.
Algorithms are ~20% of ML; the other 80% is the workflow — framing the problem, preparing data, iterating honestly, and keeping a model working in production where it decays (concept drift). Why classical ML isn't obsolete, and why these foundations are universal to deep learning and LLMs.
A snapshot-per-commit model sounds like it should balloon a repository to enormous size. It doesn't — a project with a decade of history often clones smaller than a single day's build artifacts. The trick is packfiles: Git periodically takes its loose objects, deltas the similar ones against each other, and compresses the result. This is where "Git stores snapshots" and "Git repositories are tiny" stop seeming contradictory.
A snapshot-per-commit model sounds like it should balloon a repository, yet a decade of history often clones smaller than a day's build artifacts. Packfiles are the trick: Git deltas similar objects against each other and compresses the result — a storage layer under the snapshot model, invisible in daily use.
A launch feels like a finish line — the day you finally ship to the world — but it's actually a starting line, and the most dangerous myth in go-to-market is that a big launch equals success. Most durable companies weren't made by a viral launch day; they were made by the unglamorous work of getting a few early customers to genuinely succeed, then carefully expanding from there. Adoption is a curve you climb, not a switch you flip, and the hardest part of that curve is the gap that kills more products than any competitor.
A launch feels like a finish line, but it's actually a starting line — and the most dangerous myth in go-to-market is that a big launch equals success. Adoption is a curve you climb, not a switch you flip, and the hardest part of that curve is the chasm that kills more products than any competitor.
The difference between a server that handles a hundred connections and one that handles a hundred thousand on the same hardware usually comes down to one choice: how it does I/O. Blocking, non-blocking, and asynchronous I/O aren't interchangeable styles — they're fundamentally different models with different scaling limits, and understanding them explains async/await, event loops, and why the network stack works the way it does.
The difference between a server handling a hundred connections and one handling a hundred thousand usually comes down to one choice: how it does I/O. Blocking, non-blocking, and asynchronous I/O are fundamentally different models with different scaling limits.
Kubernetes's deepest idea isn't its built-in objects — it's that the reconciliation model is extensible. You can teach Kubernetes new concepts and automate operating them, which is what operators do. This closing post covers that extension model, the realities of running Kubernetes in production, and the honest verdict on when its power is worth its complexity.
Kubernetes's deepest idea isn't its built-in objects — it's that the reconciliation model is extensible. You can teach Kubernetes new concepts and automate operating them, which is what operators do. Plus the realities of running it in production, and when it's worth the complexity.
The hardest part of platform engineering isn't the technology — it's building a platform people actually adopt, and knowing whether it's working. This closing post covers treating the platform as a product, measuring it with DORA metrics and adoption, structuring the team, and the failure modes that sink platforms. Getting these right is what turns platform engineering from a project into a lasting capability.
The hardest part of platform engineering isn't the technology — it's building a platform people actually adopt, and knowing whether it's working. Treat the platform as a product, measure it with DORA metrics and adoption, and avoid the failure modes that sink platforms.
As a program grows past one file, you need a way to organize it — to group related code, control what's public, and pull in libraries. Rust's module system does this with a clear hierarchy and privacy-by-default, and understanding crates, modules, and paths is what lets your projects scale beyond a single main.rs. This closes Module 2.
As a program grows past one file, you need a way to organize it — to group related code, control what's public, and pull in libraries. Rust's module system does this with a clear hierarchy and privacy-by-default.
Most data in the world is unlabeled, and labeling it is expensive — so some of the most useful machine learning finds structure in data with no answer key at all. Unsupervised learning groups similar things, compresses high-dimensional data, and flags the anomalies, all without being told what "right" looks like. This post covers the main unsupervised techniques and, just as importantly, how you tell whether they worked when there's no label to check against.
Most data is unlabeled, and some of the most useful ML finds structure without an answer key. Clustering, dimensionality reduction (the root of embeddings and semantic search), anomaly detection, and the hard problem of evaluating when there's no label to check against.
Merge and rebase are where Git's DAG earns its keep — and where most fear lives. Both integrate one line of work into another; they differ only in the shape of history they leave behind. Merge preserves the fork and records a convergence; rebase rewrites your commits as if you'd started later, producing a straight line. Neither is magic. Once you know what a merge base is, both become predictable.
Merge and rebase both integrate one line of work into another; they differ only in the shape of history they leave. Merge preserves the fork and records a convergence; rebase replays your commits as new objects into a straight line. Once you know what a merge base is, both become predictable.
You can have the right customer, sharp positioning, the right motion, and smart pricing — and still sell nothing, because no one knows you exist. Demand generation and channels are how you solve the awareness problem: getting the right people to discover you, and moving them from "never heard of it" toward "customer." For technical builders this is the least intuitive part of GTM, because it can't be reasoned out at a desk — it's found by testing where your customers actually are.
You can have the right customer, sharp positioning, the right motion, and smart pricing — and still sell nothing, because no one knows you exist. Demand generation and channels are how you solve the awareness problem, and it can't be reasoned out at a desk — it's found by testing where your customers actually are.
The single most counterintuitive fact in performance engineering: accessing memory is not one speed. A value in the CPU cache is hundreds of times faster to reach than one in main memory, which is thousands of times faster than disk. Your code's speed often depends less on how many operations it does than on where the data lives — and understanding the memory hierarchy is what lets you see that.
The most counterintuitive fact in performance: accessing memory is not one speed. A value in CPU cache is hundreds of times faster to reach than one in RAM. Your code's speed often depends less on how many operations it does than on where the data lives.