I think our failure, as a profession, to recognize and accept different ways to solve problems holds us back. Programmers almost always dismiss legacy code and

I think our failure, as a profession, to recognize and accept different ways to solve problems holds us back. Programmers almost always dismiss legacy code and anything they didn't write as crap, even if it works and adds business value. There's always a better language, toolkit, paradigm that the original developers should have used. We're good at pointing at mistakes and speculating on how we could have done it so much better, but not very good at honestly studying and learning from someone else's code. Programmers who carry around the idea that they alone know how to write the first ever perfect piece of software, if only everyone would listen to them, cause more damage than the people cranking out working but imperfect code. The perfect is the enemy of the good, but we never seem to learn that. I see this play out in my own work -- I specialize in legacy and abandoned applications. I'm often told by my customer that several developers looked at the code before me and declared it crap, unmaintainable, have to start over with (fad of the month) language. Yet the code works and has been maintained and enhanced for years or even decades (the opposite of unmaintainable). Ugly, yes. Requiring some commitment and study, yes. But not so terrible that starting over from scratch (which almost never works out as predicted) is a good business proposition. Call it hubris, call it fleecing unsophisticated customers, but this attitude just keeps software development reinventing the flat tire in different languages, to paraphrase Alan Kay.