It is an interesting question which, in my opinion, hinges entirely on a fairly puritanical notion of 'work.'
One of my 'problems' is that I can't "not work" in the sense of a laborer who is no longer building widgets. As a person who is asked to solve complex problems with a high degree of dimensionality inside of an arbitrarily constrained solution space, much of the 'work' I do consists of turning the problem over and over in my head while I explore the solution space.
A good example of this was an early review I got at Intel by my manager (a really solid EE type guy). He added some criticism of my time management (considered a 'ding' in the vernacular) for a embedded compiler/assembler/driver thing I wrote as part of the evaluation of a graphics processor. He said I had 'sand bagged' the time estimate.
When I asked him to describe that a bit more he explained that I had told him it would take 6 months to do, and it was 2 weeks late, and I had spent 5 months "goofing off and not working" and then about 6 weeks doing the work. So my estimate should really have been '8 weeks' and if I had started on time it would have been done two weeks earlier than that.
I thought about that for a long time. And explained to him the for five months I had no idea what the best way to write the software was, and in that five months I had learned about 8 different technologies that all came together into the final solution. I had to learn how to write device drivers in Xenix, how to map I/O space memory into the kernel, design a language which was human understandable and could be compiled into the odd little RISC instruction set of the Graphics chip. And until I had figured out all of that precursor information, I didn't have a clue how it would be written, but then after figuring out that information actually writing the code was fairly mechanical.
In this one case the problem was that hardware has so many great milestones you can call out, parts captured, schematics done, netlists verified, layout started, design rule verification, first films, films checked, first boards, boards checked, first assembly. Bringup in stages 1, 2, and 3 etc. All along the way there are pleasant milestones to say "this is done" now on to the next thing.
But software is never like that for building something that nobody has ever built before. And it is even rarely like that when you have the same software but you are building it on a different system. The linkages, the entanglement between the system and the software (and now the network and the services) makes each new implementation its own special snowflake, with its own kinds of problems.
Have you ever woken up and "knew" the solution to a tricky software issue? Or had an idea for a change to an existing system that might make it better? That happens to me all the time when I'm designing stuff. And a case could be made that I'm working even when I'm asleep! Not because I'm sitting there typing in lines of code but because I'm going through the solution space, somewhere in my subconscious, looking for clues to places that hold better answers than the answer that is currently checked into the git repository.
As a result I tend to measure my own productivity by 'solutions over unit time' versus 'hours typing into employer owned equipment'. It still bites me from time to time when a supervisor needs a constant stream of 'still flying' type status messages to feel comfortable.