| > A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant. Sometimes, your new paradigm is actually something that they tried 10 years ago. > In the end, you can sum up all rules into one: Make it easy to maintain That is only one of the many facets of programming that you have to balance: performance, memory consumption, ... . If you want to push your system performance to the extreme, believe me, "easy to maintain" is not going to happen. But that is the trade-off that you will have to make at that point. Veterans know that everything is a trade-off. Let me give you one extreme: you are writing a throw away prototype. How much time and effort are you going to spend (=waste) on making your code easy to maintain? I'll give you my veteran answer: - If you are in 100% control of the project, you know you will throw away the prototype, and you can throw things quickly together. - If you have a manager, he will take 1 look at the prototype and say "Wow, it's almost complete! Don't start a new project, just add these features to your prototype and it's done.". So in that case, make the "throw away prototype" easy to maintain. That is what veterans bring to the table: making trade-offs in specific situations. And they've been through a lot of situations. |
I think code based performance is something that is just not as big as an issue as before. In web world it's common to solve extreme performance via cache, replication, etc.
In any case, I think that in very few cases you get to a performance requirement so intense that you can't write maintainable code. We can't argue on extremes :)