You’re three commands into a deploy over ssh when the Wi-Fi drops, and the shell dies with it. Or you juggle six terminal tabs and lose track of which one runs the dev server. tmux fixes both: it keeps your shells running on their own, lets you split one terminal into many, and lets you walk away and come back to exactly where you left off. This guide covers the 20% of tmux that does 80% of the work: sessions, windows, panes, the prefix key, and a small configuration file. A searchable command reference and a curated set of videos, podcasts, books, and online resources close the article.

Every entry below is a jq filter, what it returns, and a minimal example. Output shown came from jq 1.8.2. For the guided version with explanations and larger worked examples, read the jq Cookbook. ## Run Any Entry Here The runner holds the same `employees.json` used throughout this reference. Paste any filter from the entries below into the filter box and press Run. Input JSON { "company": "Acme", "employees": [ { "id": 1, "name": "Ada Lopez", "email": "ada@acme.example", "dept": "Engineering", "age": 34, "salary": 145000, "skills": ["go", "sql"], "manager": null }, { "id": 2, "name": "Ben Okafor", "email": "ben@acme.example", "dept": "Engineering", "age": 28, "salary": 118000, "skills": ["python"], "manager": 1 }, { "id": 3, "name": "Chen Wu", "email": "chen@contractor.example", "dept": "Design", "age": 41, "salary": 99000, "skills": ["figma", "css"], "manager": 1 }, { "id": 4, "name": "Dana Smith", "email": "dana@acme.example", "dept": "Sales", "age": 25, "salary": 72000, "skills": [], "manager": 3 } ] } jq filter Run Output Press Run to execute this filter. This runner needs JavaScript. Every filter here also works in a terminal with the sample file from Set Up jq and the Sample Data.

Git hangs for a while, then gives up: ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Your key is not the problem. The connection never got far enough to offer one. Something between you and GitHub is dropping traffic on port 22, which is normal on corporate networks, many hotel and airport networks, and some mobile hotspots. GitHub publishes an SSH endpoint on port 443 for exactly this. Everything below was tested with OpenSSH 10.3 and Git 2.55.0.

I’m Jeff Bailey, a principal software engineer. I’ve worked at Nike since 2019, first on the product customization platform and now on tech modernization and platform work: enterprise architecture, cloud cost optimization, and the InnerSource and open source practices that let teams share code instead of rebuilding it. I’m a FinOps Certified Practitioner and a board member at InnerSource Commons. Before Nike I consulted for clients across retail, healthcare, and construction software. I’ve been writing code since the start of my career in the 90s, back through Earthlink and the early web. The full history is on my resume.

Have you ever worked with someone who leaves confusion everywhere they go? You are having a level-headed conversation about something simple, work is moving, and then they arrive. What follows is _**Confusion as a Service**_ : a relentless focus on things that do not matter in any universe, with any meaning whatsoever. 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.

## Introduction 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.

Lima enables you to run a Linux machine on your Mac for free. This tutorial helps you install Lima, launch a Linux VM, verify shared files, and run a web server in a container accessible via your browser. 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`.

Run `kubectl get pods` in a Kubernetes cluster with Istio installed, and every application pod shows `2/2` containers. You deployed one container. The second is Envoy, and it now handles every byte of network traffic your application sends or receives. 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.

## Introduction 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.

I just got off a 27-minute call trying to understand and fix a credit card decline problem with my Flexible Spending Account (FSA), not to be confused with my Health Savings Account (HSA). Thank you, government, for creating two accounts that sound very similar. It was a wonderful adventure. 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.

Most claims about how to build software are opinions wearing the costume of fact. “Pair programming catches more bugs.” “Microservices scale better.” “This linter improves quality.” Each sounds authoritative, and each is testable. Empirical software engineering is the discipline that does the testing: it studies how software is built, maintained, and used by collecting real data and analyzing it, instead of trusting whoever argues most confidently. 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.

## Introduction 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.

## Introduction 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.

A new paradigm is emerging in the age of AI-led software development. I’m calling it _**Are We There Yet Development**_. Last week a developer walked over to another developer asking for something they felt they needed to proceed with their _**critical**_ greenfield project when the developer was in the middle of troubleshooting a production incident. 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?!”_.

**Quick Start:** Learn five mental models that cover every HTTP response, then read live codes with `curl`. Total time: 20 minutes. ## 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 admit it: I’m an operating system addict. I’ve installed countless operating systems over my life, and I still use many of them. It may seem like a bad idea. It isn’t. 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.

Most data starts as rows in tables: customers, orders, tickets. To see how a customer links to a product they refunded through a support ticket, you write joins. The connections exist, but the tables hide them; they surface only when you go looking. 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.

The interviews are complete. Someone worked with the domain expert to create `ontology.md`. Six months later, a report counts the same `Customer` thrice, despite the model’s purpose to prevent this, and it hasn’t been updated since launch. An ontology is useful only when used by a team. A software ontology is a shared model of a domain—its entities, attributes, and relationships written to ensure everyone, including code, understands each term. This guide assumes the model already exists and aims to integrate it into workflows, design, schemas, and interfaces. Select the section relevant to your task. Command examples assume PostgreSQL and `psql`, but they support any engine with comments and constraints. Examples refer to the Subscription Billing context from the creation guide, aligning terms across both articles.

Two senior engineers argued for an hour over a bug. The fix took ten minutes, but the argument lasted fifty. One meant “active subscription” when saying _customer_ , the other meant “any account.” Both were correct but lacked a shared model. 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.

Open a mature codebase and grep for `Customer`. In billing, it means an active, paid account; in support, anyone who has sent an email; in analytics, a deduplicated household. The bug isn’t in one module, but in three teams misunderstanding they’re referring to the same thing. 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.

Your job as a software engineer in 2026 differs from 2020, beyond just using chat tools. Every system component, review queue, test runner, version control, release process, and on-call rotation must handle more load than they were designed for as demand continues to rise. 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.

Most social networks use a single database with an app, storing usernames, posts, algorithms, moderation rules, and HTML within the same company. Building on top means relying on the vendor’s rate-limited API, which can change or disappear unexpectedly. 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 pattern 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.

A read-only feed of operator updates. You can join via guest mode to read history; posting is reserved for operators. This room lives on its own page because Element only maintains one session per browser origin — embedding `#public` and `#announcements` on the same page would have the second iframe display “Element is connected in another tab.” Visit the About page for the open `#public` chat.

## Prerequisites This guide assumes: * **Familiarity with Conway’s Law.** Read What Is Conway’s Law? first if “communication structure shapes system structure” sounds new. * **Access to the deployed system.** You need to see the service list, runbooks, and on-call rotations. * **Visibility into pipelines and release boundaries.** You need to know which services ship together and which ship separately. * **A blank document or whiteboard.** You will sketch a map as you go. ## Walk the deployment Treat deployed software like a fossil record. Every service boundary, API contract, and deployment pipeline carries the imprint of the people who shipped it. Walk the deployment in this order:

## The pattern You redraw the org chart. Six months later, the codebase has grown new seams along the new team boundaries. The teams reshaped the software without intent. That pattern has a name: **Conway’s Law**. Any system you ship will reflect the communication structure of the people who built it. Modules align with teams. Interfaces form along reporting lines. Coordination friction shows up as code friction. This matters because technical leaders keep treating organizational problems as technical problems. A microservice split fails when two teams still own a single service. A monorepo grows congested because four teams edit the same file. The architecture is doing exactly what the org chart told it to do.

Cloud bills are scrutinized to the cent. AI coding tool spend analysis is complex, with token-based pricing, multiple subscriptions, and quick pilots hiding total costs until reviewed by finance.

## Introduction I first heard about Ollama when a colleague mentioned running GPT-like models on a laptop. My first reaction was the same one most engineers have: you can do that? The short answer is yes. Ollama makes it possible to run large language models locally on consumer hardware. You need only a Mac, a PC, or even a Raspberry Pi and a few minutes to pull a model. Ollama is an open source tool for running large language models on your own hardware. It wraps llama.cpp, a highly optimized C++ inference engine, and exposes a simple API that mimics the OpenAI chat endpoint. You pull models with a single command, talk to them with curl or any SDK, and the system handles GPU acceleration, memory management, and model loading automatically.

## Introduction Why do some technical teams ship great work while others stall in indecision, drama, and rewrites? The difference is rarely talent. It’s leadership. Technical leadership is the practice of using deep technical judgment plus people skills to set direction, make hard calls, and help a team do its best work. A technical leader is not always a manager. The role can be a tech lead, staff engineer, principal, architect, CTO, or a founder who happens to write code. What unites them is influence rooted in credibility, not authority handed down from an org chart.

I used to open files the slow way: `cd` into a directory, `ls` to see what’s there, maybe `find` with a half-remembered filename, then pass it to whatever program I needed. Every time, I’d lose a few seconds hunting for the right path. Multiply that by dozens of files a day, and it adds up to real friction. Then I found fzf, and file selection stopped being a chore. fzf is a fuzzy finder that turns file selection into a fast, interactive search.

For years, “AI in my editor” meant autocomplete. Copilot would suggest the next few tokens, I’d hit tab, and that was the interaction. Useful, but shallow. The AI stayed in one file, ignored my tests, and had no way to know when its suggestion broke the build. Claude Code works at a different level. It runs in my terminal, reads my files, runs my commands, and talks back in plain language. When I ask it to fix a failing test, it runs the test, reads the failure, finds the bug, edits the file, and runs the test again to confirm. The result feels less like autocomplete and more like delegating a small task to a teammate.

AI agents that can write code are easy to find. AI agents that write code I’d actually ship are rare. Nwave is one attempt at the second problem, and understanding its shape helps me think more clearly about every other AI coding tool I use. ## What is Nwave? Nwave is an agentic AI software delivery methodology that runs inside Claude Code. It slices the work of shipping a feature into six ordered waves, assigns a specialized agent to each wave, and stops for a human review between waves.

The history of AI is a story about math that already existed, people stubborn enough to believe in it, and a few decades of everyone else telling them they were wrong. Most of the math powering today’s large language models comes from the 17th and 18th centuries. Calculus, linear algebra, probability theory. The machines caught up to the math, not the other way around. I picked up Why Machines Learn by Anil Ananthaswamy because I wanted to understand what actually happened, not the hype version. The book traces the mathematical lineage from early pattern recognition through deep learning with the kind of rigor and storytelling that made me rethink how I understood the whole field.

It has been a wild near half decade ride on the GenAI coding tool beast. If I’d ridden a bucking broco like I fantasized about as a kid it would serve as a clean overlaid transposition of my mind with my ass. 🐂 🤠 I first used a GenAI coding tool in October 2021, when I was added to the GitHub Copilot Technical Preview. It was interesting, but barely better than IntelliSense—which is a tool collecting dust in my garage now that I think about it. I continued using it and as its performance improved it became my daily driver while continuing to use Neovim to get my digits dirty.

## Why Automate Anything? Early in my career, I led a team that performed repetitive file updates for customer web servers, consuming their entire day. I had a bright idea and asked our local Perl developer to automate their tasks. A couple of weeks later, a few magical scripts emerged, saving hundreds of hours, and my love of programming was born. Software automation replaces manual, repetitive tasks: building code, provisioning servers, testing, deploying. Machines run the repetitive steps; people keep judgment calls. That cuts cost and the errors humans introduce in rote work.

## Why Traffic Management Becomes the Real System Distributed systems fail at the boundaries between services. A single user request crosses many network hops, each with different latency, failure behavior, and ownership. Without shared traffic controls, every team invents its own retry logic, timeout values, routing rules, and access policy. That creates inconsistent behavior, hidden coupling, and outages that are hard to contain. This is the problem control planes and service meshes are built to solve. A control plane gives teams one place to define traffic policy, and the data plane enforces that policy on real requests. Sidecars and mesh proxies make resilience and security rules consistent across services without forcing every application team to reimplement network logic.

I can’t imagine you’ve never used a Microsoft product. Assuming you have, you may have heard of Clippy. Clippy was a feature of Microsoft Office products from 1997 to 2002 and left an indelible mark on the tech industry as one of the biggest software-based personal assistant flops. Clippy would pop up on the first run of Microsoft Word and Excel, with a friendly intent of helping you use the products. Its most consistent features included being wrong and unhelpful. If the software industry had used user behavior metrics back then, the Clippy disable button would likely have been the most-used feature in Microsoft products.

## Introduction Most programs start as a single sequence of instructions. That works until the program needs to wait for something (a network response, a disk read, user input) or until the work is large enough that a single processor core can’t finish it fast enough. Concurrency and parallelism are different responses to that problem. Concurrency is about _managing_ multiple things at once. Parallelism is about _doing_ multiple things at once. They overlap in practice, but confusing them leads to designs that are either needlessly complex or slower than expected.

## Why Integration Is Hard (and Worth Understanding) Why do some organizations connect five systems in a week while others spend months wiring up two? The difference is rarely the technology. It is understanding how integration actually works and choosing the right approach for each situation. Software systems integration connects separate systems, so they exchange data and coordinate behavior. Every non-trivial organization runs multiple systems, and those systems need to talk to each other. A customer record created in one system should be visible in another. An order placed on a website should reach the warehouse. A payment processed by one service should update the ledger.

Networking fundamentals for developers: packets, IP addressing, routing, TCP and UDP, DNS, TLS, and a practical troubleshooting mental model.

Algorithmic patterns reference: two pointers, sliding window, dynamic programming, and 30+ more. Learn to spot patterns and solve problems faster.

CPU vs GPU vs TPU: learn how processing architectures differ, when to use each, and how latency, throughput, and data movement shape performance.

Data structures guide: arrays, hash maps, sets, stacks, queues, trees, graphs. Types, properties, when to use in Python, JavaScript, Java, C++, Go, Rust.

Reference guide to fundamental data structures: arrays, hash maps, sets, stacks, queues, trees, and graphs. Learn where these structures appear in programming languages and their core properties.

Master data structure fundamentals: arrays, hash maps, trees, and graphs. Learn how structure choices shape algorithm performance, reliability, and developer sanity.

Learn color and contrast fundamentals for readable, accessible interfaces. Understand color theory, contrast ratios, and WCAG standards.

Master algorithm fundamentals: data structures, Big O notation, and runtime complexity. Learn how algorithmic thinking helps build fast, reliable software and prevent production incidents.

Software security fundamentals: threats, vulnerabilities, and defenses. Build systems that protect data and users from attacks.

Performance testing fundamentals: load testing, stress testing, and metrics. Build systems that handle real traffic and find bottlenecks before users.

Learn color and contrast fundamentals: build readable interfaces, ensure accessibility, and create effective visual designs. Understand color theory, contrast ratios, WCAG standards, and color accessibility.