Earlier quoted context omitted.
You should really know what you're doing all day. If you can't even summarize what you were doing all day, that sounds like a bad thing. The evidence is your story about what you actually did. Here's a perfectly great update that didn't result in a quick win: "I spent all day debugging that null pointer issue like we discussed. I thought maybe it was because the API was sending nulls across, but I looked at the logs…
That's the thing - this works only when you have clearly task - solution based jobs. But when it is more creative and abstract this is not feasable.
"This morning I sketched out three different possibilities for the new client check-in service. First draft of the spec is in progress, I expect to send it over to Jen and Andy tomorrow for their feedback."
"I made a dozen or so mockups for the new landing page. I have a couple more ideas I want to try out tomorrow, then I'll figure out what the best four or five are and show them to the team."
"Since we don't have any feature work pending right now, I've been experimenting on a branch with using $TOOL to do $THING better. It looks good because $X, although $Y might be a problem."
"We talked a while ago about doing $THING with the user's documents so they can $WHATEVER more easily, and I wasn't sure it was even possible. I've been looking into that today. It looks like there might be a way, so I'm continuing to investigate."
"We've wanted to replace $FRAMEWORK for a while now. I've identified the parts of it that we actually use, and I'm putting together a plan for what we can swap in and/or get rid of. It looks like, since we made $CHANGE last month, we can actually do most of it ourselves without much trouble."