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.

If I’d ridden a bucking bronco 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.

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.

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.

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.

You add more cores. The program gets faster. Keep adding, and gains shrink. Eventually, speed stops rising.

That ceiling has a name: Amdahl’s Law. It gives the maximum speedup from parallelizing a program, given how much work must still run sequentially.

This matters because it prevents wasted effort. Teams add hardware expecting linear speedup, then hit diminishing returns. Amdahl’s Law explains why and points you to the bottleneck that actually needs work.

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.

Every JavaScript bug I debug relates to type coercion, this issues, stale variables in closures, or unhandled promise rejections. These aren’t quirks but design consequences. Understanding the design clarifies the bugs.

Brendan Eich created JavaScript in 1995 at Netscape in just 10 days. It was meant to be a simple scripting language for browsers, accessible to non-programmers alongside Java applets. This origin influenced its features: dynamic typing, prototype inheritance, first-class functions, and a single-threaded event loop. Many quirks, such as type coercion, this binding, and hoisting, stem from decisions made quickly for a specific purpose.

🤦🏻

I loathe Medium, not least of which for popularizing the “magic link” pattern in 2014.

Their rationale—passwords provide a worse user experience than email, as most people click “forgot password” anyway, so why not skip the middleman?

No, it’s not a worse experience.

I have a password manager, and I press Cmd-Shift-L, and Bitwarden happily fills it in. I can even use auto-fill if a website plays nice. But, not with websites that ONLY have Massive-Pain-In-The-Ass Links™️. I don’t want to open my phone or email client to copy a code, especially if I can’t paste it because a destroyer of webs never took HTML Forms 101.

Every systems language demands a trade-off: control memory and risk crashes or rely on a garbage collector and lose predictability. Rust avoids this by offering control, performance, and safety, which I find genuinely interesting.

Graydon Hoare began Rust in 2006 as a personal project, and Mozilla adopted it in 2009 to develop Servo, an experimental browser engine. The motivation was practical: Mozilla’s C++ code had frequent memory bugs and security issues, prompting the need for a language that prevents such bugs by design. This origin shaped Rust, making it a practical solution for real systems programming, not just an academic exercise.

Why do cloud bills spiral when nobody intended to overspend? Cloud is pay-as-you-go; without visibility and accountability, usage and cost drift. FinOps (cloud financial operations) brings financial accountability to variable cloud spend through collaboration, data, and continuous improvement.

This article explains why FinOps exists, how its ideas fit together, and what changes when teams treat cloud cost as an operational concern. It focuses on why the lifecycle and domains work, not on tool setup.

Why does Azure feel like a second platform rather than “Windows in the cloud”? Microsoft Azure is more than virtual machines and Office integration. It is a global system of regions, a distinct identity layer, and a management hierarchy that relies on understanding key ideas.

This article explains Azure’s structure: regions, Availability Zones, Microsoft Entra ID, resource groups, subscriptions, and the shared responsibility model. It highlights principles and trade-offs to help you make better decisions and avoid costly mistakes.

Why does moving to the cloud feel like learning a second operating system? AWS is more than “someone else’s computers.” It’s a global system of regions, services, and a security model that rewards understanding core ideas.

This article explains why AWS is structured as it is: regions, Availability Zones, identity, and the shared responsibility model. It focuses on principles and trade-offs to help you make better decisions and avoid costly mistakes.

Like other technologies, generative AI (GenAI) has displaced the old ways. Doing math by hand or with an abacus was the way until calculators came along, and then computers. Who uses a physical calculator anymore? And, why didn’t they set Monarch in the 1950s? What a missed opportunity.

Goal

By the end you will have used DNF to install a package, update your system, remove a package, and search for packages. You will know how to confirm each step and fix the most common failures.

Goal

By the end, you’ll have used APT to install, update, remove, and search for packages, knowing how to confirm each step and fix common failures.

Success criteria: You can run apt install, apt update, apt upgrade, apt remove, and apt search from the command line and interpret the output. You can confirm a package is installed and working.

Glossary

Agile Software Development

Agile Manifesto: A 2001 statement of values and principles guiding agile software development by developers.

Backlog: A prioritized list of work items, features, or user stories for the team to complete.

Burndown Chart: A graph tracking remaining work over time to monitor progress in an iteration or sprint.

Continuous Integration (CI): The practice of integrating code changes often, usually several times daily, with automated testing to identify issues early.

Why do some codebases feel easy to change while others turn every fix into a weekend project? The difference is maintainability.

Maintainability is how easily you can modify software to correct faults, improve performance, or adapt to new requirements. The International Organization for Standardization (ISO) defines it as a core quality attribute in ISO/IEC 25010. Maintainable code costs less to change, carries lower risk when refactoring, and lets new team members contribute without weeks of orientation.

I write extensively on software fundamentals, covering architecture, security, reliability, testing, performance, accessibility, and process. The articles are lengthy, detailed, and checklist-rich.

I kept encountering the same issue: knowing fundamentals and applying them in code review are different. I’d review PRs, catch a timeout or a query, but forget accessibility or circuit breaker.

Human memory is unreliable. Checklists help, but reviewing 200+ items manually isn’t practical.

I built skills that encode fundamentals into repeatable, automated fitness reviews. This article explains what they are, why they work, and how they fit together.

When I submit a pull request, I rely on existing tests, written months or years ago, which run with each change. But what if tests could be automatically generated for each diff, tailored to catch bugs before code lands? That’s the premise of Just-in-Time (JIT) Catching Test Generation.

This approach turns traditional testing on its head. Instead of maintaining a static test suite that you update whenever behavior changes, catching tests are generated on the fly by large language models (LLMs). They are meant to fail when they find a bug. They do not live in your codebase. They exist only to catch regressions in the specific code change under review.

Why do some queries that feel simple in your head turn into multi-table joins, subqueries, and endless recursion in SQL?

Years ago, I modeled a permission system where “User A has role X in project Y” became a maze of join tables. I envisioned a graph, but the implementation struggled with the database. A graph database would have fit my thinking better.

When your data is about relationships (who knows whom, what depends on what, how things connect), a relational database makes you work against its grain. Graph databases emerged in the 2000s precisely because of this friction, as social networks, recommendation engines, and fraud detection systems pushed relationship queries far beyond what SQL was designed for. Graph databases flip that friction around. They make relationships first-class: stored explicitly, queried directly.

Core Idea: Three Frontiers

Augmented workflow optimization. Developers are generating more code than ever with AI-assisted tools. The value is real, but the economics are not. AnySphere, Anthropic, Microsoft, Google, and Amazon Web Services are all subsidizing the real cost of augmented workflows to varying degrees. They need developers inside their ecosystems, so they absorb the cost. Using local open-source LLMs for part of your workflow is one way to cut costs and rely less on those subsidies.

When I download software, I rarely know what’s actually inside it. Is it just the code the vendor wrote, or does it include hundreds of open source libraries? If a vulnerability appears in one of those libraries, how would I know if I’m affected? These questions become critical when managing software across complex supply chains.

A Software Bill of Materials (SBOM) answers these questions. An SBOM is essentially an inventory list that documents all the components in a software product. Just as a physical product has a bill of materials listing its parts, an SBOM lists the software components, their versions, licenses, and relationships.

Most software relies on open source components, with your app potentially using hundreds of libraries, frameworks, and tools maintained by different teams with varying security practices. A vulnerability in one can impact thousands of applications.

The Open Source Security Foundation (OpenSSF), hosted by the Linux Foundation, aims to improve open source security with tools, standards, and collaboration. It unites organizations, developers, and security experts without replacing project efforts.

This article explains what OpenSSF is, why it exists, and how it helps secure the open source ecosystem that modern software depends on.

Most organizations depend on open source software but never formalize how they use it. Developers pull in libraries without a consistent view of licenses. Legal finds compliance gaps late. Security can’t see the full dependency picture. Contributing back is ad hoc. An Open Source Program Office (OSPO) is the function that steps in to coordinate all of that: strategy, policy, compliance, and community engagement. It doesn’t replace developers or teams; it provides the structure and expertise so the organization can use open source effectively and responsibly.

What Are GitHub Private Mirrors?

A private mirror is a private copy of a public repository within your organization. You develop and review there; when ready, push approved work to a public fork in your org, then open a pull request to the upstream project. The mirror remains private, with only synced content leaving your control.

Retrying a remote call immediately when it fails can worsen the situation. Overloaded dependencies may be overwhelmed further, prolonging outages.

Exponential backoff increases wait times between retries (e.g., 1, 2, 4 seconds) to give struggling services room to recover, rather than piling on.

By the end of this article, you will:

• Understand what exponential backoff is and why it exists.
• See how it works conceptually and fits with timeouts and jitter.
• Correct the misconception that backoff alone avoids overload.

What this is (and isn’t): This article explains why exponential backoff exists, how it works, and how it fits with timeouts and jitter. It does not cover SDK retry defaults, circuit breaker implementation, or load testing.

These principles align with my professional principles and leadership philosophy, forming a comprehensive framework for effective decision-making and growth.

Mental and Emotional State

🤔 Cultivate Comprehension — Understand and teach my experiences.
🌽 Embrace Abundance — Create what matters.
❤️‍🔥 Nurture Love — Nurture deep caring in my relationships.
💪 Practice Conscientiousness — Execute my tasks with the utmost care.
🧘 Promote Mindfulness — Focus on being aware of my current state and surroundings.

Why do teams invest in failing projects and choose poor options when better ones exist? Why do they trust the loudest voice over evidence?

Software development decisions happen under uncertainty, incomplete info, and time pressure. The brain relies on shortcuts for quick decisions, causing errors that compound in team discussions and architecture choices, leading to avoidable failures.

Software development amplifies errors from long-term decisions, numerous stakeholders, and complex systems with hard-to-trace cause and effect. As systems and teams became more complex and distributed, errors caught in small teams began causing bigger problems.

Why do some services hang until clients give up, while others fail fast and recover?

Timeouts limit how long an operation can run before it’s considered failed, preventing indefinite blocking of resources due to unreliable networks and dependencies, which could hide real failures.

When a payment call hangs for 60 seconds, a database read blocks a request, or a slow dependency exhausts the connection pool, it’s a timeout problem. I see timeouts as the essential protection at every boundary.