There's so much good advice in this article. My number one point that i learned the hard way during two decades of writing software: take breaks when your body tells you to. It's an absolute killer if you force yourself to work on your projects just because there's stuff on your to do list, new issues on Github, or whatever. Just stop working if you don't feel it.
There’s no golden rule. For me, both work and learning out of curiosity is stress inducing activity. Nail biting, valsalva breathing, skin rashes etc.
I just grind through it and repeat the days.
I would do only aimless activities if I relied on the feels.
This kind of negative emotional investment seems to be the only thing that improves my abilities. If I’m learning through Anki or playing tunes on the piano, habit can stop after 6 months of regular daily practice.
But if I’m on the brink of stress rage frustration, somehow it persists .
I feel like that's great advice for people working on their own side projects.
But... I'm employed? I mean surely it translates to "go on vacation" but it's pretty useless advice for days where you simply have to work and can't just... not?
I don't think it needs to translate to "go on vacation". During my time being employed, this translated into getting up and stretching, taking a few minutes to look out the window, going for a short walk, taking an intentional breath, sitting and meditating for 15 minutes, actually eating lunch away from my computer, or not eating lunch and going for a quick run or doing yoga or going to the gym.
This can come forth in so many ways.
Moment by moment we can have an eye on our body and what it is asking for, I've found it to not only make me more productive, but also led to my baseline of stress to being way, way lower then everyone around me which is contagious in a positive way.
I take your point as I'm retired. But I had my previous working life squarely in mind when writing the post.
"Sustainable pace" helps, which in my case came down to 37 hour working weeks, not working at weekends, and taking all my vacation (and some extra when my employer let me buy it). I know this might sound like madness to Americans, but as a Brit employed mostly by American companies, it worked fine for me.
I found that taking plenty of breaks during the working day helped. Coffee breaks with colleagues, a decent lunch break (ideally including exercise), and plenty of tea breaks. So many times I've had a good idea or solved a problem during a break, so they are actually productive.
Then there's finding other useful things to do which aren't as taxing as the thing that's blocking you (e.g. the next large feature). Fixing bugs, writing docs, and doing preparatory investigations about the upcoming work are all productive ways to give yourself a bit of a mental break. (This was hardest when working in teams with continual short sprints or doing XP and pairing, but if I allowed myself to start to burn out, my productivity started to decline - essentially my brain was forcing me to take things a little more slowly in order to recover.)
There’s so much good advice in the article and I think most developers know these intuitively to a certain extent. The problem with it though is that corporate culture tends to ignore these and is very unforgiving in my experience. When you have to deliver everything on time, all the time, you can’t take any of this advice and practically use it. Taking time with learning for example is something you can do only when your manager allows it, your peers (technical and non technical) won’t take any issue with it and the price of taking time isn’t going to be a negative performance review.