The college knowledge isn't wasted - you just need to reframe how you use it.

Best practices like clean architecture exist to solve specific problems: making code easier to test, change, and reason about at scale. The key insight is understanding which problems they solve and when those problems actually matter.

A domain layer that depends on infrastructure might be "wrong" by the textbook, but if it's a small internal tool with 3 users and a 2-year expected lifespan, the coupling probably doesn't matter. The cost of the "correct" abstraction exceeds the benefit.

What I'd suggest: when you see code that violates a pattern you learned, ask yourself "what problem would the 'correct' approach solve here, and does that problem actually exist in this context?" Sometimes the answer is "yes, and this code will bite us later." Often it's "no, the simpler approach is fine for this use case."

The ability to make that judgment - knowing when to apply rigor and when simplicity wins - is what separates effective senior devs from people who cargo-cult patterns regardless of context.