Both is a problem. It's just that, as a dev, you're less likely to see code with massive amounts of duplication because any mediocre developer understands why this is bad.
However, work with really bad (or just extremely inexperienced) devs and/or people who are not primarily coders (e.g. data scientists), and you'll see a lot of under-engineering to the point that it's almost impossible to figure out what the code is actually doing (especially when it's coupled with random code that is inserted without understanding, just because it makes things work somehow, at least on the dev's machine).
A half-baked thought: It's interesting though isn't it, that the "immature" approach is to try to be extra vigilant. You'd think an immature coder would just want to hammer things out quickly. I wonder if it's because they learned that lesson at some point (maybe in college) and are overcompensating, trying to be extra mature or something.
A lot of us were really immature, just-hammer-something-out coders in high school, maybe in college. Then we got a job, and now we had to be professional. So we went too far the other way, trying to be how we thought we were supposed to be, but without really knowing how yet.
(Shout out to Don Martini, who helped me more than he knew in my first job, as I was trying to grow into a professional programmer. Ditto Steve Hanka, who helped me in the same way on my second job. If either of you see this, thanks!)
Yeah, I think this is insightful and is common across many disciplines.
When starting out you do as much as you can, which is often very little, things are underdeveloped. You just don't have the tools and techniques to properly solve problems.
As you improve, you expand your set of tools and techniques and you tend you overuse them. This is part of the learning process but can result in things being overbuilt.
It's only with time, experience, and feedback that you learn the boundaries about what tools and techniques are most useful and appropriate.
I think the immature approach is to try and solve all problems, rather than just addressing the needs of the moment. Whilst it looks and sounds bad, delivering quickly and ontime creates the opportunity to fix things. Trying to deliver perfect products, ie finding and fixing all faults steals future time.
However, work with really bad (or just extremely inexperienced) devs and/or people who are not primarily coders (e.g. data scientists), and you'll see a lot of under-engineering to the point that it's almost impossible to figure out what the code is actually doing (especially when it's coupled with random code that is inserted without understanding, just because it makes things work somehow, at least on the dev's machine).