Except that it's often more like 80 minutes vs. 80 hours, or the inexperienced---although it's more often the less ... skilled---simply can't solve the problem at all. In my other comment I mentioned debugging; my ability to recognize the ... pattern/smell/whatever of a bug will often let me heuristically narrow the search to an amazing degree. What once would take me hours or days became minutes.
But just as it's unbecoming to boast about what you are not, one needs to recognize what one is and can do to arrange that things work out best, at least in startups where that vs. e.g. politics determines personal and project/corporate success. The flip side of the theme of the 2nd Dirty Harry movie, "A man's got to know his own limitations."
Plus I think I'm allowed to be proud of what I've accomplished over decades of hard work. I started with punched card FORTRAN "IV" on the IBM 1130 in high school in the fall of 1977 (scare quotes because it was closer to a FORTRAN II, e.g. no logical IFs), that prompted me to begin a lifelong independent study of software engineering (since I realized there had to be better ways to do this) and the cited level of skill in debugging nasty C programs was achieved by 1999, a full 22 years later. One would really hope one has learned a thing or two over a couple of decades.
This is true. So many managers see somebody doing such hard work, fixing so many bugs, that they think he must be the brightest engineer. They never think about the fact that the engineer must have created all those bugs in the first place.