My first thought when reading your comment was "How could you possibly fit everything there is to learn into 4 hours a day?", but I think the disconnect is in two different conceptions of what a job is -
For most people, a job is something where you are hired to do a specific task for a specific wage, using specific skills that you learn once and then apply many times. "Make this button green." "Move the navbar 20px to the right." "When this button is clicked, send off an RPC to the server, and when it's complete, update the table with the relevant data."
These types of tasks lend themselves well to an "instruction manual" approach to skill acquisition: you read the manual, you apply it to your job, you memorize the parts that you use frequently, and you're done. Once you know everything in the manual, there's little point in studying further, because you know everything in the manual.
A smaller (but growing) minority of jobs require you to solve a vaguely-defined problem, where there is no manual because nobody's solved it before, and often times the problem hasn't even been posed in a tangible form. "Find out who wrote everything on the web." "Evaluate whether we should invest $5M into this venture capital fund." "Identify our next billion-dollar business." "Make cryptocurrency useful."
These jobs lend themselves to a "toolbox" approach. There is no manual, but if you have a wide enough breadth of experience, you've picked up a large variety of tools that you might be able to apply to the problem. So if you're tasked with figuring out who wrote what on the web, one approach might be ask the authors by having them add HTML markup, and then parsing and following that. Another approach might be to identify author bylines through machine-learning and then cross-reference them with a database of peoples' names that appear on the web. A third approach might be to identify pictures next to the byline and run facial recognition on them. You don't know which approach will be most useful until you're given the problem and actually try a few, but the bigger your toolbox, the more likely you are to find one that works.
The financial returns to these types of jobs tend to scale exponentially with their complexity, because the number of people who can solve them decreases exponentially. That's why it's beneficial to have as big a toolbox as you possibly can if you want to play in these markets.
I have never been the former, so I don't know how it works. That type of developer clearly must exist somewhere, because I hear people on HN talk about it, but I have always been a "hey, we have this interesting problem to solve, can you help" type of software developer. And yet, I have managed to stay quite good at this even without dedicating four hours of non-work time to it. To each their own.
I've done both of these types of jobs and I definitely feel different about them.
An example is if you work in any service industry. You don't have to think much, you just do when things need to be done. There's a lot of repetition so you just do without thinking. Or in an office job there's generally a set of tasks that you get done and this very clear path of how to do these things. I do think more time generally leads to more output for these jobs (maybe not in service if we're adding more time into the times of day when there isn't a demand for service, but I think everyone gets the point).
In my last job I worked as a researcher and I'm now in grad school. I feel like for the most part I accomplish way more when I'm not tied to a clock (I still like deadlines and think they are beneficial). But some days are just worthless. Some days 10hrs is nothing and I've forgotten to eat. But most days I'm productive in the morning then do other things mid day, be productive again, hang out with friends, then do research at night. These breaks help me end up getting a lot done. The problem I'm working on is far away (though I'm positive some part of my mind is working on it in the background). But as soon as I'm tied to a clock I feel like I get less done. In those moments where I'm drained I end up just looking busy or do something like browse HN. The thing is that these actions don't allow me to recover, so it's harder to get back to work and be as productive as I was in the morning.
I think that's the trick here. Recovery. In mentally demanding jobs we don't consider rest. It'd be like working heavy duty construction all day every day. It's not sustainable. Or asking pro athletes to train at their max every day. Recovery is an essential part of training and being effective. I think you can train to get more hours of productivity in a day, but as long as we don't actually rest that will never happen because we don't recover.
But idk. Do others feel this way? Often I feel like many don't, but maybe people are just looking busy and we're caught in a feedback loop.
Excellent point. I would also like to point out that the instruction manual jobs that you mentioned are being automated away and the pace of automation over this type of job is likely to increase.
For most people, a job is something where you are hired to do a specific task for a specific wage, using specific skills that you learn once and then apply many times. "Make this button green." "Move the navbar 20px to the right." "When this button is clicked, send off an RPC to the server, and when it's complete, update the table with the relevant data."
These types of tasks lend themselves well to an "instruction manual" approach to skill acquisition: you read the manual, you apply it to your job, you memorize the parts that you use frequently, and you're done. Once you know everything in the manual, there's little point in studying further, because you know everything in the manual.
A smaller (but growing) minority of jobs require you to solve a vaguely-defined problem, where there is no manual because nobody's solved it before, and often times the problem hasn't even been posed in a tangible form. "Find out who wrote everything on the web." "Evaluate whether we should invest $5M into this venture capital fund." "Identify our next billion-dollar business." "Make cryptocurrency useful."
These jobs lend themselves to a "toolbox" approach. There is no manual, but if you have a wide enough breadth of experience, you've picked up a large variety of tools that you might be able to apply to the problem. So if you're tasked with figuring out who wrote what on the web, one approach might be ask the authors by having them add HTML markup, and then parsing and following that. Another approach might be to identify author bylines through machine-learning and then cross-reference them with a database of peoples' names that appear on the web. A third approach might be to identify pictures next to the byline and run facial recognition on them. You don't know which approach will be most useful until you're given the problem and actually try a few, but the bigger your toolbox, the more likely you are to find one that works.
The financial returns to these types of jobs tend to scale exponentially with their complexity, because the number of people who can solve them decreases exponentially. That's why it's beneficial to have as big a toolbox as you possibly can if you want to play in these markets.