I was told they couldn't work well with constant interruptions like that. WTF? Probably was an extreme ... something going on on their end, but... wanting/needing some answers and waiting 4 days was, to me, being rather patient.
Development for me has the highest cost for task switching. The ramp up also takes longer. If I have 15 minutes before a meeting and I have not started writing code, I won't even bother starting.
If I compare that to being a Sr Manager, the cost of task switching is much lower, so was the ramp up time. Essentially it was a "let me get my notes, or the doc/email/presentation" and then I was set. That's maybe 1 minute.
I think the biggest difference is that as a developer you either have to come up with something that doesn't exist, or you have to read something that someone wrote that has never existed before and then you have to figure out what the mistake was.
The closet thing that resembles that for non developers is other abstract sciences, like Math, Chemistry, Physics or purely creative writers.
So imagine you are a creative ghost writer. You are asked to write Chapter 8 of this fantasy book. By the way Chapter 7 and Chapter 9 exist. Your writing has to match the style of chapter 7 and 9, including character names. Chapter 9 was written 16 months ago, and the guy left. Chapter 7 was never edited, but it will while you are working on chapter 8. You also wrote chapter 5 a month ago, but since then 4 other authors have updated chapter 5 to make it better. Do you think interruptions would help or hurt?
This is why developers complain about losing flow state. The cost of getting it back it too high.
They're also not typically creating things directly that provide as much business value as developers are.
Not that I’m particularly fond of this current incantation of Agile.
No one is expecting an NBA player to respond to texts during a game.
I think programmers bring this up because they think people aren’t aware that their flow state is a thing, too.
Either I am doing something wrong/I'm stupid or not all coding jobs need the same kind if deep work.
Because more than 90% of my individual technical work requires me to be in a flow state. It takes a good 30 minutes to hold a really large thought in mhead, and I can't start coding until I feel like I'm mentally present.
Now I have actually done different jobs too. I have presided over clubs in school, I worked as a mechanical engineer for a while and I used to write comedy scripts for dramas. None of them required flow state to the same degree.
Math derivations required an even higher flow state, and that's the only exception. I mentioned writing scripts. It actually requires a flow state, but it is more like pair programming and a group activity, so if you lose context someone will quickly bring you back to where you were.
Maybe other roles are more easily chunkable or people just don't care about making sure that their work doesn't have side effects or how it fits into the whole. But, I've found this one complaint by developers to be quite genuine.
__________
One thing that has worked is to write down entire interfaces, contracts and explicit steps before I even start. This step absolutely needs deep work and usually take 7-8 hours at a time.
However, once it is done, you can address each step or class as if it is somewhat side effect free. As a tangent, this is also why I hate using classes when state doesn't exist. A function allows for so much better side-effect free mental compartmentalization than instance methods.
This is fairly unique. If you're painting a big oil painting, yes you need similar kinds of isolation to get it done. BUT you aren't really maintaining a deep conceptualisation of the whole thing in order to paint. Rather you can "let the canvas remember most of your thinking": ie., the painting is its own schematic, by the means of layering & outlining it.
Also, in social-creative work "flow states" arise more naturally. I think people working with people, on the whole, enter flow states. It's why managers struggle to see the issue with asocial-creative work.
The issue here is code by itself is nothing like a dress or a canvas: it doesn't encode much of our thinking. We have to rebuild an interior world when we encounter it.
It is for this reason "literate programming" is almost certainly an excellent way to program -- absent almost any tools or popular sentiment in support of it.
Code can be written more like paintings are painted, ie., "self-documenting" -- but this is very hard to do well.
Programming with jupyter notebooks, I'd guess, is more resilient to interruption -- it is more like making a dress or painting a painting. Yes, you need isolation and quiet -- but an interruption neednt be so fatal. You write in your thought process as part of the activity of making the code.
What is rarer is the moment of effective effort's nature, for many types of coding (to agree with your point).
The author's house of cards analogy trivializes it and makes it easier to dismiss as a rhetorical device. I'd use activation energy as a more apt comparison.
IOW, if you put in 30 minutes (or 3 days) understanding code, and do not make the correct 5 minute addition / change at the end of that, all that previous time is wasted. And moreover, that knowledge has some half life in my head, after which it must be reacquired.
And that correct addition / change cannot be made without first paying that cost.
This is not unique to coding, but is generally limited to professions involving the modification of dynamic complex systems. E.g. legal, biological, mathematical.
And I'd hazard to say of those, programming has a wider universe of possible approaches (aka "Why did the last person? Oh... Oh. Oh no."). Legal is probably the closest analogy.
But the question is where do the differences lie. My hypothesis for one difference is that we dont write code like painters paint.
That is bad. We should. Hence my advocacy for literate programming.
It isn't to be dismissive of painting, it is to say we put ourselves in a more precarious position by how little we support ourselves with our tools.
Painters (, mathematicians, etc.) are all working with pencil-and-paper in quite a radically different way.
I think this goes some way to saying, actually, there is a bit of a difference here.
Doctors and nurses, who also deal with complex systems, have gotten exceedingly good at this with charting.
We? Considerably less so. But I'd hazard improving every year.
Reduction of boilerplate and flexibility-for-the-sake-of-flexibility in languages has been a big win, IMHO.
From c. 1m30s to 5m30s
In my limited experience in the creative realm (music), it takes an incredible amount of flow and concentration to get a thought or feeling out of your head and into some form of recorded medium. I can't just stop cold, wake up the next morning, listen to what I was working on and pick up where I left off. The creation is a product of a fleeting experience that can't easily be recreated.
Programming, as practiced, is distinct from painting -- but this has more to do with the practice of each. Programming tools do not afford the same ability to externalise thinking.
Fundamentally, they are built to run the code. Not to assist the programmer.
Jupyter notebooks are, here, a notable exception.
I actually spent 6 hours on Saturday writing it and another 4 to 6 other days getting it to where I was happy with it. So I appreciate the kind words.
Edit: fix a typo
My intention of the article was to give a good visual of the complexity that gets built up while coding and some tips for how I've helped myself focus better.
It wasn't intended to come off as whining, it was more to help me recognize that there is a great deal of complexity that happens and it's easy for me to avoid facing complexity by doing less intense work.
3 of the 4 tips were targeted towards things I can do to protect myself, from well, myself. I'm my worst enemy when it comes to interruptions.
My other tip was how teams can work together to make sure an interruptions is worth it.
I'm certain, like you say, the need for flow or focus is not unique to developers, but can apply to many knowledge workers.
No one is saying that. Programming is plain hard work that requires deep concentration to keep a lot of parts in working memory, and is obviously more cognitively demanding than most other jobs. It appears you don't have experience with programming non-trivial things.
Perhaps it's different in modern web development, where you create free form monstrosities that change daily and you are paid by code churn.
As legend would have it, Archimedes was killed by a soldier because he angrily demanded "Noli turbare circulos meos!"
I guess that is what "whiny" mathematicians deserve ...
Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.