Tbh I think alot of the “thinking” still looks like visible work though. I feel like the article makes it seem a little too much like there’s nothing observable, nothing to show or demonstrate, until POOF the code comes out.

But I find that I often need to be doing visible stuff to make progress… Like devising little experiments and running them to check my assumptions about the system (or discover something new about it), and making little incremental changes, running them, using the output to guide the next thing I do… Even occasionally spending the time to write a failing test that I plan to make pass.

So I’m 100% on board with letting managers believe this “80% of the work is invisible” thing… But I think as advice for programmers, it’s really important to not get too stuck in your head and spend too much time not kinetically interacting with the system that you’re trying to change.

Programming is mostly research. Researching curses to cast on the guy who wrote the Incomprehensible mess you’re currently debugging.

Yep. By the time I get to actually writing the code, I feel relieved because by then I have a pretty clear idea of how I’m going to do it, and I can work quickly. It’s the hours of figuring that out that are difficult, and the boss demanding constant progress reports when I’m still figuring it out and have nothing to show but a bunch of notes and TODOs. I find that writing my thinking notes in the form of documentation for the product can help appease management.

Pretend you have a really great programming day. You only have to attend a few meetings

ONLY a few? Everything beyond the Daily is torture!

Programming is like solving a puzzle peace by peace. Problem is, others (and YOU) break and rearrange solved parts already, each puzzle peace looks the same with slight differences next to it. There are bigger islands you want to connect, but you have not enough peaces or don’t see the pattern where to connect.