Before they show up, my mind sits in a tranquil pool. The reality I am working in is distilled and full of purpose, and I am making real strides toward the goal.

Imagine an AI that approves a second refund on the same order. Its reasoning is clear, and the tool call is correct. Yet, the refund remains wrong, and system knowledge isn’t enough to stop it, since the rule “one order gets one refund” exists only in someone’s mind.

That rule belongs in an ontology. By the end of this article, you’ll understand what an ontology is, why developers have always needed one, and why agents and LLMs need a robust one more than ever.

That leaves a question: what is doing the work now? Docker Desktop feels like one thing. Lima seems like tangled parts.

This article explains what Lima is, how it runs Linux on your Mac, and its relation to tools like nerdctl, Colima, and Rancher Desktop.

What You’ll Learn

• What is Mermaid, and what problem does it solve?
• What are the use cases for Mermaid?
• When is Mermaid not the right tool?
• Which two diagram types cover most real work?
• How do you build a pipeline diagram and publish it on GitHub?
• Where can you go to learn more about Mermaid?

The Basics

Mermaid is an open-source tool that turns short text descriptions into diagrams. Type A --> B and you get two boxes connected by an arrow. Knut Sveidqvist created it in 2014 so diagrams could live where code lives: in plain text, in version control, reviewed in pull requests like everything else.

If you want the concepts first, read What Is Lima? and come back. This article stays hands-on.

What You’ll Build

A working Lima setup: an Ubuntu virtual machine (VM) running on your Mac, managed from your terminal, serving a containerized nginx web page at localhost:8080.

Envoy is an open-source, high-performance proxy for cloud-native systems. It handles networking tasks like routing, retries, timeouts, load balancing, encryption, and telemetry, replacing application-managed functions. By the end of this article, you’ll understand why Envoy exists, how its configuration works, and why Kubernetes tools such as Istio, Envoy Gateway, Contour, and Emissary build on it.

Every if statement relies on ideas humans learn before talking. Booleans seem simple: one bit, two values. But explaining a boolean to someone with no programming background is difficult.

Boolean logic is a reasoning system based on two values, true and false, with three operations: AND, OR, NOT. It underpins all digital computers and program conditionals.

By the end of this article, you’ll understand Boolean logic, its purpose, how it works, and the mental patterns humans need before “true” and “false” mean anything.

If I were playing a game of Zork, it might have been fun pressing 1, 2, 3, or 4, or entering random words to get to the next level, but I wasn’t playing Zork. I was just trying to fix a declined credit card transaction. Every time I get a phone number and no other option, no email, no chat, I know I’m doomed. I expect to be jerked around for a minimum of 30 to 60 minutes and eventually end up in a purgatory loop where I’m expected to know the magic incantation I must cast to reach the secret department.

Why does “it works on my machine” stop being an excuse the moment a team adopts containers? Because a container ships the machine along with the code. That single shift, packaging an application together with everything it needs to run, is the heart of containerization.

A container is an isolated process that carries its own filesystem, libraries, and configuration while sharing the host operating system kernel. The application sees a clean, predictable world. The host sees just another process it can start, stop, and limit.

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