It's not reasonable to expect your coworkers to treat you like a monk who needs to spend long hours in uninterrupted deep thought and reflection.
Avoiding the cognitive penalty of interruptions is a skill that every programmer should develop. It's a big win in terms of productivity, and it only becomes more important when you become more senior and need to collaborate more frequently with other teams or provide support to other developers. Collaboration is where true productivity comes from anyway, rather than raw coding skill (above a certain baseline of competence, of course.)
In my experience, productive programmers often avoid the problem by just writing stuff down. If the guy in the comic strip had a pen and paper he could have quickly drawn those flowcharts he had in his head. Or he could have typed his ideas in comments or in a text file. But if he tries to hold such a complicated structure in his head, to the extent that he can't have a conversation with another person, he's just needlessly setting himself up for failure. I doubt he would make it through a lunch break or even a bathroom break if he can so easily lose track of what he is doing.
If we could so readily write this stuff down so that we can come back to it, we could have already banged it in through the keyboard and be done.
What's going on in a good programmer's head is going to be complex and detailed, because we need to understand it to be able to write it, and that basically means we're running the code in our heads before we commit it to a screen.
We're not "setting [ourselves] up for failure". We're solving hard problems with the expectation that we won't have to come back to it in an hour's time just to erase all our poorly planned code and start over. It's not like writing an email--we're switching modes over to thinking like a computer and this requires concentration and focus.
I'm a programmer too, and I am well aware of the complexities involved in the job. You don't need to explain them to me. I think you're overselling your point quite a bit. There are ways to deal with the mental challenges that are superior to keeping the whole thing in your head.
Imread omce that there are two kinds of programmers: those who have a mental model that keep the whole system in mind, and work out the next atep after the gesalt form, and those who have a model that is disjunct thus are able to stop, and pick things up later.
Early on I realized I am the first kind. Perhaps you are the latter?
In my experience programming is almost fractically complex. No matter how far you subdivide the problem you're solving you're making a tradeoff between the complexity of the problem you're solving and the complexity of the tree of sub-problems.
And even ignoring that: writing down abstract concepts is hard. Doing so is (to me) as distracting as dropping my work completely and doing something else for a while.
IMO the solution isn't never being disturbed and it isn't writing everything down either. It's keeping disturbances as few as reasonable and being able to get back to it quickly, even if that means rebuilding your mental model.
I still prefer chat messages, even if the other person sits right next to me. You can finish whatever subtask you are working on, take some time to think about the the question being asked and probably give a better answer
As a message to non-programmers, this is missing the last frame, where the programmer either takes twice as long or writes a new bug that costs the company thousands because of the interruption. The interrupting manager doesn't give a hoot that he made the thought fizzle unless there's some external consequences.
I manage programmers, architects, analytics, project managers and business process operators. I think this applies to all of them.
Basically anyone with a higher education that was hired for their brain, works like this.
Sorting a business process or a benefit model of hundreds of postits to figure out the most efficient way for a team to perform a task isn’t really that different from fixing a piece of software.
Having people not disturb each other is hard though. I’ve managed different teams, and the funny thing is, that it’s even harder to get people not to disturb each other when they all think that what they do requires special concentration. So this funny little illustration of the issue actually makes it harder because it might make my programmers think they require more concentration than their coworkers. :p
I’ve always worked in open office spaces, I think I’d be lonely without one but it sure isn’t great for concentration.
I wonder why upper management keeps designing them so poorly too. I mean, in concept the interoperability of a buzzing idea sharing space is great, but the concentration zones are almost always so shitty that nobody uses them, and even if they do, the concentration bit is often ignored by corporate culture.
In my experience being asked questions you can retrieve from memory aren't too distracting. Questions you need to even fractionally think about however cause the whole house of cards to come down.
"Did you see my email about thing?" is going to get a prompt no from me. "What's 3*9" is going to get you about 30 seconds of huhs and hold-ons before I realize it's an unimportant question (at which point it's too late to recover).
I had situation recently where I was deep in some code, manager went and asked about a problem in second unrelated project. Switching mentally between those two codebases was almost painful and I probably looked quite funny for several seconds.
The problem for me is that I've contributed to several different projects in different languages and I'm the most knowledgeable person in my (small) company, so If anyone has problem or doesn't know something, he must ask me. Recently I've found a good way to tame this a little. Asking person is required to write my response in apropriate wiki so that if something was unclear, knowledgebase will be upgraded for everyone.
It usually only happens to me when I'm drifting off to sleep and I've managed to come up with a solution to something I've been working on (or otherwise an interesting angle to pursue). Too often instead of taking it down in some manner, I quasi lie to myself that I'll remember it in the morning, so I can continue to fall asleep instead of taking any other action in that moment. The next day it becomes a game of recall.
As a person trained in maths, I feel like this is a little to in itself. There are many scenarios where a similar thing happens. When I was digging ditches during KSMAP there were many periods where you get into the groove another speaks and you forget.
I am getting some other spam. I will say my friend came up with the abbreviation of Kazakhstani Secret Military Aptitude Police. That was not the official title, but how my friend characterized our work.
Myself I worry that I have said too much online. A person these days cannot discuss the past without giving away the self.
Most knowledge work involves managing many layers of abstraction simultaneously in your head and also working in a collaborative environment, but only programmers seem to try to make it out like they deserve some award for doing their job in this regard.
We get it, being interrupted sometimes can be a nuisance when it causes you to lose your train of thought. If you find dealing with other human beings during the course of your day to be such a detriment to your productivity, perhaps you shouldn't work in a collaborative field.
Personally I'm okay with an occasional interruption especially if it is something technical someone else is working on. Sometimes it is that little break that gives your mind time o think of a better approach to the original problem.
This is why comparmentalization- or object orientation was invented. To keep the problems one needs hold in ones head small.
http://paulgraham.com/head.html
In a ideal case, you do not need read into the layers above and below, because reliable interfaces limit the scope of a problem.
It's not reasonable to expect your coworkers to treat you like a monk who needs to spend long hours in uninterrupted deep thought and reflection.
Avoiding the cognitive penalty of interruptions is a skill that every programmer should develop. It's a big win in terms of productivity, and it only becomes more important when you become more senior and need to collaborate more frequently with other teams or provide support to other developers. Collaboration is where true productivity comes from anyway, rather than raw coding skill (above a certain baseline of competence, of course.)
In my experience, productive programmers often avoid the problem by just writing stuff down. If the guy in the comic strip had a pen and paper he could have quickly drawn those flowcharts he had in his head. Or he could have typed his ideas in comments or in a text file. But if he tries to hold such a complicated structure in his head, to the extent that he can't have a conversation with another person, he's just needlessly setting himself up for failure. I doubt he would make it through a lunch break or even a bathroom break if he can so easily lose track of what he is doing.
If we could so readily write this stuff down so that we can come back to it, we could have already banged it in through the keyboard and be done.
What's going on in a good programmer's head is going to be complex and detailed, because we need to understand it to be able to write it, and that basically means we're running the code in our heads before we commit it to a screen.
We're not "setting [ourselves] up for failure". We're solving hard problems with the expectation that we won't have to come back to it in an hour's time just to erase all our poorly planned code and start over. It's not like writing an email--we're switching modes over to thinking like a computer and this requires concentration and focus.
I'm a programmer too, and I am well aware of the complexities involved in the job. You don't need to explain them to me. I think you're overselling your point quite a bit. There are ways to deal with the mental challenges that are superior to keeping the whole thing in your head.
Imread omce that there are two kinds of programmers: those who have a mental model that keep the whole system in mind, and work out the next atep after the gesalt form, and those who have a model that is disjunct thus are able to stop, and pick things up later.
Early on I realized I am the first kind. Perhaps you are the latter?
In my experience programming is almost fractically complex. No matter how far you subdivide the problem you're solving you're making a tradeoff between the complexity of the problem you're solving and the complexity of the tree of sub-problems.
And even ignoring that: writing down abstract concepts is hard. Doing so is (to me) as distracting as dropping my work completely and doing something else for a while.
IMO the solution isn't never being disturbed and it isn't writing everything down either. It's keeping disturbances as few as reasonable and being able to get back to it quickly, even if that means rebuilding your mental model.
Sure, if you don't mind writing garbage code. Otherwise, if you don't understand it, you can't say for sure it's correct, and it's usually wrong.
I still prefer chat messages, even if the other person sits right next to me. You can finish whatever subtask you are working on, take some time to think about the the question being asked and probably give a better answer
As a message to non-programmers, this is missing the last frame, where the programmer either takes twice as long or writes a new bug that costs the company thousands because of the interruption. The interrupting manager doesn't give a hoot that he made the thought fizzle unless there's some external consequences.
I manage programmers, architects, analytics, project managers and business process operators. I think this applies to all of them.
Basically anyone with a higher education that was hired for their brain, works like this.
Sorting a business process or a benefit model of hundreds of postits to figure out the most efficient way for a team to perform a task isn’t really that different from fixing a piece of software.
Having people not disturb each other is hard though. I’ve managed different teams, and the funny thing is, that it’s even harder to get people not to disturb each other when they all think that what they do requires special concentration. So this funny little illustration of the issue actually makes it harder because it might make my programmers think they require more concentration than their coworkers. :p
Worse, modern "open" offices are designed for interruption.
I’ve always worked in open office spaces, I think I’d be lonely without one but it sure isn’t great for concentration.
I wonder why upper management keeps designing them so poorly too. I mean, in concept the interoperability of a buzzing idea sharing space is great, but the concentration zones are almost always so shitty that nobody uses them, and even if they do, the concentration bit is often ignored by corporate culture.
This is funny, but I don’t think I’ve ever had a train of thought so fragile that a single passing phrase wrecked it and I had to start over.
The last frame should actually say something like “hey are you ready for our 1:1?”
:)
I have lost my train of thought from vague comments or questions like that.
The comment in the article was "…email about that 'thing'". I would immediately think "what thing?", then everything else goes down the drain.
In my experience being asked questions you can retrieve from memory aren't too distracting. Questions you need to even fractionally think about however cause the whole house of cards to come down.
"Did you see my email about thing?" is going to get a prompt no from me. "What's 3*9" is going to get you about 30 seconds of huhs and hold-ons before I realize it's an unimportant question (at which point it's too late to recover).
I had situation recently where I was deep in some code, manager went and asked about a problem in second unrelated project. Switching mentally between those two codebases was almost painful and I probably looked quite funny for several seconds.
The problem for me is that I've contributed to several different projects in different languages and I'm the most knowledgeable person in my (small) company, so If anyone has problem or doesn't know something, he must ask me. Recently I've found a good way to tame this a little. Asking person is required to write my response in apropriate wiki so that if something was unclear, knowledgebase will be upgraded for everyone.
It usually only happens to me when I'm drifting off to sleep and I've managed to come up with a solution to something I've been working on (or otherwise an interesting angle to pursue). Too often instead of taking it down in some manner, I quasi lie to myself that I'll remember it in the morning, so I can continue to fall asleep instead of taking any other action in that moment. The next day it becomes a game of recall.
Prior comments: https://news.ycombinator.com/item?id=6625714
As a person trained in maths, I feel like this is a little to in itself. There are many scenarios where a similar thing happens. When I was digging ditches during KSMAP there were many periods where you get into the groove another speaks and you forget.
Sorry to the person who PM'ed me on other media, KSMAP was a phonetic translation. I cannot myself translate it faithfully.
I am getting some other spam. I will say my friend came up with the abbreviation of Kazakhstani Secret Military Aptitude Police. That was not the official title, but how my friend characterized our work.
Myself I worry that I have said too much online. A person these days cannot discuss the past without giving away the self.
Most knowledge work involves managing many layers of abstraction simultaneously in your head and also working in a collaborative environment, but only programmers seem to try to make it out like they deserve some award for doing their job in this regard.
We get it, being interrupted sometimes can be a nuisance when it causes you to lose your train of thought. If you find dealing with other human beings during the course of your day to be such a detriment to your productivity, perhaps you shouldn't work in a collaborative field.
Solely a comment on the comic: moneyuser.com also has a hommage to this one: https://www.monkeyuser.com/2018/focus/
If you didn't know about the monkeyuser comics so far (as did I, a couple of months ago): You're welcome :)
In my workplace we have a unwritten rule: don't disturb someone with headphone/earbuds. This works quite well for us.
Personally I'm okay with an occasional interruption especially if it is something technical someone else is working on. Sometimes it is that little break that gives your mind time o think of a better approach to the original problem.
Prompted by this discussion:
https://news.ycombinator.com/item?id=18041337
This is why comparmentalization- or object orientation was invented. To keep the problems one needs hold in ones head small. http://paulgraham.com/head.html
In a ideal case, you do not need read into the layers above and below, because reliable interfaces limit the scope of a problem.
no one cares. they want a status update for the thing they just halted progress on, and prolonged further by interrupting you.