Do programmers really need to have the skill of "Holding a Program in One's Head"? http://www.paulgraham.com/head.html
Programmers, teach non-geeks the true cost of interruptions (2014)
151–160 of 253 posts
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#152Earlier quoted context omitted.
I’ve noticed that I have a lot less trouble with interruptions deeper in my career than starting out because those mental models are refined and intuitive now. The example presented in the article where the programmer has a carefully constructed recreation of a null reference bug could probably be broken up into a series of steps that don’t require keeping as many variables in your head. I agree that interruptions ar…
That's one of my pet peeves in this (recurring) discussion. If you're a programmer, and you're telling me that every time you work you have to reconstruct the state of a system so large you can barely hold it in your head, maybe you should invest in learning about modularity, abstraction, or just... taking notes?
The luxury of being able to design every system you work on isn't shared by many. Being able to hold the details of a complex process is one of the key traits that will allow you to succeed with legacy codebases or difficult languages.
You can try to refactor everything into a perfect state but business isn't going to wait.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#153Earlier quoted context omitted.
I think development is a profession where it is not obvious when you are interruptible. In fact one of the best manager I had outright ask me "are you interruptible?", because she doesn't know if I am deep into a complex problem or just cleaning up stuff or waiting for my code to compile. Manual labor also require focus, but when you are occupied tends to be obvious. If you are under a car, messing around with a tool…
At a prior job we actually little LED RGB light tabs that would stick on our monitors, and set them to red or green to indicate exactly this. Uptake and responses were somewhat mixed, but it was nice to have an explicit signal, beyond just putting my headphones on, that I was not going to be welcoming of interruptions for the next few hours. At the time we were in a pretty cramped office in a co-working space, so I a…
I have problems building habits going out of deep work. It's like the problem is less getting dumped from my mind and more slowly filtering out, and since my mind is still occupied, I'll move on reflex and perpetually forget to flip the switch.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#154> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…
>We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand.
The problem is that when a surgeon is cutting a brain with a scalpel, it's pretty obvious that now is not the time to ask them the status of their TPS report. There isn't the same sense of gravitas when it comes to a deep debugging session because it looks the same as when we are checking email.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#155Earlier quoted context omitted.
> Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable and no one else can understand doesn't help the situation. We seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.
I think development is a profession where it is not obvious when you are interruptible. In fact one of the best manager I had outright ask me "are you interruptible?", because she doesn't know if I am deep into a complex problem or just cleaning up stuff or waiting for my code to compile. Manual labor also require focus, but when you are occupied tends to be obvious. If you are under a car, messing around with a tool…
I'm a mathematician. I spend a lot of time staring into space and mumbling to myself. Sometimes, though, when I'm just zoned out, my wife would ask: "Are you working on something?"
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#156Earlier quoted context omitted.
> Instead, communicate like peers I agree, however... > "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?" I would just say: "I can't really stop what I'm doing right now, but I can stop by your office around 3PM." If you ask them if that will work, they'll tell you they need the answer immediately most of the time. People want instant gratificati…
>> If you ask them if that will work, they'll tell you they need the answer immediately most of the time. The question "Will that work" is optional. You need to be polite when dismissing someone, but the goal here is to offer 2 messages "I'm busy now" and "I'll get to you as soon as this busyness passes" The discussion needs to end as quickly as possible so as to not lose your focus, but also without making them angr…
I just close the door.
The few times in my career when I haven't had a door I could close, I did all of my deep work from home and only came into the office for meetings (which I compressed into 1-2 days).
The delicate social dynamics described in these threads sound incredibly expensive. I can't imagine paying someone a quarter or half million dollars and then draining away their productivity on this sort of thing.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#157I wish I could be so lucky to be interrupted for work relevant things and not discussions about Adam Sandler movies or the neighbors dog when I’m clearly focused and typing into my IDE.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#158> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…
Disrespectful jerks are a problem in any workplace. Programmers complain about it online a lot, because programmers complain about everything online.
Making a disrespectful jerk do some stupid Sudoku problem to teach them about interruptions isn't overcoming their lack of perspective, it's just letting them know that they were a disrespectful jerk (which they probably already kind of know, but they're used to it so it doesn't bother them all that much).
Of course, you can be more upfront. Just hold out a palm towards their face and say 'just 5 minutes, I'm busy'. Yeah that's rude as hell, but sometimes you have to speak their language.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#159> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…
> Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable and no one else can understand doesn't help the situation. We seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.
Not really. It’s probably more likely that developers are the ones who are able to create blogs and voice their opinions more easily on the internet.
My step-dad works in logistics and likes to quote “a single interruption takes a person 15 minutes to get refocused”. He blocks specific hours for his field staff to stay away from the office staff, so they can process the critical daily work without interruptions.
Google searching seems to say it’s closer to 23 minutes these days. Industrial engineers seem to have studied interruptions on work in the late 90’s and maybe even earlier.
As a further anecdote, when I worked in manufacturing I would end up having to come in on the weekends to do cognitively demanding work. Designing tooling, creating and optimizing CNC programs, and checking parts using coordinate measuring machines while getting interrupted by the quoting department to “just give me a quick estimate what you think this part will cost for us to make for the customer”, or production saying “we need you to quickly trouble shoot the defective parts we are producing because otherwise we will be late and get a fine for missing the shipping date” results in costly errors that can’t be fixed by recompiling code.
Pressure, interruptions, and bad management are not unique to software development. And yes, other professions do care about production high quality work.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#160I have been programming since 1977/78, and sometimes for work, but most of the time for fun. As someone who does technical work at heights with rope access, and many years of technical diving on hydraulics, pneumatic, and electrical equipment, I can say it all depends on your ability to shut out interruptions and get to a good stopping point. I get frustrated when I am programming and I am interrupted, but my most fr…
FWIW I think you could write an interesting book.
I would read the hell out of that book. Or blog