glynnormington

That's hard. My only advice when working in a stifling, corporate environment is to find out what your education budget is and then use it for the kind of learning I was referring to in the article. (If you don't have an education budget, that's one more reason to start planning a job move...)

I try to think in terms of owing the dependency a contribution as a small payment for using it, and this bugs me until I do it. But, sure, better to contribute docs sooner rather than not at all.

(One advantage of deferring is that the contribution may be better quality when I've had more experience of using the dependency.)

Fair point. I often copy stuff across from one project to the next. But this point is most relevant when I'm using another language etc. for the first time and I'm tempted to try to retrofit all my previous best practices.

For example, I used to work on a mainframe product that dumped the address space to disk on a crash. Then it was possible to build all sorts of fancy tooling to analyse the dump. When I moved to a different platform, without those kinds of dumps, it was tempting to try to reinvent all this stuff, but it would have been a massive time sink (and would have failed too).

If there's a definite performance problem and a simple solution, then sure, go ahead. But applying every optimisation that comes to mind can produce a dog's breakfast of unmaintainable code and then when a real performance problem comes along, it can be really hard to fix.

Nice - thanks.

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.)

I like that. There are other ways of capturing work in progress adjacent to the code, instead of writing a journal. One of my favourites is to write a failing test - pretty much impossible to overlook or misunderstand on "re-entry" to the task.

Another is to write a temporary commit log, with "WIP" in the first line and a TODO list in the rest of the log. This is good for ephemeral information that would just clutter up the code.

If I do need something like a journal, I have occasionally just written a private gist and put that in a tab on my browser.