5 ms·

A supporting example from another field: Back in the days of 20th century ambitious, well-funded journalism, it was common to see specialized writers do their

by GCA10 7y ago

A supporting example from another field: 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.

cosmodisk 7y ago
I've seen so many examples,where people,who spent decades in their fields become so cynical and 'know it all' type. This is almost universal across all fields.Fresh minds are always a good idea.
- bsder 7y ago
  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.
  - raspartame 7y ago
    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 :)
    - bsder 7y ago
      > I've personally been the junior who tried to solve the halting problem :) I think we all have at some point. :) Those of us who had some experienced people around simply found out sooner rather than later.
  - quelltext 7y ago
    > 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?
    - bsder 7y ago
      > > 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.

by GCA10 7y ago

cosmodisk 7y ago

I've seen so many examples,where people,who spent decades in their fields become so cynical and 'know it all' type. This is almost universal across all fields.Fresh minds are always a good idea.

bsder 7y ago
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.
- raspartame 7y ago
  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 :)
  - bsder 7y ago
    > I've personally been the junior who tried to solve the halting problem :) I think we all have at some point. :) Those of us who had some experienced people around simply found out sooner rather than later.
- quelltext 7y ago
  > 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?
  - bsder 7y ago
    > > 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.