I'd disagree, except that so much of this depends on how you define "learning to code". Digging into someone else's code base to understand it well enough to f

I'd disagree, except that so much of this depends on how you define "learning to code". Digging into someone else's code base to understand it well enough to fix bugs and add features without introducing unintended side-effects is, at least for me, quite a challenge. It takes a tremendous amount of persistence, the ability to build a mental blueprint containing substantial amounts of logic, and - most importantly - the ability to swap into the mindset of whoever wrote the app, rather than the way you would have written it. You know, a lot of us have studied tough things - I was a pure math major and I was a PhD student for a while in a very math-ish engineering department at Berkeley where most of the day was spend on proofs about stochastic systems or convexity. This sort of background isn't unusual here on HN, yet many of us would say that while code itself contains a wide range of challenges and difficulties, the field absolutely has monumental challenges that will push very smart people as far as they can go, maybe farther. I once (about 15 years ago) got rebuked (gently) by a researcher at Sun Labs once when I dismissed a potential project as "easy." A museum was looking for someone to help build a search engine for their art collection. I said "a db search across some metadata, that's not a huge challenge." The researcher replied, with a mild smirk, "oh, I didn't realize you'd already solved all the issues in image search." So then I backpedalled a bit and talked about the specs the museum had mentioned, "oh, well, they're just looking for search on some metadata". He replied, "well, maybe that's the only way they understand the problem, but you don't need to accept those limits".