I would be remiss if I wrote my next blog post without reflecting on a recent amazing and profound experience I had in Tokyo, as part of Autodesk's COO Leadership Development Program.

Python has become the lingua franca for developing various AI/ML solutions (and more), but getting started with setting up a proper Python environment can be tricky and involve several hours of research or asking colleagues how they go about it, and many "getting started with Python" guides tend to gloss over these aspects, which is why I hope in this post to give a no-nonsense, guide to setting up Python environments.

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.