The parent comment is not saying that B is working just two hours per day. Rather that B finished the task in two hours (and then likely moved on to do something else).

I have by the way directly witnessed such a huge A vs. B difference in software development. It was in fact two months to two hours ratio. And yet, the A team or the management did not realize this, or even accept this after the fact.

Well 2 hours compared to 2 months(Compared to original 2 week comparison) is an insane level of difference in quality and productivity. So huge that its either really true or some body is cheating or something is at a miss here.

I am not sure why such people even remain programmers all their life. If you can achieve in hours what people take months to achieve, you should be doing very special things. Chase some really big goals. Because after all by the same logic you can achieve in an year what many people may take many lifetimes to achieve.

Why are such people stuck doing some small time programming tasks.

I recall an analogy from Skiena [1], although this is not exactly what happened in my two-month to two-hour example. Skiena talks about a problem which appears to have exponential complexity at first, but then shows an insight that turns it into polynomial time. Consider the potential impact of this. Team Exp will be spending lots more time optimizing, debugging, writing test cases, while the team Poly will go though all of that much faster since the task is much easier now. Not just the running time is different, the development and maintenance time could be different by an order of magnitude too.

In the actual case, the team Months could not connect the dots to see that the specific problem at hand, that involved two complex things, somehow had a much simpler solution. Their code, development time, etc. looked perfectly normal from an outsider's point of view. The code was taking 40 minutes per run. I was unaware of their work and coded the same thing independently. My code was five lines core in Matlab plus overheads, or about hundred lines total. It also ran in two minutes.

In short, no one was cheating. Nothing was amiss. Just that I could connect the dots and they could not. Had I not worked on the problem, I would not have figured either.

The issue is that in the normal course of lives, two people or teams are not asked to work on the same problem in isolation. So the difference in performance does not become evident at least in the short run. This is in spite of the amount of duplication of effort that often exists.

Now this does not imply that I could do this for every task, though I do have more examples just as profound. I can often understand complex problems better and faster than other people, and then can work through them faster. But if both sides understand the problem+solution equally well, I may actually be slower in implementing at least in the initial rounds. (This is because my breadth of knowledge across technology domains is often five-ten times broader than normal engineers, which also implies that I have less practice in each domain).

And yes, I am chasing some really big goals.

[1] www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1848000693/

Just checked your profile. All the best for your Start up, do well. As with always its nice to know a fellow HN'er doing so well.

I've always thought it's the other way around. The success stories are about people who are ruthless about succeeding, who are unable to make a work/life balance because they are motivated to succeed at all costs. The crazy hours are a symptom of what makes them successful, but not the cause of it.