I would flip that question around: how are we supposed to learn anything when we're supposed to get so much work done?
Think of programming as an iceberg. The tip is the visible part, and it's just 10% of the iceberg. The invisible part is 90%.
Actually shipping code that delivers features is just the visible part of programming. If managers focus too much on only that visible part, you end up producing a lot of code. And actually, code is a liability, not an asset. Think about it: if I give two options, project A is 100 lines of code and delivers a tetris game, and project B is 10k lines of code and delivers the exact same thing, which would you pick? Or: if you ask me where do I live, do you prefer "Foobar Avenue, 123", or do you prefer a 15 page document explaining each single step how to get there?
I think coding is an activity that constantly requires taking a break and rethinking the strategy. Of course there is a lot of "just getting things done" involved, but we shouldn't think that it's just that. Programming is learning. It's learning how to solve the problem at hand while optimizing user/customer experience (through various metrics such as lack of bugs, speed of feature delivery, performance, etc).