Productivity is a difficult thing to measure, because the units people use aren't consistent. I'm going to try to respond using the metric of productivity I've

Productivity is a difficult thing to measure, because the units people use aren't consistent. I'm going to try to respond using the metric of productivity I've become most comfortable with, which is quanta of robust functionality per unit time. By robust, I mean it is not fragile or rigid to future changes within both itself and dependencies. In this sense of productive, IDEs can be quite detrimental in careless hands. IDE can make developers more prolific, generating very quickly blocks of code that perform particular tasks, but I've also found that it can cultivate a more manufacturing method of coding, where developers just bounce on the '.' and tab keys and glue bits of 'sensed' method calls together. It makes development fast, and that means any productivity metric based on providing code meeting specified requirements is satisfied swiftly. It also means that the developer spends far less time thinking about individual blocks of code; this can have very deleterious effects. A single line might consist of 12 method calls strung together, because the developer didn't take the time to go back and assess things like readability. A particular method might calculate the incorrect result when passed data it wasn't originally designed for, rather that throwing an exception or gracefully degrading its functionality. A method or class definition might likewise make unreasonable assumptions about dependencies, requiring a large amount of rewriting; rewriting which could have been avoided if the developer had taken a few minutes to step back and examine the implications of their work, and how the design could change to make the code clearer and simpler. To be clear, I am not blaming IDEs for careless, fragile code. What I am saying is that IDEs can be a magnifier for carelessness, allowing a developer with a proclivity for banging out code as fast as possible without regard for quality to do so much faster. What time they spend reaching for the documentation for a particular class or framework would give their mind a chance to think about what they are working on, and possibly come up with a more long-term workable solution to what they are building. I'm not saying it's a panacea; I guess what I'm saying is that I'm not totally opposed to artificially slowing down developers who would otherwise write code faster than they can reason about it. I suppose the other solution is just to identify them as careless, and remove them from the project. I also worry about your dismissive stance toward the “core stuff of programming.” I’ve found it is this core stuff that makes for the simpliest, future-proof code, because the core stuff allows for reasoning about design, not just about functionality.