Not Everything Is Shiny and Chrome
I strive to write code that’s “good”. Aside from the obvious rules of not having bugs and being performant I also mean fitting style standards, efficient, compact, easy to understand later, and with as strong of a separation of concerns as I can enforce.
Sometimes outside concerns get in the way of that, and I had a run of discussions with members on my team that involved discussing why limitations from outside code meant having to break those rules, and how to do it in the cleanest way possible.
The other important thing to remember when writing non-obvious code, especially code that is against the grain of how things are done normally, is to add good documentation in the code so that the thought process and reasons why things are strange is very obvious to new eyes, or old eyes that haven’t worked on the code recently.