"Hard problems" are risky business ventures. In my career, we've done a couple of things that would be considered "hard", but in each case we've leaned heavily

"Hard problems" are risky business ventures. In my career, we've done a couple of things that would be considered "hard", but in each case we've leaned heavily on papers published in academia. The best example might be when the team I was on did shape recognition from hand drawn shapes to shape objects in a drawing application. I've occasionally been asked to solve some hairy caching/concurrency problems, but again I've gone straight to the literature. My brother worked in a company that was doing circuit board design (simulating crosstalk, etc). Their work was highly theoretical, but they had electrical engineers doing the research (and were actively collaborating with a university). His job was 99% implementing code. I feel that programming is more about handling complexity than it is about solving other problems. You sometimes dip your toes into solving problems in other domains, but the biggest value you can give as a programmer is in creating a code base that is both simple and sustainable (and keeping it that way). This is the hardest problem I've ever worked on by far. It dwarfs any of the other problems I've tried to solve. I sometimes get a bit depressed that others don't consider it a "hard" (and therefore interesting) problem.