I haven’t posted much this year as I have spent the majority of my writing time working on my upcoming book, Mastering Software Architecture. I want to share an excerpt in the form of the preface to the book which describes its goals and approach. If this resonates, you can pre-order using the link above or sign-up here for updates and more.
We can’t always control what happens to us, but we get to choose how we respond.
Last night I was flying home from a show and my flight was MASSIVELY delayed (and eventually cancelled). It was frustrating. I had been on the road 12 days out of the last 15, I missed my wife, and I desperately wanted to sleep in my own bed.
I could have vented my anger at a gate-agent who has no more control over the situation than I did. I could have wandered to a bar to drown my sorrows… But instead, I decided to stage an impromptu show for my fellow stranded passengers.
I’m currently in Budapest, HU speaking at and attending a conference. Although the attendees are smart and passionate, the speakers have many valuable things to say, I see the continuation of an alarming trend in the tech industry: The sessions that promise simple answers are wildly popular while the sessions that offer insights on how to improve our thinking and mental models are are relatively sparsely attended. This culture of “don’t make me think, just give me the answers” is crippling our industry.
If you’re reading this there is a better than average chance that you either are an innovator or will be soon. People who regularly attend conferences, read widely, and follow obscure and longwinded blogs tend to skew venturesome; active information-seekers with diverse social groups and information sources, possess breadth of knowledge, are more willing to explore and adopt new ideas, and are able to cope with higher levels of uncertainty. If you are an innovator then, according to current research, you are part of a vanishingly small demographic that makes up just 2.5% of the total population. The unique cognitive and social diversity of this group offers perspective and insight into ideas, opportunities, possibilities, and solutions ahead of the mainstream.
Perhaps you see the solution to a problem right now. Congratulations, you have an idea–an innovation–that just might make a material difference in the lives of a lot of people. How do you get the other 97.5% of the population to adopt your solution? Will your innovation take off by itself on the merits of its benefits? Unlikely. If the best ideas always won, I wouldn’t be writing this. Even when the idea or innovation has clear and obvious advantages, skeptics must be won over. Old, entrenched habits must be abandoned. Innovations must be evaluated, explored and increasingly accepted until they reach critical mass (only then will they take off). This process can take years or may never succeed at all. Your efficacy as an innovator depends on your ability to optimize and streamline this process, influence your peers, and ultimately effect change in the real world. There is an art–and a science–to the diffusion of innovations.
In part I we explored the history and goals of DevOps and the Agile movement and the motivations for maturing your DBOps practice. In other words, part I addresses “mindset.” Let’s now look at this in practice and get into the “how” of DbOps, addressing the remaining “skillset” and “toolset” topics. Most crucially this involves not only understanding the tools you’ll be working with but also understanding the database. Poorly planned database changes have the potential to cause extended unwanted downtime and, if they break compatibility with the previous version of your app, can complicate rollbacks. Knowledge of RDBMS internals is crucial to moving “offline-breaking” database changes (database changes that require downtime and break compatability with previous versions of code) to “online-compatible” changes (database changes that do not introduce downtime and can be remain backward/forward compatible with code changes).
Everyone seems to want agility, and the DevOps movement has provided tools and practices to enable this. While the tools available today are wonderful, there remain unique challenges when it comes to delivering code changes that also include database changes.
I’ve been building database pipelines on-and-off for over 20 years now. The tools have may have changed but the core principles have not. It would be trivial to write a talk, essay or blog post that was just a tour of syntax and an entertaining summarization of the documentation. You don’t need me to read the docs only to regurgitate them for you into prose or PowerPoint. Instead, I’m going to take a holistic approach that encompasses mindset, skillset, and toolset. What I hope will make this work stand apart from similar content out there is I will be writing from the perspective of a (recovering) DBA and share vital insights that are more relevant than ever.
This post picks up from part I which broadly tells the story of where we are currently and how we got here; ultimately introducing HTMX as the “third way.” It serves as the background and context for this post. If you haven’t already read it, go ahead… I’ll wait.
Now that the background is out of the way, let’s look in depth at HTMX. Rather than the usual quickstart or toy examples, we’ll be looking at this in the context of a real production application already in the wild. We’ll modernize a legacy MVC application, examining the UX without and then with HTMX.
A.k.a Michael Cary - and all the other identities and aliases I have held in my life (fun fact, this might be the first time ever those two names have appeared side by side in public!). They’re all masks I’ve worn, idealized versions of myself that I want to present to the world and, ultimately, lies I’ve told myself (and possibly you).
“I’m not defined by what you see, I’m also all of the things you’ll never see.”
-Derek DelGuadio, In and Of Itself
I wrote something today, and felt moved to publish it somewhere. If you are one of the vanishingly few people who actually read my blog, it’s entirely possible you’re interested in getting to know not just my thoughts on tech, but perhaps also interested in getting to know me a little deeper as well.
Read on if you want to see some of the parts of me you have likely never seen. I’m exposing myself for a moment, “warts and all.” If not, no worries, more tech opinions and knowlege are already in the works.
When I look back on my career in technology, I’ve been seduced, over and over again, by this idea that best practices exist and that I can consider my work “good” so long as I follow those best practices. In some ways it would be wonderful to work in a field where there are absolute “right” and “wrong” answers but I no longer believe software engineering is one of those fields. Every single decision we make has consequences and whether these consequences are positive, negative, or mixed will depend on the context. It’s all just a set of trade-offs, and the key to making good decisions lies in understanding what matters most and evaluating the trade-offs in this context.
There are no best practices, only trade-offs.
-First law of Software Architecture
We’ve somehow gotten into this weird place in web development where the consensus seems to be that an absolute set of best practices exist; where the only meaningful decisions surround which framework to use and how to find the optimal implementation details within that chosen framework. Unfortunately the web development space has become so myopically focused on frameworks, tooling, and Single-Page Applications (SPAs) as the de-facto “best practices” that the trade-offs of these approaches are rarely discussed–or even well-understood up front–and, in many cases, the result is an ocean of bloat and accidental complexity that often could have been avoided entirely.
I have now been typing using the Dvorak keyboard layout longer than I have used QWERTY. It’s been over 15 years since I first switched and probably a decade since I moved to the even more niche Programmer Dvorak Layout. As the year winds down (and I am in currently in quarantine) I figure I’d take some of this idle time to write a little bit, and this is where my head is at today. Who knows, there may be some interesting take-aways from this. On the other hand, it may just be 1000-or-so words of “brain droppings” as George Carlin would say.