Programming Is Mostly Thinking
Programming Is Mostly Thinking
Pretend you have a really great programming day. You only have to attend a few meetings, have only a few off-topic conversations, don'...
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.
You're right, and other intellectual "design" jobs will have physical or visible manifestations of the design process. In video you have a storyboard, set design. In music you have notation, lyrics, demo recordings, and so on.
I am keenly aware that most management still subscribes to the idea that motion is work. They are fairly convinced that a lack of motion is a lack of work. That makes sense in a lawn care service, a factory assembly line, or a warehouse operation.
I do not work in places like that anymore.
Programming is mostly research. Researching curses to cast on the guy who wrote the Incomprehensible mess you're currently debugging.
... until you finally track down who wrote this mess, and it was you 5 years ago.
The amount of times this has happened to me is surprisingly slim. And the times it has is more because the workflow has changed or was originally misunderstood by those that made the JIRA.
I think of it more as archaeology. Going through layers of history to figure out wtf happened.
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!
Well, you can make daily a torture, too
But really, feels good when there's time to actually work instead of just talk
Programming is just inventing machines where the components are words. Of course it's just thinking. What else could it have ever been?
People who don't program think it's mostly typing. They see hackers on TV always furiously pounding on the keyboard, never staring at terminal outputs or talking to a rubber duck.
Or sometimes they think it's moving 3d shapes on a screen until they fit together, and to show how difficult it is, the entire thing will fall apart during the hacking/programming montage.
Though to be fair, I don't think the producers of that media think it's like that. Trying to put actual programming on the screen would probably be boring unless it was just a montage of reactions, starting with an overwhelmed look, followed by confidence or pride, followed by a completely baffled look and wtf expressions, then a "fuck I was stupid when I wrote this yesterday" look, then maybe a bigger wtf and physically acting out frustration, then a eureka look, all followed by a satisfied smile and nodding as the montage music ends and another character says, "I can't believe it's finally done and hasn't crashed in 30 minutes!" Though I bet that would be more entertaining for programmers who can relate to the stages of development and debug than non-programmers.
This article was motivating for me by highlighting how much research, learning and cogitation are more important than typing programs.
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.