I couldn't help but feel my soul being slowly crushed as I read further on their description of the daily activities. Needless to say, the filter indeed worked out. As someone with ADHD, I couldn't last a single day on a job like that.

[1]: https://engineering.meetsoci.com/mob-programming

I've been in a team that does this. I did appreciate the knowledge share from the expert the first month despite the fact it completely drained me. After awhile, I hated the whole thing and dreaded going to work. I get it works for some people, but I know it is not for me.

> on a zoom call

This would make this about 10 times worse. I wouldn't last a week.

Those grades and work experience were quite valuable to myself.

There are protected classes/categories that can't be part of the employment decision, but outside of those, the employer is free to set whatever criteria they want for the position.

If I run a plumbing company, I could say "all of our plumbers must have a computer science degree," and I can't imagine there's any legal reason I couldn't do that. I'd certainly have a recruiting problem, but not a legal problem as far as I'm aware.

So in the case of plumbers, if a plaintiff can show that you are hiring fewer women because women are less likely to have CS degree—then you would need to show a “demonstrable relationship to the requirements of the job” for a CS degree.

However, this isn’t an issue for software developer positions. A CS degree doesn’t have to be absolutely necessary to be able to perform the job, it just needs a demonstrable relationship to the job requirement. There is also already precedent that a degree in a related field does meet that requirement.

I mean to each their own, but companies - and fellow developers - need to stop forcing others into their way of working. Having One True Way of doing things is always bad. But yes, this may mean there will be a divide in your company / teams, where one part prefers solo work while others prefer group work. Deal with it. Compromise. Let the extroverts work on their own for a while, and the introverts do some pair programming, but don't go all in on one or the other.

This isn't just true with programming. If you like to do things solo, then don't become an airline pilot since they always work in pairs. There are plenty of other places you can work as a solo pilot. Airline pilots work in pairs because, for that type of work, there are advantages to doing so. If a company wants to "go all in" on pair or mob programming, there may be very good reasons for doing so and trying to have a split culture doesn't always work.

Thanks for both of your comments. The mob programming sounds like I would be depleted way to fast.

Culturally traditional management is biased to create the 3 struggling engineers scenario because most management strongly believes that people working on many tasks in parallel is peak efficiency. You see this manifest in places that run the Jira + PR feature mill. Staff that complete lots of jiras and have lots of green dots PRs in their GitHub profile are considered "peak performers"

The fortune 500 is littered with companies full of this anti-pattern. Less so each year though, because if amazing execution on digital transformation matters to the business, to the extent those 3 struggling engineers execute poorly, the competition slowly eats the incumbent's market share.

I love it and it's helped get momentum on things which would typically just sit there. BUT, 30 minutes is definitely my maximum for something like this.... even if we did something minor like make this meeting 1 hour long - I would dread it.

Context: we do have an engineer on-call (on a weekly basis) and they will respond to urgent sentry errors, but the above helps sentry errors with less urgency get moving without being a total buzkill for the on-call engineer to look at ALL of them.

But it does quickly lead to exhaustion.

To summarize: there are three roles, Typist, Navigator, and Support.

The Typist is not allowed to think. They are explicitly described as a "smart input device". For the most part, only the Navigator is allowed to think. They tell the Typist exactly what to type, and the Typist must follow everything the Navigator speaks, to the letter.

The Support only looks over both their shoulders and sets a 10 minute timer after which the roles rotate. Yes, every 10 minutes everyone switches roles.

When working in person, one thing this selects for is people with perfect vision. Elderly programmers need not apply!

Why do I say that? Well, I have computer glasses that let me see my screen perfectly even at my age. This applies to anyone over 40-50: if you don't have them already, I strongly recommend getting a pair of single vision prescription lenses tuned for your normal distance from the screen. Since I use a laptop, these glasses are set for a 20" focus distance. I have two external monitors (one landscape above the laptop, the other in portrait mode to one side), and I keep those at the same 20" distance from my eyes. It is glorious! Everything is in focus, all the time.

If we're sitting around a desk, it's almost certain that I won't be able to read what's on your screen, for the simple reason that it won't be at a distance that brings it into focus (probably much too far away).

Oh, and you may like dark themes and tiny fonts like all the young people use these days. So even if it were at the right distance I wouldn't be able to read what's on the screen.

Mobbing on a Zoom call mitigates the focus distance, but the dark theme and tiny fonts would still mean I can't see your code.

And webcams are supposed to be on all the time so your fellow mobsters can see your face. A nice sentiment, but two problems:

1. I can't work sitting. If I do, I fall asleep after a while.

2. I can work standing, but not standing still! (I'm no John Carmack, who can give an hour long talk without moving a muscle.) I have to move around in order to think and stay alive. So I would constantly be walking in and out of camera range, or stretching, or wiggling around on my Fluidstance balance board, or just looking out the window for a vision break.

A more delicate problem: Sometimes older people need to take more frequent bathroom breaks, and the timing may be unpredictable, especially for someone like me who eats a lot of fiber for intestinal health. Sorry, I may not be able to just "hold it" until the next scheduled mob break. (Apologies for the TMI.)

This whole thing is an ADA compliance lawsuit just waiting to happen. (And no, I'm not going to be the test case; I have no interest in working for a company with these practices.)

That said, I would never want to join a company that has phrases like

> The mob disbands, either to sleep, or to their individual work

and

> [...] full 8 hours of programming [...] minimum expectations [...] additional time is expected to be put in

in what is basically their job description. Also, six to eight hours of non-stop webcam is horrible! https://news.ycombinator.com/item?id=24718640

I went the other way. 42in 4K TV placed further back. Big font. Zero eyestrain.

The main trick is that you have to set up the TV in "Game Mode" to turn off input processing, and also turn off stuff like overscan.

Obviously this setup may not work in a office cubicle or other space-constrained space.

Works fine for in-person reviews in the time of Covid, the other person isn't hovering over my shoulder either. They can stay way back and still see what's going on.

Drug your employees so they appear to be working the desired hours. I can see ethical problems with that idea. The employer should at least be dispensing the drugs for free as a "benefit".

Wildly different experience compared to mob/pair programming all the time.

But don't stop with a diagnosis, get some coaching from an ADHD specialist. There's so much more to it than just attention -- emotional dysregulation, time-blindess, executive function impairment.

It's a whole thing. But with support you can cope with most of it. And most importantly learn to separate the condition from.your character.

Diagnosis can be emotionally helpful— they’re often done by neuropsych evaluation specialists but you should talk to a psychologist or psychiatrist first because evaluation is a few grand, most insurances won’t cover it if you don’t seem very likely to be diagnosed including DSM-V criteria like having significant life changing symptoms before age 12. The testing itself is a few hours of tests designed to push you to your limits for things like working memory, impulsivity, and reaction time. (I was waiting for the tester to say “Reaction time is a factor in this, so please pay attention.”) Parts got frustrating but not like Megaman frustrating.

Depression and/or anxiety are commodities in 80% of those afflicted, so that’s worth paying attention to also.

If you think you may have ADHD, definitely worth it to understand more about ADHD and a diagnosis will help those close to you to understand your behavior.

ADHD medication is excellent from a patient’s perspective. The first-line ones are almost immediately effective. If you don’t like what they do, you can just stop taking them and try another one. In less than a year, you can try most of the known-working medications.

Even if nothing comes of it, at least you know. Knowing is half the battle. :)

And note: it does sometimes make you feel like cheating or something… you will have to arrive at your own conclusions. Suggest a good therapist to help deal with it.

Your partner is worried. So shift the work/life balance to have more life with your partner. Trust the team at work to understand.

Diagnosis from other people does lead to prescription drugs being offered. If someone reading is using chemicals, please pay close attention. Some doctors attempt to prescribe drugs in increasing quantities. That is not the path to sustainable balance. Medications are useful in an ambulance or hospital, they do help in emergencies! But they're not intended to be used routinely for a healthy life.

Peer support is best. Finding humble, open-minded peers can be challenging. The CouchSurfing (now BeWelcome) community is very open-minded and humble. Many church friends are humble. Teaching from the Bible is a reminder of how none of us are perfect, yet God forgives, and shows grace, mercy, and peace.

Some companies try to force concepts like pair programming, mob programming, etc upon their "human resources". It works well for people who like talking & body language, but not for people who prefer reading, typing & listening to music. Personally I prefer reading & typing, and that's why I use Hacker News.

You're not alone, you're welcome here. Interruptions are OK despite the cost of context switching. Diagnosis is not needed, you've already found help. I pray that God will bless you with peace in your personal and professional life, and they'll all catch up to your high-frequency genius ideas soon :)

There is a reason why nearly all good programming languages, standards, platforms and even games are usually started and prototyped by one developer. That is because programming is creative value creation and business/finance/project managers passionately want it to not be, they want it to be a factory and it never was, is or will be that until the initial versions are out. They want to value extract before the value creation, they also try their hardest to make sure no programmer has much power so they are "swappable" which again is not true in product creation, maybe maintenance or once the base is created, but not initially.

Programming is a creative skill and should always be seen that way. Most product developers, game developers and full stack to presentation developers know this and can make some of the best value creation because they can take it from start to finish. Once it is prototyped or first versions, it can be ramped up for value extraction.

When prototyping some new idea that might result in a new product/platform/module/whatever, I tend to iterate faster than I could explain my iterations to any other person, even well-versed developers, let alone average-skilled ones. It is normal to refactor the entire codebase multiple times a day in such situations. The internal reasoning processes that guide these iterations, the probability assessments followed by quick trials followed by another iteration that ultimately lead to a solution are so manifold and dealing with so many particulate details (that are of utmost importance however at such an early stage of a new system) that it is impossible and impractical to discuss all of them with someone. You just have to follow your intuition. Having two intuitions in play at this stage is counterproductive, the friction losses are just way too big.

This feels pretty relatable and sometimes also extends to code review, when another developer essentially goes: "Hmm, i don't like this for subjective reasons, you should rewrite it to be different." even in situations where doing so would have no tangible benefits and the only thing that ends up happening is the development velocity being ruined.

I think that sort of problem would manifest itself both in pair/mob programming, architecture discussions, sprint planning as well as code review, it's not like you can easily avoid it altogether, unless you avoid the people in question entirely or provide pushback against nitpicking and bikeshedding, which may or may not be viable.

That's why code review process must have a guidebook with a rule "it's on the reviewer to show why the suggested change has a tangible benefit".

Agreed, yet you're implying that:

  - there must be a guidebook in the first place
  - that it must actively be followed

It's unfortunate people are mostly conditioned to not oppose: whether to get branches landed faster, or simply because of the imposter syndrome, but some of us who are good at opposing and saying no sometimes struggle to find the right balance.

My goal when reviewing is to help others learn something new, which is why I'll sometimes share a personal, subjective preference for an approach (with "subjective" meaning that there are pros and cons to either approach with neither being better in every circumstance, especially in a legacy codebase like they all are).

I am trying to walk the fine line between teaching someone something potentially new, and not dumping on their velocity or self-confidence. I love it when people acknowledge the idea and say "nope", yet I understand that many won't do that, so most of the time, I stop myself from even sharing my subjective preference.

Outside of character, it requires building trust between people and not being out there to "prove your mettle", but to build stuff together. And with so much churn in jobs and remote work (I haven't met my new coworkers of 6 months yet, and I haven't met half the previous team either), that's sometimes hard.

This is literally the problem with interruptions and open-office floor plans for knowledge workers. There's no effing way we're all ADHD-addled goldfish. Decades ago my senior cube-mate liked to tell non-engineers who walked into our cube asking questions unannounced: "like I tell my wife, we're in here balancing a stack of plates in our heads, and you just walked in here and knocked them all down."

You're right about it being a house of cards, and the industry isn't doing us any favors selecting for people who can chat about it vs. arrange the metaphorical cards high and get the hard things done.

I struggle with this during technical interviews. I can't think deeply and explain what I'm doing at the same time. Since talking is required it means that I can't think.

The difference is the matter of degree.

I've been following a very similar path as you describe in your last paragraph, and I'd be very curious if there are other similarities that differ from how others write code.

By chance, do you struggle with eating sounds in offices to the point where you panic?

Thankfully the CEO of the company wasn't much into it, so he forced our pointy-haired boss of a manager to make it optional.

The whole team unanimously decided to never do it again.

The 8h shift looking at a shared screen was absolute terror. No privacy, a lot of machismo with people claiming "I don't need to look at the documentation", terrible productivity when pairing with certain employees that didn't really took the work seriously.

Mandatory pairing simply doesn't work, period. It's like they say about therapy, wanting to do it is a pre-requisite for it working...

I like continous pair programming, but not because I actually continuously pair - if someone wants to watch me work, or is too green to go it alone quite yet, its fine. But usually we only pair when it makes sense to, i.e. we are at the beginning of something and figuring out what to split up.

If management tried to force real continuous pairing down everyone's throat all the time....yeah no. That management should be fired, they don't understand how people work.

Yes. Especially ice chewers. Which one PM thought was hilarious as he worked through a cup of just ice.

Not particularly, but having to deal with distacting sounds, pressure to focus, and feeling trapped in a cubical can definitely make me uncomfortably anxious.

Not to be rude, but the stereotype of the software developer is fast becoming one of fragility. A low wage worker spending their day working a fryer or a guy at a construction site would be thrilled to have such working conditions to where their biggest problem is someone eating too closely while making $100k+ per year in the air conditioning.

Why is it so terrible for anyone to want to work in a specific environment that they find comfortable? Why do you think that the ability to work as a fryer or construction worker is somehow “better”? Why are people who have the capacity to either ignore or tolerate bad working conditions and continue working considered morally superior?

As human beings we’re all so different and unique in our ways and preferences. We are at a stage in our evolution where we can provide people the kind of environment that they prefer to work in; even let people choose the kind of body and gender they think works best for them. Why is that so bad? Can’t we just let go of the toxic masculinity involved in such comparisons?

I am not even touching on the nature of knowledge work itself which has very little to do with physical toughness and everything with being in environments conducive to problem solving. Please just stop with these rubbish admonishments.

For some people, it’s quite literally perceived as someone’s kid screaming next to them.

What people forget is, we don’t have a choice. People who have a disability will have to deal with it no matter what job they do.

It’s like yelling at a person in a wheelchair to stop bitching about the lack of an elevator in a three-story office building because they have a “good job” and getting up the stairs isn’t a big deal because you do it every day.

This analogy may sound like an exaggeration, because there is no way you can comprehend something so minor and trivial could be a problem. And that’s kind of the point. It’s extremely difficult to understand something you haven’t experienced.

Most people jump to the conclusion that these things aren’t a big deal and they’ve seen people lie about it to manipulate people. Therefore, a person claiming to have a disability that isn’t obvious is lying to get things they don’t deserve.

Not everyone has a fully working brain or body. :(

Of course I'm happy to work in software rather than in fast food. And I think many people would prefer working a desk job rather than a physical job. But humans get used to things. I remember my time working in fast food, but it's hard to remember exactly how I felt and say "Wow, working in an office is way better" every time I encounter something that I don't like in an office. I also think that just because I have better working conditions now doesn't mean I should stop trying to improve them.

Oh my! People complaining about things that are relative to the situation they are in! How fragile!

I think you are mistaking in believing you have trouble explaining because you use a different thought process.

For almost everyone of us, figuring a complex system means you deconstruct the system in small pieces, understand the small pieces, construct the system again in your mind along with making a kind of mind diagram about how it works. But when it comes to explain to others you use a different process than you used to figure it out. You already have that mind diagram, so you proceed like in most text books or in articles by already providing the big picture and going in details only when you feel is needed.

I also write good code, but it doesn't have anything to do with attention or memory. You write good code because you believe it's important to have something that is working well and also will be readable and maintainable. And writing good code is something almost every programmer can do if the working environments permits - i.e. they are not valuing churning bad code fast over writing good, reliable code.

For the most challenging tasks, say, coming up with an original solution to an unsolved problem, I think it's better to alternate deep focused thinking alone with group brainstorming. But you really need that meditative alone time to gnaw at difficult problems -- for me it tends to be in the shower, or during a walk. That's where you have those awesome "Aha!" moments.

On the other end of the scale, certain mundane/repetitive/trivial tasks really don't warrant pair programming IMHO. You're spending two brains on something that really takes 1/4 of a brain.

The ideal case for pair programming, IMHO, are those tasks where you can visualize the general path forward, but where there are significant challenges wrt implementation such that another pair of eyes can really provide insight. For example, say you have to implement a module, and you have a general idea of what it needs to do, but the overall decomposition and abstractions involved may be inchoate. While I think a fair amount of "implement this new feature" type of stories fall into that category, in my experience that comprises only ~40-60% of the total workload.

The above mostly applies to pair programming with two fairly equivalent/experienced developers. I agree with others who have noted that it's a fantastic training mechanism for new/junior devs. And then, there are various special case scenarios that justify it, as in, you have a problem with X and need to pair with an expert in X to resolve it. IMHO, these are best done ad hoc rather than via a formal process.

That’s a fun way to put it. When encountering the usual brain–computer metaphors, I’ve always felt like I relate more to the Turing machine scanning over its strip of tape.

It’s a trained skill tho.

If you want me to explain code as I see it, I'll start in the middle of a function, where you have no context what it happening and jump to another line of code that is two functions removed. Repeat. You will have absolutely no idea what's going on as I flip through tab after tab of code.

My brain does not like doing things in order. I have to force it. Hence the processing overhead.

My friends find it entertaining to listen to me tell a story, because none of it is in order. I frequently backtrack or go down "irrelevant" paths, before returning to one of several previous threads.

Fortunately for this comment and the second and third novels I'm working on simultaneously, editing exists.

You seem to be explaining things from the point of view that your different way of thinking is a problem for others rather than an opportunity for them to grow and learn. That's kind of odd...

Personally I think it would be very interesting to work through code in that way, and I don't think it would particularly detract from my understanding.

If you'll indulge me, I'll try to explain using part of a story I wrote as an example. (It is a furry story, hence the animal body language.)

——

## My explanation

“You went grocery shopping?”

“About two hours from now.”

“You can relax,” he says after he sets the kettle down. His ears perk up, staring at me intently, and I steel myself. “I took the week off.”

“I didn’t expect you to be up so early.”

Then I notice the grocery bag on the table. Breakfast probably being oatmeal or toast; we were out of eggs.

“You okay?”

——

Who is speaking at each section of dialog?

1, 1, 2, 2, 1, 1

——

## Original

“Yeah,” he replies sheepishly. “You got three minutes to get dressed while I get your coffee.”

“You can relax,” I say after he sets the kettle down. His ears perk up, staring at me intently, and I steel myself. “I took the week off.”

He breathes out slowly, but his tail gets more frazzled. “And you were going to tell me this when?” he says with restraint.

“About two hours from now.” It’s my turn to look sheepish. “I didn’t expect you to be up so early.”

“Thought I’d make you breakfast.”

Breakfast probably being oatmeal or toast; we were out of eggs. Then I notice the grocery bag on the table.

“You went grocery shopping? Did you take your anxiety medication?”

——

Bonus round: What does “You okay?” from the previous section refer to?

There was a minor accident in the kitchen that let to this discussion.

——

This is a bit contrived and I mixed things up more than usual because understanding creative writing on paper is easier than explaining code over zoom.

I think the GP post (GGP?) about the utility of sharing expertise is a good one, though I think that can be done w/o it being 100% all the time as well. It probably also depends on the nature of the tasks and complexity of the system. There may be jobs that really do optimize better w/ a lot of paired programming, and I'm just not a good candidate for those roles. We all have different niches in which we achieve our best performance.

- Were you officially diagnosed with ADHD. I never went to a doctor, but in the last years I had growing assumptions I might have ADHD or Asperger (or both).

- Do you follow certain strategies which made communicating your thoughts and ideas easier and/or better?

Diagnosed bipolar 1 recently. But I was diagnosed as ADD as a child thirty years ago. ADHD is a popular addition to the standard Bipolar feature set.

> Do you follow certain strategies which made communicating your thoughts and ideas easier and/or better?

Not in a way I can easily teach. I learned my social skills late and had to study people to understand them. I take all of the inputs and outputs of a known person and mentally visualize what their internal state is. Then I play out how different phrasing will be received.

Whatever part of the brain normally handles social interaction is broken in mine, so I use logical thinking to run other people's brains in a virtual machine.

I guess I should get an official opinion. Nevertheless, diagnosed or not, virtualizing people seems like it could work for me, although it seems to take a significant amount of time for each person to work.

IF my dad IS talking about (politics|religion) THEN do not enter discussion.

Pairing may be good to some degree for knowledge sharing but it works against good architectural design, which requires the kind of holistic thinking you describe, as well as kind of micro-iterative whittling away at the problem that interactive pairing couldn't ever achieve. In addition, the n^2 communication lines yield the worst effects of Conway's Law https://en.wikipedia.org/wiki/Conway's_law

Nearly all of the computational problems we face in industry (save a narrow class of specialty problems) can be pretty easily articulated in the "macro" sense: "oh, we'll just have this distributed actor invoke that one and he'll reply with the blah, blah state".

Look, we just paired and collaborated on a design, cool! But the reality is that none of the hard parts have been solved. The hard parts are always the unanticipated errors, edge cases, invariant violations that beset every system--a large set of issues that need to be made airtight when it comes down to actually putting the code and tests together, and these require the holistic thinking you're talking about or either you get subtle bugs or otherwise a mess is made in the code.

As an industry we've gone so hard on coming up with social processes to "knowledge share" (pairing etc) and do things like audit for defects (code review process), but all of these are ultimately compensatory measures for bad design and bad code; and, in fact, as you suggest, they kind of encourage and trend toward bad code.

A different approach to building systems socially would focus on the code being decoupled and articulated such that the barriers to entry would not _require_ pairing and these other processes. Decouple and compose components that can be understood at face value and in situ.

But this is very hard and requires extensive practice and expertise, something our industry isn't keen on talking about. We like that quick race to "expert beginner" wherein we can say "Phew, now I'm an expert". So instead of focusing on mastering these we go for least-common denominator processes, which if you think about it is what pairing, and many of our processes are,- least common denominator.

The truth is we're social creatures, so I don't think we'll ever get out of this state. Social processes will win not because they optimize the problem space but because most of us love and crave the interaction. My only lament is that we don't call the spade a spade and we try to argue that these processes are necessary for optimization when they really impeded optimizations and create downstream frustration and limitations.

IMO, pair programming is most useful for short design discussions and mentoring, like explaining a better way to architect a feature to a junior engineer. I look back on these experiences fondly, and this type of collaboration helped me grow a lot as a developer.

I don't feel like I get the concentration and focus required to "put the whole code implementation in my head" when I'm pairing, so I don't really see how it can be used 100% of the time to build systems efficiently.

And regardless of whether it's a good way to work or not, many engineers just won't want to have someone looking over their shoulder 24/7. That kind of environment would drive me mad. I need to be able to drown out the world and bury my head in the code, and most of us don't work on code the entire day. I like having the freedom to read an article or browse the web for a bit whenever I want to fuck off.

Pair programming and mob programming are definitely not for me, and there's no way I would take a job that requires doing either most of the time.

That said, there are definitely cases where sitting back and thinking through a design is a really good idea. In my experience, it's 1/10th of the job.

By domain expert I mean someone who has worked in a single domain for many years. Lets say you have written healthcare backend software for 10 years, then if they tell you to design a new healthcare software system then you will be able to predict most future requirements the system will have even if they don't spell those out explicitly to you. Sometimes laws changes and you have to redesign stuff, but having to adapt code due to new laws isn't a common occurrence.

Edit: And 10 years in a single domain really isn't a lot of time. In a sane world you would be called an apprentice until you reach that level, that is the only way to make robust products. This is how almost every other field works, but in programming people seem to think that such expertise is impossible, at least at scale.

Only if changing requirements are a requirement :)

However, solo thought doesn't necessarily activate all neural pathways that will solve problems.

Much like explaining problems to someone else often causes you to realize the bug, social interaction activates communication, idea formation, recall, association, and error checking neural pathways that don't necessarily fire when thinking in isolation.

So for 100% pair programming: again with the dogma in IT. 100% code coverage. TDD. Strict agile/process alignment.

Stop with the dogma.

> If this comment is a bit rambling, you know why. :)

Everyone has struggles with communicating clearly don't they? Do you think it is possible that we put too much emphasis on apparently typical and non-typical way of thinking, with one pathologised?

Would ADHD really be noticeable if we were living in a medieval agricultural society?

I'm speaking as part of a generation where boys grew up being medicated for what I saw over-diagnosis of ADHD.

Your confusion is very understandable because most people don't know what ADHD is. Some of the symptoms overlap with immaturity, so people who are not qualified to tell the difference will frequently misdiagnose the problem.

If you want to understand ADHD, this video for parents of ADHD children will explain. https://www.youtube.com/watch?v=YSfCdBBqNXY

You don't need to watch the entire 3 hours. The first 10 minutes should be fairly enlightening.

My genuine question - Is it possible to have ADHD and be a coder? It’s just that coding requires so much focussed attention over long periods. If you are enjoying a career as a coder I’m inclined to think either the ADHD is mild or treated very effectively? Or even that treated ADHD actually makes you better than the median somehow?

Now, that said, there is a new movie, Everything Everywhere All At Once, and if you take this title as a stand in for ADHD, maybe you can see that while this way of living can be overwhelming it also allows you to have a pretty good overview over systems and how their components interacts very fast. I think that's what many ADHD'ers are actually very good at, grokking code bases or the gist of things very quickly. Systems thinking in general. Also quick recall / association chains...

Also, on average, the higher your IQ, the later in your life your ADHD diagnosis will be (see this video on adult ADHD https://www.youtube.com/watch?v=dVDhYtQkuO8). Your other abilities can compensate somewhat for your ADHD. Also of course when battling this condition you will build many personal tools and habits that neuro-typical people will never have to do, so in that sense you also might have a leg up in certain situations.

I'd say professionally the biggest problem is not so much on a technical level, but more on an emotional / impulse control level. ADHD'ers can come off as brash, speaking their mind freely, not being able to just put that comment in when it's better to shut up.

A person with ADHD will have a tendency to get distracted from the task they're supposed to be working on, and will instead work on other things. That's not necessarily bad if those other tasks are important. Perhaps counter-intuitively, the lack of impulse control may even lead them to hyper-focus on a task... just maybe not the one they were assigned.

People without ADHD also get distracted, but they have the impulse control to better resist tempting distractions, and the memory to remember to return to their original task after unavoidable distractions.

My entire view of ADHD changed when I saw a video for parents of children with ADHD a few years back. This is one of my favourite HN comments of all time: https://news.ycombinator.com/item?id=17889156

It has way bigger consequences outside of work for me. Things which you are very passionate about are easier to focus on than things you are not, regardless of AD(H)D.

When I learn about and talk about a system a visual representation of the flows of data and function calls is playing in my head. I get an overview of the system and what it does. Think "mental model". I "see" that this service calls that service to get that piece of data, which it gets from that database table and it all flows over there to do that and suddenly it all makes sense. I recall those high level flows for a very long time too and I have no idea how I do it. It just happens. I hope my mind keeps doing this for a very long time still.

I can talk about it and it makes perfect sense to me. There are other people at the company usually that share the same knowledge and understanding and if we speak a similar enough language we can communicate well. And then there are people that do not seem to get this level of understanding, even after prolonged periods of working on the same code base. Ever. When you ask them to explain to you how the systems and modules interact, they can't.

And then you draw some simple graphs of this service and that service, and this database here etc. and it finally clicks for them. They could not synthesize this from code or written text. They only ever saw the local view of the module they worked in. Overall, more abstract flow of information and modules was lost to them. You have to actually visualize it for them.

Note that I am not talking about "visual programming" as in drawing UML like diagrams and such to actually program. It's purely about showing data flow and call stack and such. Usually I don't need to draw this for myself as my head does it for me and it works really well with statically typed languages without any magic going on where I can just have the IDE navigate to exactly the right places, find all the code references quickly and accurately etc. One time (a looong time ago) I actually threw together a quick script to generate a graphviz file for the call graph of some system based on some proprietary database's stored procedures that I had to quickly come up to speed with and that nobody was there to explain to me. I think it printed out to like 15 pages that I taped up on the wall next to me just to make sense of it. No IDE support to click through from one procedure to the other.

Discussing code for linked lists for example, having the box and pointer notation for what happens and scenarios very helpful!

[1]<->[2]<->[3] to [1]<->[3] means changing [1]'s and [3]'s pointers and freeing [2]

Granted, code requires far more details than many conceptual explanations, but it is still one.

Google “crazy conspiracy board meme” and you’ll have a good analogy for what’s happening. If I start writing it down, things randomly disappear from board. Which requires me to look at the gaps and fill in the blanks.

You can imagine what this looks like from the outside. My dad has interrupted me so many times with “get to the point” and the only response I have is “working on it.”

The funny thing is… I’m an author and prefer to work with text.

- Learning CBT from a book with the help of a therapist to guide me. https://www.amazon.com/Feeling-Good-Handbook-David-Burns/dp/... The core of it is in the first few chapters. Never read the later ones once I got the concept.

- Learning how to have realistic expectations about what I can do day after day.

- Prioritize self-care and optimize for long-term performance over short term success. This includes going to bed earlier than I want. :(

- Working with my manager to have the proper accommodations. In my case, strict 40-hour work week, no work interruptions outside of that, and time off as needed.

I’ve needed accommodations less since things have evened out, but I’ll never be able to do on-call.

Any time I get too distracted and drift off there's someone to nudge me back into focus. Occassionally I'll have to apologise and just say, "Sorry I didn't catch any of that" which sometimes takes a lot of understanding on their part to not be offended.

There are some days where I struggle to explain things which is very frustrating especially for architecture type issues. I also struggle to actually build anything from scratch, and definitely have a brain more wired for destruction than creation.

Secondly, you need to find an understanding workplace. The best places I've worked have been understanding of the fact that some weeks they'll get less out of me than a freshly hired junior because other weeks I'll do some very good work.

It helps if you can have a niche, and helps if you can start off making a good impression. For me that niche is more of a bug finding and security focus. On weeks I'm feeling very motivated I can spend my extra energy being useful finding security holes and general bugs. Good managers will see the value from that.

If you tasked me with writing even the most basic "todo list" web-app from scratch you'd probably find me after a week deep in analysis paralysis still deciding between frameworks having not written a thing, but give me the simplest "todo list" web app even one that's too simple to have bugs I'll have found something wrong with it before the day is out.

But everyone is wired differently, so your niche might be the building side. Just work out from experience what your strengths are and lean heavily into them, or at least strong enough to get a reputation than you're good at your job, but not so heavily you get pigeon-holed in a role.

And if it's just not working for you, don't be scared to just quit and find somewhere else. There are good and bad workplaces, and a surprising amount of advice is from people who have only ever worked 1 or 2 jobs at most so don't actually necessarily have the experience of different workplaces to be able to back up some of their assertions so take all advice with a pinch of salt and work out what works best for you.

Motivation- you need to actually align your tasks with an actual concrete personal goal or sense of accomplishment. And be invested in the work. Lacking that, you'll be dependent on external stressors to get anything done, which will reflect poorly on you if it gets to that.

One of my issues with motivation is what you mentioned: I really really struggle to get invested. Things that are "work" seem to live in an anti-motivation bucket, regardless of how organically interesting they may be to me outside of a work contest. I'm in my 30s now, and I've been doing this my whole life and it is killing me. It takes a tremendous amount of effort and an extremely imminent deadline to get me to start anything. This (ostensibly) runs completely contrary to my self-concept and value system, but the motivation problem permeates every fucking inch of my life, and always has.

I can read this back and recognize a defeatist attitude, but I don't know what else to do.

This has helped in two major ways. I've let go of the idea that the hyper productive days are my natural state, and that the 90% of the days that aren't there are some kind of failure. I've also built my career to avoid having daily accountability and prefer weekly/monthly.

That mindset shift, separate from the daily "how do I get stuff done" tactics, has really helped prevent the kinds of negative spirals that adhd can put me through.