I know I've commented before on how, while Clean Code has its place, there are adherents who adhere to it so literally and unthinkingly that they've constrained their careers and condemned themselves to the same silos for the rest of their professional lives.

Alice laughed. "There's no use trying," she said. "One can't believe impossible things."

"I daresay you haven't had much practice," said the Queen. "When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast."

I've been working on a little side project, teaching myself how to make a SQL-backed application server in Rust. I tried doing TPP, The Transformation Priority Premise, but while working in a strongly typed language like Rust or Haskell, there are steps of the process that are simply impossible to express in those languages. Small functions that do one thing, and are properly annotated, cannot— literally cannot— express some of the stages of the transformation priority premise, and they have to be skipped over.

A "One True Way" clean coder would say that any language that forbids steps of the transformation priority premise isn't a good language to work in. I'm sorry, but if you think Rust and Haskell aren't good languages, but C++ and Java are, then we have a security and legacy management nightmare that will be with us for generations.

The same is true of SQL. I had a conversation with a recruiter who challenged me on the question of the kind of join I had just written, since I hadn't annotated it with either the "inner" or "outer" keyword. I said that it didn't matter; his database schema said that no relationships could be NULL, so the joins were technically full, and the notion of inner– or outer-keys wasn't relevant. "The default is inner," he said, a little irritated. Yes, I know, but that's not the point; this database's types are constrained so that those annotations didn't affect interpretation. Optional types aren't possible.

Just another thought.