IMO this attitude comes from people that have horrible, soul sucking jobs, combined with piss-poor time management skills. If you're basically typing web forms all day, go out and get a more challenging job, or start your own.

Here's the thing. A concert musician (cellist/pianist/whatever), will practice at most 6 hours per day. Most only practice a few hours per day. at the highest levels

People say program more because you learn more, but that's a smokescreen. 8 hours per day is plenty. Progress is NOT linear. It's logarithmic: enter image description here

The only reason that a musician might practice longer than 3 hours, is that they need to squeeze out the extra 1% that those hours gives them. If you think that applies to you, re-solving a problem CS solved 2 decades ago, then you have a prima-donna complex to boot.

I've worked in pressure cooker companies before, and trust me, the actual amount of work that those guys get done isn't any better than a company like 37signals that places constraints on the amount of work: 37signals.com/svn/posts/996-why-i-love-work..

What ends up happening is that sure, you may be in front of a computer for 10-12 hours, and in the office for 2 more, but that doesn't include the 90 minute lunch you took, the 2 hours you spent browsing discussion forums, and the hour break you had to play one of the many games laid out in the office (foosball, pool, yada...).

Look back at that graph. Now back to me.

Your mind actually has the opportunity to expand much more if you engage it in some other activity: Learn to play an instrument. Learn a foreign language. Better yet get out and get some exercise, and connect with real live people. On the logarithmic nature of productivity:

In the renowned 1993 study of young violinists, performance researcher Anders Ericsson found that the best ones all practiced the same way: in the morning, in three increments of no more than 90 minutes each, with a break between each one. Ericcson found the same pattern among other musicians, athletes, chess players and writers.

For Real Productivity, Less is Truly More

This is actually a well-known principle in the business world, I'm surprised more programmers haven't heard of it. Update: More on the Ericsson study.

The whole notion of it taking 10,000 hours / 10 years to become proficient actually comes from the studies done by Ericsson, not from Malcom Gladwell.

As we all know, you can have 1 year of experience repeated 10 times... so just having your ass in the seat for 10 years doesn't qualify. What does qualify is what Ericsson calls deliberate practice.

He has found this principle to hold true in athletics, music, writing, chess, and mathematics. He further defines deliberate practice as being so effortful, that even at the highest levels you can only put forth about 4 hours per day. Otherwise you will suffer from overtraining or burnout. Again, he recognizes that there are diminishing returns for deliberate practice, up to about 4 hours. On the subject of not having a good/challenging job:

Hogwash. Either get a better job, or here's an idea: Make your current job into something it's not, at least right now.

One of the best programmers I knew walked into a job as a maintenance programmer on a legacy system that consisted of dozens of programs and hundreds of thousands of lines of code. Most of which had been hacked on over the years so much that you would have to say there wasn't any coherent design to it anymore.

This was pretty much a go-nowhere, dead-end job. Management wanted you to keep your head down, and just fix the damn bugs. The good developers were working on the greenfield project. People either came here to sit out their remaining days until they retired, or gain a few years of experience before going on to new application development. Whereas most programmers would complain about the lack of career development, or the opportunity to learn new things, or not having exciting projects to work on, or more generally just bitching about no one enabling them, this guy simply sat down, and went about doing the work that needed to be done.

And over the course of 2 years, he had transformed that system from a buggy hell of spaghetti code to something that was a thing of beauty and functioned like a swiss watch. So complete was the transformation, that the VP of the division started paying more & more attention to the existing project, and started questioning the value of the greenfield project. Although he didn't have a title, the operations people went to him as the de-facto leader of the group. When I left, the VP was talking about creating a new role for him as a systems architect...

I'm not sure what happened to him after that, but he taught me a couple of very important lessons:

Your job is what you make it, and there's interesting problems to be solved everywhere. If you hate writing CRUD screens, solve the problem by automatically generating them.

Don't sit around waiting for opportunities to come to you. Chances are they never will.