I think you've got some great advice here, and "recursively learning" is a good way to explain it.
In open source, especially, this is such a good strategy to follow. It's why Linux is fun :)
I don't know how you apply your philosophy to employment though. At work, I pretty much do the opposite of what you're suggesting to avoid my 9 to 5 becoming hell. I focus only on the end goal, where that goal is employer satisfaction.
Here are some pragmatic tips for how to achieve satisfaction for all parties in employment:
* Maximally pad estimates. Don't know how long something will take? Tell your team that you need some time to figure out how long a project will take. Use this time to get to an 80% solution, or at least have a very solid plan. Now that you understand the problem but your employer doesn't, you're in a much stronger position to provide good support for your heavily padded estimate. If a manager pushes back, you have lots of info already and can speak with confidence. Compromise as appropriate and be friendly about it, but remember that every hour you can pad is another hour you've reclaimed. This is by far the most important thing. The ratio I look for is 40 hours of estimated work to 8 hours of heads-down problem-solving.
* If you can't figure out the solution to a problem in a couple of hours, break the problem into parts. Only give estimates on the parts you've already solved. Managers are happy to see multiple tickets for what you might think of as one task, because it gives them the appearance of their team achieving more.
* In agile, you should try to stay at least one sprint ahead. Your team will appreciate you being proactive if you're always looking at what's coming up next sprint.
* Save your teammates from themselves. Look at their estimates before sprint meetings, try to come up with a few things they maybe didn't think of, and ask "are you sure that's enough time? what about x, y, and z?". You want to both pad your estimates and help your coworkers and managers pad their estimates as well. I believe the #1 reason for underestimating is not putting in enough time to come up with good reasons why something may take a long time.
* Keep good notes. Always be ready to give an update on what you did on any particular day. I write bullet point notes every day in a personal wiki, and I use them as talking points in standup the following day. Share some of these notes (re-phrased as a friendly update) a few times a week with management via text. If you think someone's nervous, take a little extra time to give them an update so they feel in control.
* Make sure you have one "no meetings" day where you can go heads-down with a stimulant of your choice. Complete all of your obligations for the sprint on that day, but keep them stored on your local machine so you can roll them out as you like. Try to make sure that's your only real work day. The rest of the time should feel more like a social club if you're doing it correctly.
* For remote workers, always be on Slack. Use a script that prevents you from going idle, and set up your phone to get your messages. That shows that you're always online and available if someone needs you. Usually people won't bother you outside of core hours anyway. Respond quickly when contacted, even if it's just an acknowledgment that says you saw it and you'll get back to them.
* For office workers, spend as much time in the office as you can. Try to make it pleasant for yourself. Come in early and have breakfast while people show up. Eat lunch with the team, but take a little extra time for a personal phone call to catch up with a friend or handle some personal business. Late afternoon, a few days a week, try to get to the gym. Your goal is to be first in and last out, but without actually making any personal sacrifices to do it.
* Sometimes hold your commits until after work hours. Managers who pull these metrics from github are evaluating the completely wrong thing, but it doesn't hurt to give them what they want to see. You can use a shell script to sleep then commit/push/pr.
* Be friendly and helpful. A little extra attention goes a long way. Make notes about significant events in people's lives and reference them later to show you care, just like a CRM.
* If you see someone stressed and struggling, offer to jump into their problem with them and try to help them solve it. If you can help, great. If you can't, at least you tried, and maybe you added some value.
* If someone asks you for something or to do something, write it down and set a reminder. Never let a request go unanswered. Failure is often ok, but disregard is never ok.
If you follow my approach, you should be able to acquire goodwill with your team and a track record of dependability. You'll complete all of your work with minimal stress, make friends along the way, and present very well to management.
I still hate work, and I would rather do pretty much anything else with my time, but this is the most palatable strategy that I've come up with.
When I tried your approach, which again, I think is the correct way to actually learn and build anything, work was a daily struggle. Now that I do about 20% of the "work" (as I used to think of it) and spend 80% of my time managing relationships, I find myself in a much better situation.