You've put most of my thoughts into words more eloquently than I would have :) If I'd add another point, I'd say that many skills of a good programmer don't ne

You've put most of my thoughts into words more eloquently than I would have :) If I'd add another point, I'd say that many skills of a good programmer don't necessarily relate to programming itself -- even still on the technical side. > And realize that all programming is essentially an exercise in complexity management. I think this gives us a hint at this. If we're building more and more complex systems to solve problems (and that's what our job is, not producing compiling code!), there's also tremendous value in reasoning and extrapolation skills that allow us to "mentally leap into the future". In his first session of "Beyond the Goal", E. Goldratt elaborates on four questions he insists one must ask about new technologies: - What is its main power? - What limitation does it diminish? - What are the old rules that accomodate that limitation (and should thus be abolished)? - What should we do instead? Along those lines, often we're given a problem and an existing system; and the best thing to do is just to identify why there is a problem (the limitation) and what (ideally simple) steps we can take to get rid of it. So less thinking along the lines of "add another form/button/algorithm/yaml file" and more "hang on, this problem just goes away if I correct some preconceived notion we just inherited without introspection". Edit: I have encountered situations where the last bit resulted in me mostly getting rid of code (and complexity) instead of adding more to a project.