Think of it like the shift medicine made a century ago. Doctors once prescribed treatments because a respected mentor swore by them. Then medicine started running trials, tracking outcomes, and pooling results across studies. Software engineering is partway through the same shift, and understanding how it works lets you tell a real finding from a well-dressed guess.

Someone on r/dataengineering asked if there’s a standard for modern data architecture. With 20 years of experience, they had a batch pipeline pulling 200MB files into a data lake and a new source as a serialized Kafka stream. They wondered if streaming was the new paradigm or if they were becoming dinosaurs.

The best answer cut to the confusion: the question asked about architecture, but the follow-up discussed tools. They are on different levels. Data architecture has little to do with tool selection.

A team spends three weeks debating whether to use PostgreSQL or MongoDB. Six months later, nobody remembers why they chose one over the other, a new hire proposes switching, and the whole argument starts again from zero. The database was never the hard part. The team had no way to make the decision, agree on it, and remember it.

Most software failures are not coding failures. They trace back to an undocumented decision made without considering key forces, by the wrong people, or both. Architecture decision-making is the discipline of choosing well when the choice is hard to reverse.

Most data teams hit the same wall. The pipelines run, the warehouse fills up, and yet nobody trusts the numbers. Two dashboards report different revenue. An analyst spends a morning rebuilding a definition of “active user” that someone already wrote last quarter. The data exists, but the data nobody argues about does not.

Analytics engineering is the work that closes that gap. It sits between the people who move data and the people who interpret it, and it owns the messy middle where raw tables become datasets you can trust.

Looming over nearly every developer is a neverending sense of urgency from on high and an enduring belief that using AI means building at the speed of thought. As this cultural “norm” seeps into the software development lifecycle I can’t help but think about children in the back of the car whining for the hundredth time: “Are we there yet?!”.

What You’ll Learn

• What an HTTP status code is, and what problem it solves.
• Five mental models that make any code readable, not just the ones you’ve memorized.
• The mnemonic for all five classes, and four more models for the hard cases.
• The handful of codes you’ll meet 95% of the time.
• When the code lies to you (200 with an error inside).
• How to read status codes yourself with curl.
• Where to go to learn the long tail.

The Basics

Every HTTP response carries a three-digit status code: the server’s verdict on your request, delivered before any body content. The first digit classifies responses into five categories; knowing those five is enough to read any code you encounter.

I jump between macOS, Linux, Windows, and Chrome OS across many devices, and that’s just on desktop. On phones, my first was a Google Nexus One then a couple pit stops with Nokia Lumia 521 and 620 Windows Phones. Later I went back to Adroid with a Samsung S7, an S10, and others, I now carry an iPhone 13 Pro Max. I’ve also used long-dead operating systems like SunOS, Solaris, Warp OS, and many more. Oh, and I run Android TV on an Nvidia Shield and don’t forget three different Raspberry Pis and a Synology NAS all running various flavors of Linux.

A knowledge graph puts those connections first, treating the relationships between entities as the main thing. By the end of this article, you’ll know what a knowledge graph is, why people build them, how one works, and where it helps and where it doesn’t.

This tutorial uses plain Python, a list, small functions, no database, libraries, or setup beyond Python. By the end, you’ll have a runnable file that stores facts, answers questions, and navigates between facts.

If the words triple, node, or edge are new, read What Is a Knowledge Graph? first. This guide builds what that article describes.

An ontology earns its keep only when a team uses it. A software ontology is a shared model of a domain: its entities, their attributes, and their relationships, written so people and code agree on what each term means. This guide assumes the model already exists. The goal is to put it to work: in workflows, design sessions, database schemas, and on every screen where a teammate looks something up. Pick the section that matches the task in front of you. The command examples assume PostgreSQL and psql, but the practice maps to any engine that supports comments and constraints. The examples use the Subscription Billing context from the creation guide, so the terms line up across both articles.

A software ontology is an explicit, agreed-upon domain model, including concepts, meanings, and relationships. In DDD, it covers ubiquitous language, bounded contexts, and aggregates. This guide creates one.

Goal

Create a software ontology for a domain: a model that identifies key concepts, defines them once, classifies (entity, value object, or aggregate), and maps relationships and boundaries. The final artifact is an agreed-upon model reflected in the code.

A software ontology is a clearly defined, shared model of a domain that includes concepts, meanings, and relationships, documented and integrated with code. This article explains its role in Domain-Driven Design (DDD), why it exists, and how it functions as a mental model.

This article discusses AI’s impact on software engineering through the lens of software ecology, citing Adam Bender’s Google talk, “Software Engineering at the Tipping Point.” It helps you analyze your dev environment, spot vulnerabilities, and choose resilient principles.

The AT Protocol (ATproto) divides the monolith into parts that different people can run, use different languages for, and swap out without losing accounts or posts. Bluesky is its biggest app, but the protocol is more interesting for developers than the app.

The team is three weeks away from shipping. The demo went well. Estimates are tight. Velocity is trending up. The product manager is drafting the launch email.

Then the integration tests hit, the third-party API rate-limits at production volume, a database query takes four seconds instead of two, a security review finds an authentication gap, and the analytics team sees a schema mismatch.

Three weeks become three months.

For the theory and why the law holds, read What Is Conway’s Law? first.

Pick your guide