Its very much the case that new engineers want to work on the hardest projects and prove that they are capable and deserve lots of money and/or responsibility. But management typically doesn't care if you completed 99% of the hardest project on the block if it doesn't yield a usable result (nor should they). Its generally better to solve a simpler problem well enough to at least claim success. The downside is that if everyone feels that way, the quality of the framework for future tasks is not robust and technical debt racks up. Without a sound framework, there isn't reliable infrastructure and navigating previously written tools can't be trusted by glancing at a method or package name. It turns a depth 1 BFS into an unbounded DFS and eventually it becomes extremely time consuming to get anything done. The problem gets compounded if there is a lengthy review process and the reviewer is safer doing nothing, letting the change languish until a manager pushes for it.