On Focus, Attention Pathogens and Autism in the Tech Workplace

I would like to talk about focus and attention, and about people with autism working in modern tech companies. I hope that a useful discussion can be started (not just me in a monoloque) and have it trickle down to your local workspace.

Myself, I prefer not to reveal which side of the yes/no of the autism spectrum I fall, other than that I am there somewhere. Being too specific might lead the reader to make too wide-raging assumptions about people with autism. Autism is a fuzzy thing which can have many elements, people having or lacking elements at random. I obviously drew a much better hand than others, as I do not have the desire for structured days or general rigidity, I am fairly social and empathetic, replying on others’ body language even more than neurotypical people. Obviously I got lucky to be handed a bunch of performance-enhancing traits that keep me out of financial trouble. Many other people around the spectrum have strengths that they never get to use in a workplace. Let’s change that.

I have been working on strategies. In the hope that others benefit from them, here they are:

The first thing is — how do we communicate state of mind to people who are different from us. We need language, we need terms that paint just the right picture in somebody else’s mind. Here are some ways that I use to explain:

(edited to add: what I would really like to end up with is terminology that can be used with outsiders, and that drives the message home effectively. Whoever invented the term “technical debt” did awesome work in explaining to non-programmers why cutting corners is bad even if you initially have some single project more on-time. I want similar terms, to explain that you can’t expect every programmer to perform well when randomized, and that randomization means different things to different people)

Attention patterns are like vehicle types

Everybody’s attention when doing mental work is like a vehicle. Some vehicles are slow, others are fast. Some vehicles are agile, others are slumbering. Some vehicles can run circles and pop into various places at a high pace. Some vehicles carry a lot of payload at a slower speed, or lighter payloads at a faster speed. Some vehicles can carry different loads at the same time (at a loss of total capacity), some vehicles can only carry one kind of payload at a time.

My own concentration is more like a freight train. And I mean a good old-fashioned 2017 American freight train lacking all those safety features that the German trains introduced 1898–1930. Large. Heavy. 20 tons of axle load, not the wimpy German 16 tons. The kind of train that drops a bunch of 737 fuselages into a river when you screw up.

My concentration moves slower and has a high payload. When its motion is undisturbed it can carry much benefit for everybody. Make it stop frequently, efficiency goes down with a larger exponent than normal. Derail it, there will be nothing happening for the rest of the day while cleanup goes on. And I had times when the next day was still collecting pieces instead of moving (although that was mostly during times when I was in an environment that I should not have allowed in the first place).

Some companies’ policies are made exclusively by people who I will liken to riders of little Pizza delivery scooters (multitaskers, people people etc). No matter how great they are at feeding their own town and how much everybody appreciates their work, the policies developed there need to be reviewed with other vehicles in mind. How many freight trains do you have on your work environment policy board? How many sports cars?

It can be difficult to see differences between engineers (heavier vehicles) when you are far in the multitasker (zippy vehicle) zone yourself. And vice versa. Not every engineer has the same attention patterns. There are those engineers who voluntarily stay in open seating, and who meet often with managers. Who multitask. I liken them to sports cars. When managers fill meetings about work setups with scooter types and add engineers, they are likely to put sports car type engineers. Then you are still forgetting to get input from the freight trains. Your designs might end up unsuitable for them.

“Workplaces are like CRT monitors with burn-in”

My work environment is like an old tube monitor (or one of those trashy 2015 4k 40” Philips panels) in that it suffers badly from burn-in when run without a screensaver. I can concentrate and do good work in busy coffee shops, airports, under jet runways and countless other distracting environments — for a while. But that expires. Single small annoyances multiply over time. An open office environment is not different. Zero problems at first. But then the screen burn-in happens. Specific people. Specific paths that people walk on frequently (anybody got some glue traps?). The sound-reflective surfaces around the whole group. Not all open office layout are the same, far from it[1]. Me blasting myself with Finnish and Dutch heavy metal and knowing that even through my high-end closed-back headphones my coworkers can hear it. Long-term I need to optimize my work seating. If Corporate Misc(tm) resets my efforts on a regular basis that is a problem.

Yes, today I can work in that Starbucks, because although it does have annoyances that did not burn in yet. If I tried to work there 40+ hours a week that party would be over very quickly. Long-term annoyances in workspaces need fixing, otherwise they lift focus.

“Attention Sponges”

I need “attention sponges”. In addition to the actual project that I am working on, at the same time. The work fluctuates in its ability to hold on to the attention. Naturally fluctuating and unavoidably, but also due to broken things (such as slow compile-run turnaround, which I wrote about here: https://hackernoon.com/software-development-at-1-hz-5530bb58fc0e).

I need something running that the wandering attention hooks onto with a predictable pattern until the attention lift is over. A good example is a TV series running that I watched many times before and still get tiny new details from — let’s say Babylon 5. It is important that the Attention Sponge is not interactive, because then it might eat up the actual work path. If I did not prepare an attention sponge in advance then an attention lift can quickly get into a randomly picking up things — let’s say browsing Ebay for guitars. While there is no problem switching back to work from Babylon 5 when the work env is ready for the next productive burst, Ebay is interactive. I might not switch back from a randomly hooked thing. Aside, I have too many guitars already (not to mention mixing consoles). A lot of people have it even worse than me, they go to social media or (shudder) news. If they pick up something upsetting they suffer even more damage to the work day.

Attention sponges of this kind can meet acceptance problems in the workplace as I am ‘watching TV instead of working’. It would be better to have a seat with the monitor facing a wall and let me apply what I learned about my own attention patterns. Many people around the spectrum are very sensitive to others walking behind them anyway.

If you follow my arguments here, at least for some employees, then you should make it clear that these methods are considered normal in your place. If you do not, then only the bolder types will pick this up (assuming they even became aware of any methods to limit damage from focus lifts).

Coordination, specs and “leave single assumptions in one single code place”

[I have to clarify this for non-programmers. When you write code you are subject to the limits of your programming language, and you are often forced to repeat the same assumed fact (how is this supposed to behave?) in multiple places. Non-programmers probably cannot imagine how limited most programming languages are. If is called “irreducable repetition” and it creates huge problems when you have to revert one assumption that is now in an unknown number of places]

Sure, I like writing code by sitting down alone and just do it. Obviously I also coordinate with people. The strategy here is that I use bursts of coordination and then bursts of sitting down and write one working line of code after another. Going out of sync with the requirements? Please. I have been programming for a long time. I have never seen complete requirements before coding starts. Unless they were BS in the first place. Which happens frequently. Anybody presents me with “complete” requirements upfront, I am unable to trust them. Sorry. Nothing personal. I know you might believe that your specs are complete and correct — you still won’t be able to convince me. Please understand that I am thankful, deeply thankful, for you having tried to do a complete job. You did a much better job than normal, and be assured that it will be of great help bringing the project forward. Your work is greatly appreciated. My own duty here still is to keep flexible. Nothing personal.

Instead of constantly ripping the actual code writing activity apart by distracting myself and 1+ other people I use an approach that I name “keep every single assumption in a single code place”, which I do with compile-time computing, a concept that I write about elsewhere. Instead of ruining the flow you keep the code safe to change every time you fill in a blank. Then you adjust on the next real sync phase. Every blank I filled in is still in one place in the code. When I learn the true value for the blank, it is a one-place change, with no risk of other parts of the code being out of sync then. Not just for the week. For the next 30 years that this codebase might live. 30 years of constantly changing single original assumptions that you want to edit in one single code place, not having to hunt down an unknown number of places associated with one assumption. 23 years after the last person who originally implemented it has left. 30 years. That is how long a lot of real software lasts.

[for decision-makers and managers:]

Now, if you are a decision maker you probably heard of this spreading of assumptions into multiple places in the code, and you are aware that this is a form of technical debt. Your developers almost certainly want to follow good practice here— but current programming tools are laughably inadequate at compile-time computing (which is what you need to actually fix this). I would like you to keep an open mind and give methods to improve this a high priority. I promise I will spam you with my writings about compile-time computing for quite a while.

Diverting from a $$$ making new project toward hunting down a previous assumption in an unknown number of places is one of the strongest attention pathogens out there. Not only don’t you get $$$ for that work, your developers are much more likely to be in “the zone” (of engagement fueling fast work) with the original project, which is what you want since it is the $$$ project, and almost certainly drops out of “the zone” on the sidetrack of unknown depth and duration. This is distracting and expensive.

The interest rate that you pay on the technical debt for this kind of “assumption spread” is very high.

Fixed-paced information flows might not work for me

I generally cannot absorb information at other people’s pace. Some details I need to pause on when others do not. Other details from fixed-pace information flow come to me quicker than to others, at which point my attention potentially goes to places where it will not return from. It can cause me physical pain when other people forcefully grab my attention and then waste it (my doctors even have a physical explanation). I can work around it — but let’s be honest, why not let me learn the way that works for me? The other people learn a different way and we all end up with a great mix of skills and approaches. Monoculture doesn’t work in software engineering.

Calvinball

I can play Calvinball in the workplace. Even for extended periods. I cannot do it at the same time as writing code. I tell everybody around me that they need to pick one or the other.

(If you are not familiar with the game, search for it. You will see a true reflection of many corporate mechanisms)

Other things I noticed:

• I suffer badly when I am unproductive due to not being able to concentrate. All kinds of frustration can kick in, and often there is fallout from whatever hijacked my focus. Buying guitar #42 on Ebay is not fun. Not the buying, not the owning, not the lack of achievement on Friday evening. I want to program. I want to see some code running on a Friday evening that didn’t run last Friday. I don’t even play those damn guitars. I enjoy coding, not playing guitar.
• I don’t need or want a single-person office. I performed best in a 3-people room, where the 2 others actually worked on the same code and had the same code interests. A room where we hacked the “locked” A/C control, and built our own ducts to distribute the air, and we were left in that place for a long time. Thank you, Matt and Jessie.

Footnotes:

[1] “Open workspaces” as implemented in the real world, and their sensory impact:

• mothership says “you must use open seating”. Local org has limited budget. Result: sound-reflective surfaces everywhere. Concrete, steel, stone, glass. Not even ceiling tiles (for the techy look, who-hoo. Shuddup). So that all the buzzing from the utilities in the ceiling (now under the ceiling instead of inside, the ceiling itself being sound-reflective, too, so you get what, triple dose noise?) is audible. For best effect, integrate the “phone booths” right there, facing the hall, and only give them curtains. This doesn’t work for me. I can deal with open workspaces as long as my back is not to an area where people are moving. But the BS with the cathedral acoustics? No. The oversimplification needs to stop. Not all open spaces are alike.
• people coordinating in open spaces… No, they don’t. One person comes in, mumbles a quick thing about what they want. Target person copy-and-pastes a bazillion of browser links from the desktop to the laptop, then both leave to not disturb others. Didn’t work, others are already randomized by that time. Then the two coordinators might not find a place out of earshot, reverberating back into the glass palace. This does not improve communication. A 3-person office with people actually hacking the same code, that is awesome. Even if somebody gets randomized, now you have a single or maybe two people who get a coffee.
• the H-WHACK system will be terrible. Icy drafts cruising on centered paths, away from the walls, hitting people, but not hitting the temperature readers. On the other hand, pockets of stale hot air. Your landlord won’t do shit for you because they told you it won’t work before you converted the space that way. Right they are. Your building coordination people will refuse to even turn up at “hacker hours” since it’s after their work time. The climate usually changes drastically over the day as sunshine, clouds and darkness transition, not to mention some places do what they say is turning off the entire system “after work”, otherwise known as “time when we can actually write code”. Climate also changes drastically with the seasons. A/C controls in most existing office buildings won’t be able to regulate open spaces across daily and seasonal changes. They weren’t made for it. Your budget does not allow redoing the A/C from scratch. Your company will start moving people around based on their work hours and temperature preferences, based on what they thing is the temperature there this season, right now. Repeat every season change. Now people are placed at random, not in functional groups. This doesn’t work for me. Does it work for you?

Assuming a working open space (rare) I estimate that about 30% programmers actively like the open spaces, 40% will just do whatever corporate says, never evaluating whether it is good or bad for them, and 30% suffer enough to notice. That is for a functional space. If you make the mistakes above you shift this to be worse. Who is calculating the budget against those percentages? Does anybody have better numbers than me pulling them out of thin air? Never seen them outside blank “this is data-driven (and you don’t get to see the data)” presentation throw-ins.

[2] I wrote about programming tool turnaround time here:

“Software development at 1 Hz”, a rant against slow programming tools. This writeup hit a nerve, making HackerNews front page. A lot of people have their attention hacked apart by too frequent too long pauses that are technical (not human or corporate) in nature: https://hackernoon.com/software-development-at-1-hz-5530bb58fc0e