It depends on your field. Engineering is a good counterexample.
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 don't disagree with this, but I do feel like there is some benefit to movement within different niches of engineering. I've been on teams where someone who, while being an experienced engineer, was new to the stack or hadn't worked on a project like ours, and they brought new ideas/technologies to the table simply because they were so excited to look for them—i.e. the "Wow!" factor of stepping into a new space. To agree with you, however, I've only ever seen this among engineers who had a strong general base. I've personally been the junior who tried to solve the halting problem :)
> The number of times I have seen junior programmers try to solve the halting problem would make you weep.
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?
> > The number of times I have seen junior programmers try to solve the halting problem would make you weep.
> 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.
The example problem is unclear. Could you please describe more on it. Which DSP algorithm falls under the Halting Problem and is there any database or general programming related problem that falls under "Halting Problem" ?
Suppose your company is developing a framework for creating mobile apps. You work on optimizing the GUI renderer and you are assigned a task to make a module which finds computationally equivalent render functions (or a company making a programming assignment plagiarism system, or a duplicate config file detector when the config language is accidentally Turing-Complete).
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.
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.