I have seen the reverse where so many junior engineers make soooooo many mistakes that are absolutely obvious to experienced engineers. That's why we review things.
I would also argue that programming advances so slowly for exactly this reason--we really don't respect the senior ones who know what they are doing.
In spite of what people think, programming isn't "new" anymore. A "know it all" programmer may be someone who has seen the wheel turn 3 or 4 times at this point. I would argue that programming hasn't really had a significant change since modern (read: assumes infinite memory and CPU) managed runtimes (Java, Python and Javascript).
Part of this is that the fastest way to a VC lottery winner is "social fad"--you want youngsters primarily because they are "plugged into the scene" and the programming is secondary. The number of times I have seen junior programmers try to solve the halting problem would make you weep.
I think we all have at some point. :)
Those of us who had some experienced people around simply found out sooner rather than later.
In what context?
What you describe is an example professors used during my education to motivate theoretical CS studies, i.e. you don't want to be THAT guy.
However, while this is true, I haven't yet seen many junior programmers on the job trying to solve the halting problem. I don't quite understand why that would be common. But maybe you are talking more about online communities and side projects?
> In what context?
The problem is that they don't recognize it as the "Halting Problem". It will be something like "Well, we can scan this thing to see if it does X or Y." No, actually you can't because "Doesn't terminate" is also an option. Oops. That's the Halting Problem.
In digital design, non-causal logic is a similar pitfall. Offline DSP algorithms can look backward and forward in time. If, however, you try to apply such a forward looking algorithm to a real-time system that needs an answer on the same time as the current sample, you wind up accidentally creating non-causal logic and wondering why your algorithm isn't working.
You may try removing whitespace, finding invariants, ordering the variables by type, converting for loops to while, tail call optimization, but your collegue always has a trick to make equivalent functions undetectable by your module. You were solving the halting problem. Instead, you should use CS knowledge and tell them it's impossible but they can have a non-optimal search. Perhaps, the fastest way to complete the task would be to score similarities between the functions' machine code or AST.
Back in the days of 20th century ambitious, well-funded journalism, it was common to see specialized writers do their boldest, most imaginative work in their first year on the beat.
They also made some newbie mistakes, but on their good days, they saw stuff that the old pros didn't. They asked the "obvious" questions that everyone else had stopped asking. They ventured into areas that according to conventional wisdom were "unimportant" or "not yet significant."
People who had been on the same beat for 10 years or more could reliably generate solid and perhaps even admired work in their specialties. But they worked within shrinking boundaries.
The senior editors who really earned their keep made sure that the rest of us kept rotating into new fields every few years, so that the "wow!" factor never left our work.