His essay here touches lightly on a pattern I've noticed among people who work in large corporations: they fall into the habit of asking for permission and guidance too often.

It doesn't make any sense to complain about inept suggestions or withheld permission when the problem could have been solved or a critical decision could have been made without blessing from above. Invariably though, if you ask for permission, now you really do need it.

Many of the greatest projects that have ever come out of large corporations happened because the innovators didn't ask or wait for permission (e.g. Unix).

"It doesn't make any sense to complain about inept suggestions or withheld permission when the problem could have been solved or a critical decision could have been made without blessing from above."

The trouble is, if you try to solve a problem you weren't asked (told) to, or use new and 'unapproved' methods, and anything goes even slightly wrong, you'll be in serious trouble.

If you do what you're told and use the 'approved' methods, your job will be safe in the short term - no matter how unsatisfactory the end result.

"Many of the greatest projects that have ever come out of large corporations happened because the innovators didn't ask or wait for permission (e.g. Unix)."

Longer term, yes, I think you're right.

I think it's worse to be stuck with responsibility for a codebase that you have no real authority over.

You can't live in fear of that kind of stuff. Who's the fricking expert on software development? Not the managers. If you focus on meeting everyone's needs lower down on the food chain-- and invest in tools in techniques that multiply your ability to maintain and extend the code-- then your development will be so tight and your response to issues will be so comprehensive that the "play it safe" types will have nothing they can say to you. (Except maybe that they'd rather have more buttons or something.) If you're a responisible developer, you'll be addressing the "slightly wrong" stuff well before the middle managers even hear about it. You'll have a relationship with the real value-adders such that they talk to you instead of your bosses. You, after all, are the one that gets stuff done quietly and thoroughly.

Sheesh. They're "play it safe" types. Think about it. Once the code is up and running, they're not going to be to be suggesting any changes. Suddenly you're the status quo and they'll defend your work by saying "if it ain't broke don't fix it" just like they said about the previous solution.