You also have people who do 40 hours of work in 20 hours and spend the other 20 learning. They satisfy the requirements of both (a) and (b). And they may very well have the advantages of both.
Great point! I think this is what happens. I've seen this person, and sometimes, I've been this person.
The employer/client often knows that some of the work this type of person does doesn't directly pay immediate tangible benefits. Sometimes they're even frustrated by it. But, on the other hand, the programmer is just so damn good that they have to put up with it.
Overall, the boss who doesn't understand this principle of "deep work" feels frustrated, but still has to acknowledge that these deep workers are his most effective producers. So the boss ends up feeling he has to "take the good with the bad," almost like you'd feel about a great painter who is a prima donna or something. (But in this case, the "prima donna-ness" is not due to a character defect, but rather, the underlying nature of software development).
At a large corporation, it's generally a good idea to avoid letting your boss know how much free time you have. The problem is that if you volunteer your extra time, you'll end up doing 80 hours of work in 40 hours. This is not nearly as beneficial to your career as spending the 20 hours developing deep skills.
I'm not saying lie. If your boss has something that needs to be done and asks you to do it, then get it done. But don't volunteer for extra work.
The times that I have been the person getting 40 hours worth of work done in 20 hours, I was using the other 20 hours to rewrite things with a different approach ... in other words, the "deep work" that the business didn't see a need for.
I knew that the deep work was why I could get 40 hours worth done in 20 hours, so I made sure I did the deep work. That, of course, put me behind in my directly assigned (non-deep-work) tasks. However, the deep work paid off in more powerful ways (more powerful abstractions, allowing me to find solutions to problems we thought we would be unable to solve, discovering real problems that we didn't yet know we had, etc.), and ultimately made it possible for me get my tasks done in the other 20 hours (or, to deliver something else of enough value that they decided my original tasks didn't matter).
It's not nearly as neat as "40 hours worth in 20 hours", and it certainly didn't lead to a bunch of free time sitting on my hands. It was just a case of knowing the deep work was necessary, even if those assigning me work didn't, and doing that deep work anyway, and having things work out well because the deep work really was necessary and powerful.
And I think that happens a lot with good developers in the "enterprise" software world.
