About the Author
Hey folks, thanks for reading this "book" if it can be called as such. I'm Jean-Sébastien Dominique, Jean or JD for short, and I've been programming for over 30 years and working professionally in software development for 20 years. I have worked in many diverse fields including web development, search engines, on-demand video streaming, online purchasing, banking, insurance, cybersecurity, satellite telecommunications, 5G, flight simulators, cloud services, and many more. I am a licensed amateur radio operator and a commercially-trained airplane pilot. I have a Bachelor's degree in electrical engineering with a specialization in telecommunications and digital signal processing. I had almost completed a Master's in mm-Wave RFIC circuit design, but I much prefer software engineering and dropped out of it. Recently, I've realized that my experience and training in aviation, especially in Human Factors, can be generalized and applied to DevOps. My latest project is therefore a Master's in Human Factors. So far, it has been confirming what I've been saying all those years, allowing me to back it up with science rather than merely being dismissed by others as opinions. This blog initially started out of spite, since a lot of weight in work environments is given to other people's opinions just because they wrote it in their blog, rather than focusing on actual experience and expertise. The blog has since evolved to instead become a teaching tool.
Why This Blog Exists
It started out of spite.
Throughout my career, I kept running into the same pattern: people dedicating themselves to the guidance of specific blog posts or books without ever being critical about the work. The biggest example is Clean Code -- probably the book I hate the most because of how much unearned authority people give it. I found that following its guidance led to poorly maintainable code. Over-abstraction. Single-line functions that should have been inlined. Code where you couldn't tell what it was actually trying to do because everything was fragmented into tiny named pieces. There's nothing inherently wrong with a longer function, but I kept getting criticized for writing them because "as per Clean Code..." The best takedown I've seen came much later -- qntm.org/clean -- where the author demonstrates that Martin's own example code violates his own rules, producing exactly the kind of illegible, side-effect-laden mess the book claims to prevent. It contributed to my motivation to start writing more.
Here's the irony: the most maintainable code I've ever worked with was written in the 1990s -- before Clean Code, before eXtreme Programming, before any of it. Since XP took hold in the early 2000s, I've watched maintainability and readability trend massively downward despite that being the stated goal. What these movements actually did was average out the bad code into better code, but also average out the better code into worse code. And the cognitive science explains why: humans can hold roughly 3-7 elements in working memory at once, yet the layers of abstraction and indirection that these practices introduced force you through 8-10 layers just to understand what a simple function call does. The practices were supposed to help humans reason about code. They made it harder.
But it wasn't just Clean Code. It was the same pattern everywhere. The author of Java's Optional<T> said not to use it, so people fought you if you did -- despite it making code semantically clearer and more human-readable, as if the billion-dollar mistake of null was somehow preferable. In PHP, influential people wrote great things (the Symfony framework comes to mind), but others just hyped whatever they built as the next revolution. Around 2012-2014, there was a wave of web frameworks competing to build your website in the fewest lines possible, even if the framework itself was thousands of lines. As if I cared about building a site in two lines of code -- you just built a giant templating system, not a usable framework. And somehow, people gave those authors enormous attention while I was out there writing quality code that's still in use today, getting none of it, just because I didn't share my intimate moments with my code over the public internet.
What really hit me was landing at AWS and discovering that 15 years after having debates over Clean Code, Java Optionals, and nonsense optimizations (declaring variables inside vs. outside a loop -- it doesn't matter, but I had to spend an evening proving it), I was facing the exact same debates. The blogs had changed -- the ones from 2005-2010 were replaced by other people repeating the same claims in 2015-2020, sometimes as their own. The same arguments, 15 years apart. Nothing beats generating clicks over controversial ideas, it seems.
So I started doing knowledge sharing sessions with my team, making them realize the problems they were trying to solve weren't new -- they were problems I'd already solved 10-15 years ago that had been solved even before then. My career was spanning across a new generation that was unaware of what came before them and discovering it fresh (one of today's lucky 10,000). The same cargo-cult guidance was being propagated over newer copycat blogs, and I'd been sitting there thinking time would prove them wrong.
Those knowledge sharing sessions turned into writing. I put a lot of that information on a blog -- not this one, but the same website. Eventually I lost the confrontational tone and moved to a teaching one. But it was still too formal.
Then I did a presentation on applying Human Factors to DevOps. I presented aviation accident case studies alongside DevOps incident post-mortems and drew the parallels: the human element failing in the same ways, the system failing the humans in the same ways. Except aviation has learned from it, and DevOps hasn't. That presentation pushed me toward my current Master's, where my research focus has narrowed to how humans interact with AI in complex systems -- which is pretty much the topic of this blog. I've been applying these concepts to DevOps and organizational environments with great success since. Applying Human Factors research to DevOps is largely novel -- there's almost no existing literature on it -- and that's the gap I'm working to fill.
The conversational style came from realizing I could always explain things clearly in one-on-ones with my mentees but could never figure out how to do it formally in writing. Turns out I just needed to write the way I talk.
Since starting the Master's, the blog has evolved into a reflection of my academic research aimed at DevOps practitioners. It relies on academic papers but doesn't overburden the narrative with them -- using them sparingly to support the claims rather than gatekeep them. My goal is to become a noteworthy reference on responsible and efficient AI usage in corporate environments.
What I Bring to This
The professional experience gives me the observations. Twenty years of watching systems fail, watching teams drift toward incidents, watching automation create new problems while solving old ones. I've seen every pattern these articles describe play out in production environments long before AI entered the picture.
The graduate work gives me the frameworks. Human factors as a discipline has studied automation's effects on human performance since the 1980s. The findings transfer directly to AI-assisted development -- the mechanisms are the same, the domain is new.
The synthesis -- connecting those frameworks to the specific context of writing software with AI -- is mine. Where the literature supports a claim, I cite it. Where I'm extending beyond what's been formally studied, the text says so.
How I Work
I think rhizomatically -- lateral connections across domains rather than strict hierarchies. A pattern from aviation safety maps onto a software incident. A finding from memory research explains why AI-generated code feels understood but isn't retained. These connections aren't forced; they emerge from working in both spaces simultaneously.
I also have aphantasia -- I can't generate visual mental imagery. I encode through semantics and procedural memory rather than pictures. This makes me skeptical of a lot of cognitive research, because most of it is done under assumed conditions of "normalcy" -- whatever that means -- and not everyone is normal. Aphantasia research is still very new, but so far it's found that while we retain the same accuracy of imagery with far fewer details, we also produce far fewer false memories. There's likely extrapolation to be done with other cognitive concepts, but more research is required. My brain clearly works differently and yet I function just the same. That makes me cautious about any paper that pins an effect to a single mechanism without neuroscience or better control of variables we're just starting to consider.
The point is that I start from observations of my own experience -- personal and professional -- and then seek to explain them through science, which often requires multiple papers rather than a single one. Sometimes my observations contain incorrect assumptions or unrecognized biases, and I actively seek to disconfirm those too. I don't look for papers that support what I think is happening -- what I think is just the starting point for the research. I look for papers that explain what's actually happening. Some of them have already changed the way I think.