Back in the early part of my career, I found myself thrust into an environment that in retrospect was entirely predicated upon a waterfall design methodology. We would do big design up front, in excruciating detail, often without understanding the implications of what was even feasible, with the usual overruns that would happen in terms of time and money to go along with that.

I have pushed the content of this blog post to GitHub Pages with zero use of a personal access token (fine-grained or otherwise) or even an SSH key. How is this possible?

Chefs have a saying: mise en place, or "putting in place." This is a great analogy and philosophy for data in an enterprise as well...

Time and attention and energy are utterly precious and fleeting resources. Following that, there are few things you can do that are more egregiously and flagrantly detrimental to a colleague's time, attention, and energy than DM-ing them with a simple "Hi" or "Hello" with no context, expecting a response from that alone towards something you are seeking to accomplish.

Whether for your team, or for your product or service, a designated code name provides maximum flexibility in the face of what is an ever-present constant in our lives: change.

Point solution infrastructure as code (IaC) templates get very tiresome very fast, because they're not reusable.

In a previous post, I discussed the topic of vendor lock-in with cloud providers, and why I thought it was over-emphasized. I'd like to further highlight my stance using a real-life example of actual vendor lock-in, which, in my opinion, is more concerning.

In the last few systems and services I've designed for cloud, I've taken an approach of starting with the limits and working backwards.

People have been wondering about how I created my themed terminal setups, so I thought I'd make a post about it.

I wanted to capture some thoughts on deployment approaches for OpenAI in a large enterprise.