My algorithms professor engrained an idea in me that has stuck throughout my career: first you make it work, then you make it better. When it comes to code, we

My algorithms professor engrained an idea in me that has stuck throughout my career: first you make it work, then you make it better. When it comes to code, we want an almost mathematically-provable correctness, but the real world doesn't care. The real world cares about getting something that solves their problem; ugliness, code smells, and technical dept are irrelevant to them. So I wouldn't write off the managers and their fancy business needs as just some conspiracy keeping good coders down. I think this need for pragmatism is something that separates a computer scientist from an engineer. It goes both ways though. Sometimes the shit is just terrible. When the cost of any change is introducing a new bug, you've got to take a stand and I think your insight is spot on here. The developer is in the best position to know when the cost of change has gotten to high. I don't bother asking permission, but I've never had to ask forgiveness either. The manager is my customer: he just cares that what comes out of me works, and because I stop to clean up, it does.