> Nobody else

Programmers are far from the only people who do creative work that involves building complex models in a mental "buffer" and then streaming them out into some persistent form.

Maybe most people on HN are programmers, and maybe most programmers work in offices where they're the only people who do this kind of work. But that's the kind of exceptionalist tech-centric point of view that can only make it more difficult to communicate our struggles to our non-programmer co-workers, who might actually be very familiar with similar struggles in different (possibly non-professional) contexts.

> Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc.

The fundamental issue I have with this argument is that it assumes the role of “sales guy” and “manager” are always the same.

I’ve spent quite a few years in the Enterprise software space, and I can assure you that the knobs to twist on a massive deal are numerous, highly complex, and would paralyze some devs in their tracks.

It’s easy to trivialize these roles because they often appear to be full of “busy work”. If you have the opportunity, go spend some time with the sales team! Listen in on some calls. Get involved in a hiring round. Participate in a marketing meeting about establishing positioning for your next product/feature.

I basically switched from programming to writing (= for humans) and the need for concentration is rather similar. The model of the text-to-be is not as mechanic, but consists of so many threads that need to be woven together that you can easily lose track.

> Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc

Have you ever worked in sales or as a manager?

Managed teams for a long time. Not a sales guy per se, other than having been in a lot of sales calls.

Looking at their schedules for the ones on my team, you could not break up software development like they do with that they do.

My manager's day is filled with stuff in 15 minute to 1.5 hour increments.

And yet even with these 15 minutes you have to immediately mentally reconstruct the context of this meeting and then actively listen to what the other person says, figure out if they actually mean what they ask (quite commonly the issue is different), and then immediately jump into another meeting, and you can't just forget what happened during that 15 minutes. You have to carry this mental model of conversation and context (typically multiple ones) all the day with you. Then you have to actively prioritize across the various contexts and deliver value for all of them, while being in the meetings for the better part of the day.

It's a different side of the same coin.

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 are annoying but they’re unavoidable, and we can develop strategies to make them less impactful. Passive aggressively trying to make somebody else feel your pain is guaranteed not to work and will just make them resentful and make you look petty.

I agree it's silly to hit back at people.

As for managing the interruptions, I tend to think of it that a deep session needs maybe 3 hours from one end of the pool to the other. Break it and you might need to start over, depends on how checkpointy you can make it, so try to make a way to not get interrupted for that length of time. That's a real senior coder skill BTW, making your own exploration recoverable. You already mentioned one thing you can do, which is to not try the really long crossings.

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.

> Nobody else constructs models in their minds that are almost purely mechanical and specific to a small problem. Every model the sales guy or manager uses has very few knobs to twist

What about mechanical engineers, electronic engineers, etc.?

The comment could probably apply to every form of engineering if we want to look at things broadly.

They are programmers. They even use programming tools to do their work.

Architects, lawyers...

EDIT: Removed writers. Architects and lawyers don't have as much room for mistakes and technical detail matters more in their work.

Intuitivists. They might take their time to refine their thoughts but they aren't programmers.

Type one thing wrong and your novel is still a novel.

Describing a lawyer as an "intuitivist" is pretty hilarious. Their work, especially surrounding contract work, can be extremely programming like, with very particular language, highly technical and specific terms/wording, and there absolutely are many cases where typing one thing wrong (such as a misplaced comma) can (and has[1]) completely change the meaning of crucial sections of contracts.

[1] - https://www.bbc.com/worklife/article/20180723-the-commas-tha...

The list was different earlier.

Obviously I can't know about what every profession does, not even my own. But I've interacted with enough professionals of various sorts to say I don't think the intricacy is the same.

Ymmv

It is. Before becoming a sysadmin I was a lawyer for 12 years. Never had trouble with interruptions while on my feet in court (except for my adversary, or the judge), but it was a real problem when drafting contracts or auditing complex estate accounts. Sure, you could multitask easily in a real estate closing or a trial settlement conference. But a lot of the work required shutting the private office door and asking the staff to "hold all calls". To be fair, sysadmin work was a lot less stressful and more rewarding -- except when it came time to write or debug code. That, and troubleshooting WebLogic services, Apache threads, the network team's firewall rules or database performance.

The real problem is that, culturally, most people aren't ready to accept software development as a high wire, professional, activity. That still would disturb this fantasy they have about tech being "intuitive" or managable in any meaningful way for non-experts. Those of us on the inside know that's b.s.

type one thing wrong and my code is still code, but the meaning changes, just like the meaning in the novel changes.

with many novels, the author may have intended X, but readers are often encouraged to bring their own views and interpretations to the work, and those may often be useful to others in understanding the work. that's not as true for most software I've worked on though.

And when I mentioned writers, I was thinking of the work that's probably required to build the plot, even before writing it. I'm not a writer, but I would imagine it involves holding a world and timeline in their head and tweak it while making sure they're not introducing plot-holes. I imagine quite a bit of research is involved, too.

This would be quite problematic with legal writing.

As if programming can't involve intuition. There isn't one way to do things nor do we operate with strictly defined rules to follow. We need a fair amount of intuition from experience to make the decisions that will be more beneficial for the future development of our projects.

The point is others tend to rely more on intuitive structures that are everyday. Crystallised intuition about a specific domain doesn't count because of course everyone who is a specialist is going to have their own local knowledge. Calling it domain intuition might make more sense.

What kind of intuition do they rely so much on to call them intuitionists that is everyday in nature rather particular to their domain, but that programmers don't also rely on? Are we talking "everyday" like "I need to buy groceries" type of intuition? I don't understand what you're trying to say.

> Nobody else constructs models in their minds that are almost purely mechanical and specific to a small problem. Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc.

When we get to this sort of absolute perspective. I like to think “either everyone before me is/was an idiot, or maybe I’m missing an unknown unknown”

I’m sure other technical fields of non programming require holding more than one thought in the head at once.

Perhaps anyone constructing anything that depends on an intricate set of rules may experience the same thing.

In a lecture Lamport once talked about the difference between mathematical equation (where half a page is a lot) and a program (which is a sort of math, only many pages long).

> I’m sure other technical fields of non programming require holding more than one thought in the head at once.

That's not a good enough comparison. You don't see the qualitative difference.