Coding dirty is a counterpoint to Clean Code. Carson Gross (htmx) on the three dirty principles:
Big functions can be good, actually. Important things should look important. When everything is small, nothing stands out. Large functions also keep related context together and improve debuggability. SQLite, Redis, for example, contain large functions.
When you split your functions into many equally sized, small implementations you end up smearing the important parts of your implementation around your module, even if they are expressed perfectly well in a larger function. Everything ends up looking the same: a function signature definition, followed by an if statement or a for loop, maybe a function call or two, and a return.
If you allow your important “crux” functions to be larger it is easier to pick them out from the sea of functions, they are obviously important: just look at them, they are big!
Integration over Unit tests. Sometimes it’s better to focus on crystallizing the API and on higher-level invariants that survive refactoring, rather than tying implementation down in unit tests.
Of course, you can and should refactor your tests as you change things, but the reality is that a large and growing test suite takes on its own mass and momentum in a project, especially as other engineers join, making changes more and more difficult as they are added. You end up creating things like test helpers, mocks, etc. for your testing code.
All that code and complexity tends over time to lock you in to a particular implementation.
Minimize Classes and Concepts Sometimes a god object that handles multiple concerns is better than juggling many single-purpose objects. Gross uses ActiveRecord as an example.