Comment by dijit | Hacker News Reader

Comment by dijit | Hacker News Reader

I don't remember where I read it, in a book or on HN or even if someone told it to me. But I learned that when requesting time or disruption: certain positions need specialised handling.

An example:

A receptionist does not necessarily need focus time, and is interrupt driven, so their work should not stretch to more than 5 minute intervals; if something takes more than 5 minutes it must be filed for someone else.

A manager manages their time in 30 minute increments, anything that can't reasonably be done inside a meeting is unfortunately unlikely to happen. This is stupid, but it's unfortunately true; you might sometimes experience other situations but I think that's not the common case.

A programmer (or, researcher, etc;etc) books time in half-day increments. If you must have a meeting with programmers, it's often better to book events in serial but only consume half a day.

I've been practising this methodology for 8 or so months in my org and it does seem to hold true in the general case, there are some minor exceptions but most people do seem to he happy.

EDIT: It was the "Makers Schedule" by PG; Serves me right not to read the comments[0] before commenting.

[0]: https://news.ycombinator.com/item?id=35462780

I feel that this is extremely dismissive of the reality that other people do in fact have similar focus requirements, but simply have learned to take notes or otherwise deal with interruptions.

There are more demand driven roles but probably every person you interface with on a day to day basis professionally has hard work to do. Sales copy? Focus. Figuring out some accounting discrepancy? Focus. Trying to actually plan out the next quarters projects in a decent way? Focus. Trying to find a good place for a year end party? Focus!

The reality is that everyone has similar interruption issues, but understands the existence of needs beyond themselves when working on a team. Programmers are maybe special in the level of coddling gotten on this topic. Along with a dose of having people more likely to have general executive control issues.

This mythologizing gets in the way of trying to tactically improve things. Real things programmers can do, such as take notes on paper, documenting ideas, writing exit/entry notes, and many other things people do to be able to come back into a project after interruptions.

It’s very liberating to find workflows where you can actually get stuff done even in small increments, because you are not relying on this idea of doing a hard reset of your mind every time you switch tasks

EDIT: to be clear, it’s good to let people work uninterrupted. Sometimes interruptions are needed because of working in a company where other people also have needs. This is true of many people working at a company, and so we should operate understanding interruptions exist and we are the same as other people.

You aren't seriously comparing looking for a restaurant with fixing bugs in a enterprise scale codebase, are you?

Maybe the difference between programming and most other office activities, for me at least, is that I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it.

I don't think that's at all comparable with writing sales copy or finding a venue.

Figuring out an accounting discrepancy might be harder for a junior auditor than a senior one, because competence grows but the problems remain a similar size. (Or I'm talking out of my ass, I only have second-hand knowledge of audit and I'm led to believe that the attitude of big firms is that if something is very hard to find, it's not worth finding because nobody else will find it later!)

Planning the next quarters projects tends to be a collaborative activity rather than one requiring deep individual flow state, I think.

> I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it.

I think that's an interesting way of putting it. I've seen coworkers in non-tech positions go through this. There is a scope expansion (though of a bit of a different flavor) going on often. Many people go to their 1-on-1s and talk about wanting to be challenged more, and looking for new problems to tackle.

But I do think that a lot of stuff, including "collaborative" things, do end up with similar mental blockage. How many times does your manager tell you "I wanted to get back to this message, but I had so much come up all day", even though the final response was maybe only a paragraph or two long? Especially in more chaotic environments people are facing unique flavors of problems pretty often in my opinion.

At one point the systems being juggled are probably very complex, and perhaps the ceiling of problem is highest for programmers. But I think it's important to not underestimate the difficulties and intractability of things other people are working on (since the intractability is ultimately what generates this whole issue with focus)

I feel in turn that this comment is the dismissive one, and in fact extremely so.

The issue is not that programmers need to focus, is that they need to focus on deep, complex work. At least a few of those other tasks you mention (don’t have much experience with sales copy, and in rather terrible with both sales and copy) do require focus but have smaller reasonable increments of progress.

Stop thinking about the workplace for a moment and think more broadly of tasks throughout the entire day. Some of those are more easily put down and returned to than others.

Some examples of tasks which require focus but interrupt well: formatting meeting notes into minutes, simple accounting (paying bills, reconciling a ledger). The main point with these are that the individual units of work are small, and don’t generally require a lot of mental preloading to begin/resume working on. So if I am interrupted it can be irritating but I don’t really lose much.

Programming generally involves a lot of mental state that needs to be preloaded, and the Subtask units are often not small. That’s all.

Regarding the insinuation that this “myth” is the result of coddling at the professional level: if this were true, then non-professionals would not discover this independently for themselves…

As someone who's had to come up with product copy and have had to fix bugs, people trying to interrupt me writing a long e-mail gets me way more than people interrupting me while trying to fix a bug where I already "know" the issue and I'm just doing the cleanup/test writing.

I am being too glib. But the sort of "focus broken, can't move forward" feeling is something I constantly have felt in many non-programming tasks. Granted this blocking is also due to the nebulous nature of those tasks vs, say, fixing a bug. Most bugs (not all!) at least have some sort of definitiveness to them.

The coddling I talk about is stuff like other staff members being told to "not bother the coders", something I've seen first and second hand. That, along with many programmer's (myself included) habit of generating endless excuses for why something is not happening and it being more or less accepted as a given. But as someone who struggles with this stuff, I also know that a large percentage of it is due to my own behavior! And changing that has improved things.

My post is combatative, but mainly because I really want people who read this stuff to introspect on their own behavior, and _improve_, instead of assuming that the task is impossible due to some intrinsicc nature of the work that is overestimated

Okay, this is fair.

I write and program. Writing is harder and takes longer to get back into

Are you sure this isn’t because you have more talent/competence for programming than writing? Or that you haven’t set the bars differently?

Writing is a daunting task for me, but that has more to do with my own talents and experience than anything. Not implying anything about yours, just something to consider.

Most programmers are just code plumbers. It's not like most of you are some research scientists breaking into the unknown. In fact for most jobs I've held programming has been by far the easiest part of the job. Understanding the 'real' requirements from the client (not what they think they want but what they actually want) and many other things are on a completely different level of complexity. Computers are the most basic parts of a business. I've also noticed that most software people are horrible at understanding the business that they are operating in. And think that management is the one that doesn't understand things. Except it's the other way around. Engineers are optimizing the parts that don't need optimizing and don't focus on bringing value to the business.

And then we wonder why our software can’t run acceptably on multi ghz processors.

> The reality is that everyone has similar interruption issues, but understands the existence of needs beyond themselves when working on a team. Programmers are maybe special in the level of coddling gotten on this topic.

Sure everyone deals with interruptions. But the real question is how deeply focused do they need to be to operate? How many variables to they need to keep in their head so to speak, to do effective work? Is it the same for engineers vs other disciplines?

> This mythologizing gets in the way of trying to tactically improve things. Real things programmers can do, such as take notes on paper, documenting ideas, writing exit/entry notes, and many other things people do to be able to come back into a project after interruptions.

Question is: are you willing to foot the bill? This extra reading/writing/documenting takes time. Is it worth it to get a more responsive engineer? It's really the same constrains as in operating system design; you can context switch endlessly by restoring state, but you'll pay with disk access time.

> It’s very liberating to find workflows where you can actually get stuff done even in small increments, because you are not relying on this idea of doing a hard reset of your mind every time you switch tasks

That's assuming you can break down tasks that way. Deep engineering work often doesn't work that way.

I fully agree with you. I’ve been a software developer, a customer support engineer, and a product manager. My focus is also distracted by meetings and urgent things. My work is also best done when I have some time to focus. Everyone else in the professional world learns to defend their time, turn off interruptions, say no to meetings or decline them and ask for a reschedule. I actually view this as an undervaluing of communication and teamwork skills in the way we educate and hire software engineers.

Reply on news.ycombinator.com