Yes, I'm very aware of how it generally comes to pass that companies ask for heroic efforts from individual employees. However there is a feedback loop here. A company that pushes employees to heroic efforts has something broken about their estimation process. But conversely if employees really don't know whether they can do what they try to do, then I guarantee that they will regularly fail. Which will lead to a lot of uncertainty and make accurate estimation impossible. And to complete the scenario, most people burn out fairly quickly from heroics. (Programmers are particularly likely to be demotivated by pressure to be heroic.) Which means that if you're requiring heroics, then you'll quickly wind up with a burned out team and all ofthe attending problems that come with that as well.
In short heroics are both a cause and effect of organizational problems. Which makes heroics a red flag to watch out for.
Going to your made up example, obviously your "bad" problem is bad. But your "good" problem is also bad. If the whole spec was "speed it up by 10%", that's a bad project to commit someone to. Perhaps it can't be sped up by 10% at all. Or perhaps it can but that programmer won't be the one to do it. Or perhaps it can be sped up in 20 minutes after you realize that it isn't using an index. A far better project would be, "Spend up to a week studing how to speed up search." Another good project would be, "Spend a week to do change X that we think would speed up search by 10%".
Why are those versions better? Well first, with both it is fairly easy to figure out where to start. Second, both make demands on programmer effort that are estimatable up front so that programmers can give you feedback on whether your demands are reasonable. Thirdly other people can be given clear messages about when to expect improvements that they need.
About whether I understand you, I am quite certain that I don't. You are throwing around the word "accomplishment", but I don't know when you feel a sense of accomplishment in doing something, and when you don't. And I'm painfully aware that different people feel a sense of accomplishment about very different things. (BTW there is a certain irony that you'd respond to a post titled, Well, what do YOU mean by accomplishment? with a response where you say, assuming you understand what I mean by accomplishment... Um, in fact I probably don't...)
About reporting. You might find reporting (at least as it is for my job) more interesting than you think. People often ask for reports that are not going to happen in a reasonable time frame, I have to explain that to them. People often ask for reports that won't actually solve the question that they want to solve, and I often have to work with them to define a report that does. People often ask for a report without realizing that someone they don't work closely with already has the answers they want, and I get to hook them up. And given that I'm in so many discussions, I often wind up pointing out, "You know, it wouldn't be hard for me to give you numbers for _____, which would probably help you a lot." Plus a large fraction of the questions that people want to answer are of the form, "Why do the numbers look like ____?" Which puts me close to business problems in discussion with people whose responsibility is to address those problems. If I have any ideas about why that happened or what to do about them, they are all ears.
There is a lot more to the job than just producing reports that someone else has specified.
Cheers,
Ben
PS FYI, I recognized the author's name when I saw the article. That was part of why I stopped on that article, even though I'm not a big fan of CMM.