“If builders constructed buildings the way programmers write software, the first woodpecker that came along would destroy civilization.” —Weinberg’s Second Law of Software Engineering
Most of what I write about here is DevOps, which is a set of practices, cultural philosophies, and tools that combine software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver software more reliably and continuously.
Core ideas:
- Collaboration — breaks down the traditional wall between developers (who write code) and operations teams (who deploy and maintain it), encouraging shared responsibility throughout the entire lifecycle.
- Automation — automates repetitive tasks like testing, building, and deployment, reducing human error and speeding up delivery.
- Continuous Integration/Continuous Delivery (CI/CD) — code changes are frequently merged, tested automatically, and deployed to production in small, manageable increments rather than large, risky releases.
- Monitoring & feedback — systems are continuously observed in production, and that feedback loops back into development priorities.
- Infrastructure as Code (IaC) — servers and environments are provisioned and managed through code (e.g., Terraform, Ansible) rather than manual configuration.
The goal is to move from the old model — where dev and ops worked in silos, leading to slow releases and finger-pointing when things broke — to a model where teams ship faster, recover from failures quickly, and improve continuously.
In practice, DevOps often involves tools like Git, Jenkins, Docker, Kubernetes, and cloud platforms, but the cultural shift (shared ownership, blameless post-mortems, iterative improvement) is considered just as important as the tooling. My preference is a Linux-LiteSpeed-MariaDB-PHP (LLMP) stack which is used for this site.
But I’m also human (I think)
I occasionally stray off-topic and write about things beyond programming. I’m human, after all. I not only program for the Internet, I also read what is on it—and, occasionally, have opinions about it.
I tend to be skeptical of just about everything and try to analyze things objectively rather than emotionally. I’m generally more interested in understanding a problem and finding solutions than in deciding who or what to blame. This may also explain why I’m not invited to many parties.
I also enjoy creative writing, and sometimes use satire, sarcasm, parody, exaggeration, or absurdity to make a point. Those things aren’t necessarily intended to be taken literally—or even particularly seriously. The purpose is often to reframe an issue so that something familiar or controversial can be looked at from a different perspective and, ideally, encourage discussion rather than shut it down.
There is a long tradition of doing this. George Orwell’s Animal Farm isn’t really about farming, and Jonathan Swift’s A Modest Proposal wasn’t a literal proposal for solving hunger. The absurdity was the point: sometimes exaggeration and satire can expose an idea more effectively than a strictly factual statement ever could.
So, when I write something deliberately provocative or ridiculous, it is worth considering whether I’m making a literal claim—or whether I’m using the absurdity to make a different point. Not everything I write is a position statement, and not every argument needs to begin with, “According to the latest peer-reviewed study…”
Sometimes a little humor is simply a better way to get people thinking.