"Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration."
I've never heard of or been part of any organization (academic, non-profit, corporate, open source, etc.) that respects the basic need of developers for uninterruptible concentration.
Note also that it is a particular word choice by Knuth: uninterruptible ... not uninterrupted. It harkens back to what Paul Graham wrote in both Maker's Schedule, Manager's Schedule and in Great Hackers -- even just having a mid-morning meeting on the calendar at all can prevent you from even attempting something hard at the start of your day, because you know the time is already interrupted.
You need more than just happenstance of not being interrupted in a given time window. You need to know that you can't be interrupted, at least not unless it's a sky-is-falling kind of emergency (and you need to be able to trust that your colleagues know the difference).
This is far and away the number one thing I need as a developer. I can write passable software that I'm not proud of if it's loud, violently anti-privacy, over-saturated with "collaboration" generally in some ultra-Agile open-plan nightmare setting. But the only times I've ever written software that I was proud of -- software that made huge, huge differences in the organizations I was part of -- was when I could finally find a loophole or something to create a situation when it was not possible to interrupt me with the usual bullshit.
It amazes me that even still, status effects and incredibly poor understanding of where the value of software engineering resides leads to so many organizations that not only have interruption-is-the-norm open-plan disasters for offices and a million Agile meetings, but actually praise that garbage and hold it up as if it is an example of positive collaboration or effective engineering, despite it being the very antithesis of positive collaboration or effective engineering.
Very true. I hate being interrupted when I'm programming. I'm fortunate that I work alone (except when my wife comes into my office). I think programming is a Zen state of concentration. Either that, or the trance that programmers get in, is a type of hypnosis.
Einstein's wife was forbidden from entering his study.
Oh, it isn't just me!
My wife doesn't understand why i have a horrified look on my face whenever she opens my office door to look for something or pass through.
I actually think understanding of this sentiment has declined over time. It's been around with a name since the days of the Jargon File (http://www.catb.org/jargon/html/H/hack-mode.html), but the general trend seems to be towards not supporting it at work or realizing how universal it is among programmers.
I'm not quite sure why; I assume it's partly that software development is less unified these days, and perhaps partly that day-to-day coding is way less stateful than it used to be. If someone is juggling register addresses all day, I imagine they'd be especially quick to condemn interruptions.
I think psychological flow [0] is the more general framework for this -- even outside of programming. It's not that understanding is declining, it's that programmers don't do a good enough job of demanding healthy working conditions. The rise of start-up like physical work spaces is an encroachment by those who extract wealth from our labor -- pushing the envelope as far as they can and taking more and more concessions, not just in terms of wages that don't keep pace with expensive cost of living implied by the urban centers where you're more or less required to live in order to work, but further by making basic physical workplace health an issue of subordination and sublimation -- signalling loyalty by being willing to suppress your human needs and requirements.
In other words, people aren't ignorant of this, they just won't care unless programmer labor makes them care, and programmers seem especially bad at sticking up for these kinds of things.
The problem is how to make a company care. If you say you quit unless you get your own office they'll say "Good riddance, even if you're a great dev and we'll have problems replacing you, we don't want someone who's not a team player."
Most people are social creatures (including most programmers I've met), if asked they will tell you they like to share a room with several others. It's fun, it's "collaborative" and there can be a hearty banter going on or whatnot. It's the cool thing to do because all cool startups do it! And they are team players!
So now if you come along and say you can't work under these conditions, your coworkers will think you don't like them and your managers will think you're not a team player. So in order to have any possibility of success, all programmers need to be on-board.
Now this is difficult because bringing the subject up may cause your coworkers think you don't like them. Then they'll say they rather sit together, and they want to be team players, and that having their own office with a door they can close feels like a privilege they don't deserve, and that closing the door feels like you're not being social, and that they don't even remember what it's like to be in flow (if they ever have). And that it will be too expensive for the company if all devs have their own room. Never mind the loss the company makes due to devs working (much slower) in interruptible mode. The problem is that that loss is not easily quantifiable.
My own experience is that I'm much more productive when I've had my own office and had the possibility of long stretches of working in flow. But whenever I've brought it up with a manager they've brushed it off as anecdotal (even though I've brought studies that say the same thing) and made me feel greedy for wanting the privilege and prestige that comes with my own office even though I care nothing about prestige and the only privilege I want is to be allowed to work in flow because that is a marvelous feeling.
> Most people are social creatures (including most programmers I've met), if asked they will tell you they like to share a room with several others.
I think this is actually false, both anecdotally and when surveys have been collected.
No one actually thinks you're not a team player just for desiring minimally healthy conditions. They are fully aware that you are probably a great team player, especially if you care about your teammates getting healthy conditions too.
The "not a team player" buzzword is just a political tactic to find a plausible excuse to discredit or eliminate you, despite you having a justified point, before it ends up catching on with colleagues. It's an HR code word for "we need a blank check excuse to impose our will while thinly veiling our dictatorial approach with some democratic plausible deniability" -- nothing more, nothing less.
Coworkers also will rarely care -- they want privacy too! As for managers making you feel greedy, that's just more of these psychological manipulations and tricks. They know full well your request is healthy and reasonable, but need a way to both look like they are high status and reject it at the same time, so they must invent ways to make your request look low status.
> I think this is actually false, both anecdotally and when surveys have been collected.
Yeah, me too, I guess I was a bit vague with the "if asked" part. I meant if asked straight to their face when others (possibly) managers are listening. There are exceptions of course but in my experience most people see it as a potential conflict with coworkers and managers and will not support it publicly.
> No one actually thinks you're not a team player
Yeah, I know, poor choice of words. But I meant basically what you said. It's shite politics in play. The cost of an office is a very concrete number in a spreadsheet but the loss of productivity is hard to gauge.
I have a small office in a large closet upstairs that I use at night for work, my SO has a converted room downstairs as her office for her home business, so there's not a lot of cross traffic. Unfortunately, that means she IM's me quite a bit, which since it's even lower cost than walking 20-30 feet if she's already at a computer, I'm not entirely sure isn't worse. :/
I frequently work from home and coworkers pretty frequently IMs me. Maybe I overthink this but I don't dare to shut off my IM (or mail either for that reason) in order to have uninterruptible concentration on a task because if I'm not responding to IMs quickly enough my coworkers may get the wrong idea about me working from home. The company supports it and most of the time I'm much more focused working at home, but when I'm in the office I frequently hear comments about other coworkers working from home like "Oh, (s)he's working from home, well, it is a beautiful sunny day today * snicker *".
Why else would you want a private home office? If you don't have a significant other, there's no need for a separate private space.
In my case, I work from home two days a week, and I have children. I separate space is essential to get work done. It's a matter of having a private space that allows me to be home if needed, and save time for with my family, or not being productive enough to make it economical for the business to allow.
I was trying to express that I am envious of people who are able to have a significant other and a comfortable home with space. Having even just one of the two sounds like a dream world to me.
This is why many devs work odd or late hours. To avoid the commotion of an active office. Every office has at least one person who abuses the communication channels. E-mail -> Calls -> Texts -> At your desk inside of 30mins asking "Hey did you get my email about <trivial thing>?"
The problem is you still have to show up and be an unproductive body in a chair during normal hours (especially if you work for a "progressive" company that talks a lot about how you don't need to keep regular hours) in order to get status points and be seen working. Then you have to stay late or work extra remotely to get the actual work done. So then you're just trading the productivity loss of an unhealthy, poor workspace for the productivity loss of unhealthy, poor hours, fatigue, and burnout risk.
I agree with most of your sentiments. Unfortunately Agile is getting to be a pretty watered down term, but in theory a bunch of "Agile meetings" is very against the whole meaning of Agile. Agile suggests "standups" because you're supposed to actually stand at the meeting, get tired, and go back to 'getting shit down'.
Question: if the point of an "Agile" standup is to share status and keep abreast of what is going on, why does it have to be done synchronously, at some always inconvenient time?
Could everybody just send a chain email with their "this is what I did, this is what I'm doing, here's my roadblocks" rote answers. Takes two minutes to type up, thirty seconds to read, instead of having to go stand around and listen to people ramble on for half an hour, with yet another meeting slicing your time into ribbons.
I don't think it's an 'either-or' proposal though. You're contrasting 'here's my ideal asynchronous system' with 'horribly long rambling meeting at the worst time.'
Here's my company's typical morning, for example:
- Arrive at the office. Catch up on email, Basecamp, maybe do some code review, that kind of thing.
- Have a stand-up meeting that lasts ~ 5 minutes, where developers and product people discuss what they are currently working on, any blockers, things that they anticipate will be needed from others etc.
- If there are any issues that require further discussion, agree a time or channel to discuss them.
It's great. Everybody is fully aware of everything that's going on, who's working on what, and any upcoming issues. It takes basically no time and serves as the launch point for the day's work.
I appreciate that it doesn't always work – may be more of an issue for teams that are geographically distributed. But I also absolutely see it working really well in practice, so I'm suspicious of reasons for discarding the idea so easily.
In several jobs all using Agile, with experienced Scrum masters and lots of training, I've never heard of or witnessed a stand-up actually lasting the allotted 5 minutes (they always run way over and never contain info that I actually need to be present to hear about) -- not even when it was a team of just four people. It's simply unrealistically averse to human nature.
Hmmm, during my last contract my shortest daily stand-up with an oversized team (14) was in fact four minutes: we held it around a restaurant table right before dishes being served :)
PS: It took 4 minutes because one of the team members was new - her first day with us ...
I have very infrequently had a standup run over in ~5 years of daily stand-ups; if it does (rare), it's because we've discovered an issue that's going to stop the team making progress immediately and needs to be dealt with. They almost always contain relevant info from the team I am working closely with.
I have to wonder the environments in which people are working where this is not the case. Is it just that the teams are too large?
I don't doubt your experience. I'm just saying that my experience has been violently the opposite -- for both large and small teams in large and small companies, all of which had done extensive training about Agile and had used Agile for a long time. Also, and this is not an exaggeration, literally every software colleague or contact or friend I know also has had the experience I have had.
We acknowledge there are amazingly rare companies like where you work that don't suffer from this -- but they just seem to be so, so, so extremely rare that they don't really factor into any true understanding of what "Agile" means in practice at the overwhelming majority of companies.
Also, in almost every case our standup meetings went on too long because people talked about irrelevant things, personal anecdotes, weekend plans, etc. Many times they thought what they were saying was relevant, but it wasn't. Scrum leaders were often the ones doing this the most.
Over time it basically fractured the team into two groups:
(1) the "boy scout" group who wanted to appease the Agile process and look like good, obedient workers, and so never minded the irrelevant and time-wasting meetings and acted chipper and happy to engage in all things Agile.
(2) the disillusioned and burned out group, for whom (over time) the irrelevant banter of stand-ups became like having someone grind your eardrums with sandpaper, and led to frustration, lack of energy to participate, and resentment, and a ton of turnover.
I've seen this dynamic develop in a lot of companies too. Sadly, the answer they usually come up with is a sort of Agile eugenics: let the people who get understandably frustrated by Agile leave -- regardless of how much experience in the company they have, how critical they are to their team or product, or how good they are. And then change the hiring process to screen virtually solely for Agile enthusiasm and end up shifting the workforce to a pro-Agile monoculture -- and then, regardless of whether it's objectively true or not, declare victory and talk endlessly about how much more productive you are now that you are uniformly Agile.
It doesn't really matter that it takes almost no time - it's that it is an interruption[1]. You're working along on something, getting in the groove, then Outlook dings at you , so you've got to page out the real work that you're doing, recall the silly scrum answers you're supposed to give, get up, walk over, wait for everybody to show up, blather on about things that you don't care about and already know because you've read the digests from source control checkins and ticketing, say your piece, and escape. Half an hour or more is blown away, plus another half hour to get ramped up to where you were before this all started. Oh, and by the way, somebody surprise-scheduled a customer demo or {InsertOtherMeetingWithNoDefinedAgenda} for you in an hour. Might as well just get coffee and browse the internet, and accept that normal working hours are for looking like you are working, so you can actually get something done later when everybody has gone home.
Stand-ups are only an interruption if they are poorly scheduled. I accept that sometimes it isn't possible to schedule one, such as when there is a large, geographically-distributed team. However, I have rarely seen them take place outside of the first 30 minutes to one hour of the working day, in cases where teams work on-site. This works really well in my experience, offering a little bit of time to get set-up for the day, a stand-up near the beginning to catch up and exchange status, then an uninterrupted rest-of-the-day.
To be honest, it sounds like in most cases I've heard of that teams are just undisciplined about interrupting developers. I obviously agree that interruptions are bad, but I've had great experiences (like my current team) when the standup serves to consolidate all interruptions – there will be no surprise customer demos, unexpected interrupts or other things of the sort, and part of the 'social contract' of the team is 'we will have this short meeting to keep us all up to date, and in exchange we will prevent developers from being interrupted'.
> I've never heard of or been part of any organization (academic, non-profit, corporate, open source, etc.) that respects the basic need of developers for uninterruptible concentration.
What do you think is the cause of that? Could it be because organizations aren't led by people who've experienced this problem themselves? Or do they just fail to prioritize it?
Certainly there's a need for quiet periods. There's also a need for periods of communication. Could it be as simple as dividing the day further, where X hours are reserved for no-communication time? Or, providing a separate no-interruption room for those who want to use it? Or is it just a matter of building trust with colleagues, as you say?
Perhaps voice these sentiments within your company. If nobody says anything, how will they know?
Being expected to check your emails is an interruption.
Someone entering or leaving past you is an interruption (this is why open plans and shared offices of any sort don't work well for tasks requiring open ended concentration).
I don't actually believe that most people understand these issues, they don't understand the difference between the simple menial tasks, the small steps of implementing little details you've done a thousand times, and the large leap to actually keeping your mind full of a problem to solve.
I think many organizations only pay lip service to the idea of valuing productivity. The management and executive layers have all kinds of opportunities for weird forms of rent seeking based on status, often boiling down to viewing their subordinates as a collection of pretty office decorations or the human equivalent of trading cards. They talk a lot about productivity, but actually don't care to consume productivity out of you, so they don't want to pay any costs related to productivity.
Staffing up for an acquihire event is a form of this. Designing a gaudy open-plan office with ridiculously opulent amenities yet no privacy is a form of it. Even the long-known fact that physically attractive people get hired, paid, and promoted more than equal-or-better performing, less attractive colleagues is a form of it.
Yeah I hear you on the "short term thinking" mindset of management
I think there is something intangibly great about making something that is built to last, and that some people don't recognize the value of such a thing
Best of luck finding an environment that suits you. You will!
I've certainly never seen a large organization that is consistently good about this. What I have seen, and valued enormously, are side-channel concessions to this need.
One of the better formulations is having lots of small conferences rooms (or corner chairs, or anything isolated) that anyone can grab, with bonus points for doors. It's not a complete replacement for respecting flow, but it's a great way to let people with some urgent, complicated code task get a truly isolated setting to get things done. A lot of everyday code can be written passably in counterproductive settings, so even occasional, high-urgency access to good workspaces seems to be a huge step up.
Actually, I think the bookable conference room or slightly private cubby/carrel "solution" is terrible and is a form of explicitly codifying disrespect for developer needs, which is itself a form of codifying the fact that business values more how you look on paper, your credential, and your appearance in the office than your actual labor product.
It also leads to problems where you receive status penalties in the eyes of peers and managers if you are the weird guy who always books conference rooms. It also creates problems if you work in a situation where you cannot move your workspace. For example, I also consider it to be absolutely basic to have at least two 24-inch monitors, my ergonomic keyboard, ergonomic desk chair, and trackball. Why should I be forced to use poorer tools, like a crappy laptop screen, portable mouse, crappy conference room chair, etc., just to get quiet or private space. It's unreasonable to give up either adequate equipment or adequate privacy.
In some jobs, I've also worked with large workstations and needed to be physically present at them, remotely logging in to them was not always feasible for some tasks.
Finally, you end up running into booking conflicts all the time. And anyone with more seniority or status than you gets to kick you out (thus interrupting you hugely and ruining your plans) and anyone with a meeting gets to kick you out. And it also leads to artificial scarcity -- there's no need for coworkers presumably working towards the same goal to be competing with each other for the scarce resource of blocks of spacetime in conference rooms. It's outrageously cheap and easy for the company to provide all of them with adequately private conditions.
Allowing a super generous work-from-home option is maybe a better solution -- as long as the company is also willing to pay for you to have equipment in your home office that is equally as ergonomic as what you get in the company office. But then you're contending with different kinds of status issues for not being physically present, some jobs still require a physical presence for various reasons, etc.
The minimal acceptable solution is for companies to simply spend the money that it costs to provide healthy amounts of private working space and give employees more autonomy in structuring how they work with regards to private time. No half-assed compromise should be given even the slightest legitimacy as a workable alternative and no company should get any credit for anything other than the minimally healthy option of actually providing access to private conditions.
p4wnc6,
I am trying to get in touch with you. The only contact info I could find is the email address on the "newcastle" site. Please let me know if there is a better way to contact you.
+ 1 on this. It reminds me to the two systems that Daniel Kahneman talks about in his book: Thinking Fast and Slow. The human brain is only good at multitasking simple things. You can only perform one complex task at a time.
I think it depends on what your emails contain. They can be stressful, challenging problems, or simple ones. For me, the longer I am at an organization, the less stressful communications become, assuming I've built good relationships.
It's the first period that's tough to get through. You're getting to know both the people and the business, software architecture, or whatever the job entails. During that time, we often blame email because we get email from strangers. Make the strangers friends, and email becomes a lot easier.
> They can be stressful, challenging problems, or simple ones. For me, the longer I am at an organization, the less stressful communications become, assuming I've built good relationships.
I like to communicate with customers always short and to the point via emails, because I value my and their time.
But with friends, I like to write more interesting and funny emails, that takes me more time. But because they are my friends I am willing to spend it.
Writing those mails to friends takes more concentration and allows more reflection about them and myself, in order to express myself correctly and in a nice way.
I would see the culprit more in todays Twitter culture, where people are force to write short messages without much reflection.
Maybe even the onscreen keyboard in most smartphones are another reason. Nobody wants to write more expressive messages with them.
> But with friends, I like to write more interesting and funny emails, that takes me more time
That's interesting that you find being funny more time consuming. Some people would say work/business/math is harder than humor.
You've proven my solution wrong. I can't think of anything more to say other than "some emails are easy, some aren't". And then, there will still probably be someone who says all their emails are a challenge, like Don Knuth, lol
> That's interesting that you find being funny more time consuming.
With my friends and family I am more willing to express my feelings and opinions on subjective close topics where correct expression is more difficult. At least for me, that takes measurably more time than just stating facts or expressing opinions on more objective topics for customers (and sometimes friends, for example to organize an evening together).
Adding some business politeness just have to fit some template, is very unpersonalized and, I find, easily done.
But of course there are some difficult letters to write to business contacts to, but I would call them very self-reflective.
I think people like Knuth are more hand-written letter types, were someone is forced to reflect and to go to "the bottom of things", because the act of writing itself takes more time. But I think that it doesn't matter that much about which medium is chosen or how long it takes to generate the messages, because the persons that are generating those message chose how much time they are willing to spend on each subject. Forcing it though the medium might enforce a certain standard, that could help some people or is more bothersome for others.
Huh. I find it much easier to be verbose. I've sometimes shared a laugh with colleagues when explaining,
"Sorry, I didn't have time to write a short message".
Condensing / distilling something complex into its most-concise essence is a valuable skill most of us would do well to acquire.
When I was studying in the early 2000s, email wasn't a problem. I went to check my email at the computer centre on campus twice, maybe three times a day.
With smartphones, I probably check my email 40 times a day. It is very distracting, but you have to keep on top of it for work. I'm sure it gets in the way of more meaningful thinking and has ruined my attention span.
If your job is to answer email, that seems reasonable. But if you're a programmer, I can't see how you'd need to check your email more than once an hour, or maybe half hour. Otherwise you'll never actually be programming.
If you're a programmer, your primary task isn't churning out code; at least for me, an important part is to first understand the customer or user's wishes, and second to make sure my colleagues are up to speed and aren't blocked by, for example, missing some knowledge that I possess. Mind you, most of that is done in person, not via e-mail; the Knuth comment (which I'm probably extending to your statement) seems to be about any kind of external influence, including emails, PRs, slack messages, people, or whatever.
That's fine to isolate yourself from that if you define your own problem and solution for it and work alone, but really, how many people do that? That's a thing reserved for idk, university researchers and people with their own projects.
"Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration."
http://www-cs-faculty.stanford.edu/~uno/email.html