22 ms·

As an engineer for 10+ years with pretty severe ADHD (unmedicated, I cannot usually even read more than a few pages of a book before either losing focus or feel

by dkh 3y ago

As an engineer for 10+ years with pretty severe ADHD (unmedicated, I cannot usually even read more than a few pages of a book before either losing focus or feeling drained) I have always been aware of how much my performance fluctuates based on the cognitive load of dealing with the code I am currently working with, and how it is displayed. I half-jokingly tend to describe it to people as having a "small brain buffer" where while I can understand (and design and implement) very complex things, it is easy for me to flounder when debugging if I feel unable to visually see or mentally hold the entire problem in my head at once. This is especially true if the code isn't mine. It is for this reason that I try to write what I feel is very obvious or self-explanatory code, why I try to keep functions/modules as simple as possible and ideally not longer in length than I can see on my screen at once (when possible), and why I almost exclusively join small/new teams who don't yet have an enormous codebase that I'll have to wrap my head around. I am never done tweaking the UIs of the editors I use to maximize my ability to work around these things.

bestouff 3y ago
Hey you are a younger version of me ! I completely agree, and I am now very selective wrt where and with who I work and I still love my job.
deleted 3y ago
[deleted]
Netcob 3y ago
Same here. I try to see the bright side, where I am basically forced to write "clean" code because anything else just doesn't fit my buffer. And I feel a kinship with current LLMs with small context sizes.
- elcritch 3y ago
  It's funny, my input buffer may be small and it's a large mental drain to read busy code (ADHD con), however once I grasp how a code base works it's just there (ADHD pro). It makes me wonder if it's related to the hunter-gatherer origin hypothesis. In that scenario covering large tracks of land was beneficial and that ability can be used to mentally map code. The flop side this also leads to distractibility and boredom paying attention to monotonous details.
  - dkh 3y ago
    This is true for me as well, but the amount of time/effort it takes to get to that point can vary wildly, sometimes being a bit prohibitive, other times never fully getting there for the duration of the job. If I wrote the code, or was present for most of its growth, or have spent whatever time it took in this instance, I am pretty damn efficient with it indefinitely, as long as I don't for whatever reason take a huge break from working with that codebase. (As a ZFS fan, the silly analogy for my brain that I half-jokingly give people here is that I have a high amount of L2ARC)
- dkh 3y ago
  I did have this weird lightbulb moment a few weeks ago where for a moment I felt like an LLM was the perfect parallel to describe how my brain worked
rightbyte 3y ago
> flounder when debugging if I feel unable to visually see or mentally hold the entire problem in my head at once Surely this is a general problem and not specific to programmers with ADD? Or do you mean you are relatively worse at "needle sting debugging"? You second paragraph is just sane things in general. I wish your mindset was more common among my colleagues ...
- dkh 3y ago
  Relative to my peers I have often found myself to have lower tolerances in these areas. It sometimes surprised people when I felt something was complex (to work with, not conceptually) when they did not, or at the length of time it could sometimes take me to fix something that involved digging through a lot of code.
- VHRanger 3y ago
  ADHD is a quantitative disorder, not qualitative. To some extent, everyone gets mild versions of ADHD symptoms, especially if tired/bad nutrition/no exercise, etc. ADHD is when these symptoms harm quality of life significantly across many domains and since you were prepubescent (it's a brain malformation, not a series of bad habits)
  - steve_adams_86 3y ago
    To expand on that, I think it can be clarified somewhat by describing the mechanism at work. People without ADHD have a generally-working motivation/reward system which is undergirded partially by dopamine. This neurotransmitter is relatively low in ADHD brains, which seems to lead to signal:noise issues. That’s likely a cause of having a highly distractible baseline state, but also leads to bursts of dopamine seeming more salient and arousing. You have a harder time regulating motivation and evaluating perceived rewards. A lot of what happens in the brain is based on relative states. If your dopamine is always low, something making it spike will seem more interesting than it necessarily should. If your dopamine trends higher, you’re going to have an easier time regulating interest, motivation, and an ability to transition through things you need to do — particularly things you don’t want to do. The inverse of a dopamine spike is a dopamine drop. This impacts the brain in important ways as well. In a person with ADHD, going from a high to a low can often cause serious declines in mood and energy. In a more typical brain, the same effects are present but less severe. So while these are all normal challenges people face because they’re the product of the same brain mechanics, a low dopamine baseline makes these mechanics more extreme in people with ADHD. They are primed for distraction and clinging to things which increase their dopamine. This could be video games, relationships, drugs, hobbies, etc. It could even be work too. They’re also primed far harder falls from their highs. This extreme oscillation often means some aspect of life suffers due to a lack of balance. That’s why it can be a disability. Hopefully that helps explain the quantitative aspect.
giantg2 3y ago
"and why I almost exclusively join small/new teams who don't yet have an enormous codebase that I'll have to wrap my head around." How do you find these teams? In my 11 years, I don't think I've ever found myself on a greenfield project.
- dkh 3y ago
  I live in Southern California where there was no shortage (until recently, at least) of very early-stage startups, and for years I exclusively used startup-focused sites like AngelList (now Wellfound) when jobhunting. The largest startup had 12 people when I joined. I worked for a company of 40ish once, but they weren't primarily a tech company and engineering consisted of only 3 people. I should perhaps disclaim that while this worked perfectly for me for close to a decade and I was never without work for more than a couple weeks at a time, I have currently been unemployed for a few months and have had a considerably more difficult time than at any point in the past.
  - TylerE 3y ago
    Going with, in general, a company with less than 50 employees doesn't have to meet many of the requirements larger ones do when it comes to things like the FMLA.
    - dkh 3y ago
      Yeah but the demand for talent was such that, for at least a long time, the benefits and perks at startups usually exceeded those of the bigger companies. This may not be the case now, but I still think what you describe is not true often enough to be considered a general truism
      - TylerE 3y ago
        Not true enough? It’s literally how the laws are written. They exempt companies with fewer than X employees, where X is almost always 50
carlmr 3y ago
>it is easy for me to flounder when debugging if I feel unable to visually see or mentally hold the entire problem in my head at once. So much this. Fuck OOP-inheritance-thinking for spreading implementations to so many files.
- pxc 3y ago
  I also find this splitting-out that happens with OOP extremely unhelpful. I'd never considered that problem being exacerbated by ADHD, but it makes perfect sense.
  - carlmr 3y ago
    The opposite to this: sum types (enums with values). You have all the logic in one place, and if you forget to handle a case in most languages you're forced by the compiler to be explicit.
    - pxc 3y ago
      In my first job after college, we had codebases that took both approaches: an OPP-y Java codebase with lots of inheritance and some FP-oriented codebases that used Scala case classes. As a novice, I definitely found the case class handling easier to browse and understand at the time. The OOP stuff can be made a little easier to work with if your editor can show a lot of buffers at once and makes it easy to search through buffers. Trying to just flip through all of those files with tabs would have been really hard for me.
vanderZwan 3y ago
> unmedicated, I cannot usually even read more than a few pages of a book before either losing focus or feeling drained Tangent: ADHD is strange. I have it too, and yet when it comes to reading my symptoms appear to be the exact opposite (when I was younger I could not stop reading books until I finished them, even if I ended up skipping an entire night of sleep for it). I wouldn't be surprised if in the next decades, as we learn more about it, this diagnosis will split into multiple different comorbid disorders with overlapping symptoms.
- patmorgan23 3y ago
  Recently I've heard ADHD described as "the inability (or weak ability) to direct attention" rather than a lack of it. So hyper fixation could be a symptom.
- flir 3y ago
  Already has to a degree - hyperactive type and inattentive type. But you've also got to consider personal taste - hyperfixation happens when it's something you're interested in. Someone else might hyperfocus on video games, or trawling ebay, or researching a topic.
  - dkh 3y ago
    I am famous for "ratholing" for hours on some specific thing that caught my interest, usually with little sense of the time that has passed, and almost exclusively on problems that aren't at all what I'm supposed to be focused on at the time
    - deleted 3y ago
      [deleted]
  - eyelidlessness 3y ago
    Not a disagreement, more of a yes, and: “interested” may not necessarily be personal interest, and the subject of hyperfocus might not be a personal interest. It can also happen manifest, for example, as obsession with solving some work problem or chore which isn’t appealing at all until begun. Or even some unrelated yak shaving tangent that fits none of these categories.
branko_d 3y ago
> I half-jokingly tend to describe it to people as having a "small brain buffer" The good news is that "smallness of bran buffer" doesn't matter very much if you are trying to implement anything non-trivial. Most useful software is so complex that it's impossible to keep all of it in your head in any case. But we can divide and conquer complexity without holding too much in our limited human heads at any single moment in time. The real art is how you divide and conquer. Having a bigger "buffer" merely delays (slightly) the point at which you have no other choice but to start doing just that.
- dagmx 3y ago
  I disagree. It really does matter if you have any afflictions that exacerbate it. It maybe doesn’t matter for relative performance versus other developers but it does matter for the individual. Having frequent context switches just to keep on top of your work can be really draining. How much it matters also really depends on the languages you’re working in. Taking a couple languages I use regularly for example: Python (or any dynamic language ), as much as I enjoy it, can be a nightmare because of how dynamic it is. You have to keep way more of any given app in your head at a time. Rust by comparison (or any similarly static language) is much easier for me to just focus on the very local code without caring about the rest.
  - formulathree 3y ago
    Modern python is no longer dynamic. Type checking is a big part of python now. Python also has ADTs which match it in power to rust.
    - sneed_chucker 3y ago
      That's great if you're in a codebase at a workplace which enforces python type annotation checking. Unfortunately, I can tell you from experience that out in the real world, at fortune 500 companies, there are millions of lines of untyped Python doing critical work while being full of subtle type errors which should be compile time errors but will rear their heads as runtime errors when it's least expected.
Natuerich 3y ago
[dead]
npunt 3y ago
This idea of a 'small brain buffer' is why I love writing small atomic notes in wikis [1]. It lets me break problems down into simple pieces that I can later assemble upward in abstraction, rather than try to hold complex ideas in my head and compile them together in one big document. The buffer waxes and wanes, and I need to be able to adapt my writing process so I'm productive no matter where it is at the moment. [1] https://notes.andymatuschak.org/Evergreen_notes https://notes.andymatuschak.org/Evergreen_notes
- tomjakubowski 3y ago
  I've been doing this too in Obsidian and really like it. Notes can be as short or long as feels right. If they need to grow they can grow, sometimes they get split into sub notes. I have notes with titles like "Cardboard furniture", "Staging patch changes in VSCode", and "Hilbert Transform". Some are one or two sentences, some are more like essays with subheadings. Small notes tend to have one or two links to other notes. Longer notes have more links and tend towards centralization (eg all booking info about an upcoming work trip). Search makes it easy to find the notes that don't have links.
  - vogon_laureate 3y ago
    It's been a game changer for me. I always did this anyway in other Notes apps, but Obsidian just does a great job of making it feel like it almost prefers you to write notes like that.
  - npunt 3y ago
    Yep, Obsidian is the best! Two patterns I use a lot to help with this small brain buffer problem are collections & streams. Collections (sometimes called 'Maps of Content') are sets of internal & external links or resources around a particular topic, e.g. 'Self Deception', 'Creativity', 'Air Quality', etc. The page names represent the topic so they're easy to name, and if I can't find a page I go to these first before search. Streams are pages with date headers that contain small notes around a broad topic. For instance, 'Passing Thoughts' are random ideas, 'Story Prompts' are ideas for stories, and 'Inbox' are links to read and any notes I have on them. Streams do three things for me: 1. I don't know how big an idea is until I write it, and this stream pattern lets me optionally break ideas off into their own pages if they get to a certain level of size/complexity. 2. I can quickly capture without having to create a new page, since I'm at ~2000 now and each subsequent page makes search less effective. 3. I can avoid the challenge of naming pages, which is often harder than it seems. For instance, I've taken to naming certain pages like Andy M's evergreen notes style of declarative claims/statements, like 'Recognizing our influences empowers our creativity', 'The curiosity driving information addiction may be due to a sense of deprivation', and 'Good ideas deserve good stewards'. To do this clearly, concisely, and scoped correctly is its own challenge and worth the time investment because it really lets me build on strong foundations, and it prevents similar pages from proliferating in search by being easy to find.
devjab 3y ago
Interestingly I do the same as you, partly because the single responsibility part of SOLID, but also because it just appeals to me to write clean easily understandable code. It’s for different reasons than you, however, my ADHD brain can “buffer” massive amounts of code… for a while. So I mainly write things simply because it’s much easier for me to “get back to” after 6 months, well, and because it’s clean code. I think it’s interesting that we end up with the same sort of code architecture though, despite not being affected by our ADHD the same. For me the real struggle isn’t focus or “buffer”, it’s when things are boring. For almost all code work, even debugging, my hyperfocus grinds into gear, and if I’m left undisturbed I can quite literally work for 10 hours straight without eating. I don’t, because there is a bill to pay after doing so and I’ve worked on myself for decades to the point where I know to take breaks, eat and go home, but the hyperfocus is there. Until things get boring. Luckily this is rare with code. Not so with everything related to the process of being allowed to write code. I try to work in places where the process people bother you as little as possible, and if I can avoid it, I’ll happily go through the rest of my career without ever pretending to listen in another standup meeting ever again.
- deleted 3y ago
  [deleted]
rpastuszak 3y ago
> It is for this reason that I try to write what I feel is very obvious or self-explanatory code [...] I don't have ADHD, but, for different reasons, my brain seems to work in a similar manner. And, I have developed coping strategies similar to those applied with people on the ADHD spectrum [1][2]. My anxiety around coding has reduced a significantly when I learned about TDD and started writing code made of very small, composable chunks. I even use the same "small buffer" metaphor when talking about this! I know that some people with ADHD use the writing tool I built for myself. If you have a moment, feel free to give it a shot and let me know what you think: https://enso.sonnet.io https://enso.sonnet.io (the web version is free, and has complete feature parity, no need to pay me) - [1] https://sonnet.io/posts/hummingbirds/ https://sonnet.io/posts/hummingbirds/ - [2] https://sonnet.io/posts/sit/ https://sonnet.io/posts/sit/
- naikrovek 3y ago
  > My anxiety around coding has reduced a significantly when I learned about TDD and started writing code made of very small, composable chunks. you definitely do not have ADHD, then. I find these absolutely impossible to trace through when I want to find out what a program is actually doing, in reality. if I have to find the actual logic used in main or whatever event handler, and it's in a function called by a function called by a function etc., then I will forever despise the developer who felt that this was anything approaching an acceptable design, or even an acceptable idea. codebases like that are impossible for me to absorb. put the logic where it fucking goes, inline with its use! right there! nowhere else! don't nest it behind abstractions you don't NEED. functions that are very small and used in 100 places in the codebase should be inlined in the source code so I can read it. there is no function used this much in an application I've ever even considered working on, anyway. I always prefer to copy and paste a little bit of logic around than to wrap 5 lines in a function and call it from everywhere. if the function is 100 lines of complex code, put it in a function and call it ONLY if it is used in more than 2-3 places, and NEVER if it is only used once. today's "best" practices serve only to shut me and others like me out of participation and are exclusionary. this does mean that I have to take the time to find very good names for everything, which takes time, but always pays off in readability, for everyone, not just me.
MSFT_Edging 3y ago
I relate to this, one reason I avoid IDEs is the "window" where you can actually see code is so limited. It feels like coding through a paper towel tube. I'll make my life way harder in order to optimize the view of the code.
sodapopcan 3y ago
> why I try to keep functions/modules as simple as possible and ideally not longer in length than I can see on my screen at once (when possible) This is the paradox of "readable" code. Each person has a different definition of it. I also prefer to write as dumb code as possible (well, these days I do, I of course tried to be extra clever in my earlier days). But for me it's the jumping around that makes me lose focus. My limit is about 3-4 jumps. This is not to say I write long meandering functions, but I personally couldn't imagine a codebase I'd be happy working in that is made up of modules that fit on a screen. Maybe it's possible! But the projects I've worked on that have a linter rule of "100 lines per file" or whatever end up being these rabbit holes. It's so hard to come up with code design guidelines everyone can agree on. As a side note, I despise things like imports and aliases. I'd prefer that when I do jump to a function, I can read it without having to check if anything is imported or not. I always opt for fully qualified function calls, regardless of how many characters it is.
- s_trumpet 3y ago
  At my firm we’ve standardized on import being used only for a short list of well known first/third party modules (e.g. Ecto.Query and Plug.Conn). Application modules can be aliased, but not library modules. This is so that we don’t need to keep repeating the name of the application throughout the codebase while preserving clarity as much as possible.
- seabass-labrax 3y ago
  > As a side note, I despise things like imports and aliases. I'd prefer that when I do jump to a function, I can read it without having to check if anything is imported or not. One idea might be to use an LSP (Language Server Protocol) interface. It could describe the fully qualified symbol for you when you, say, select the abbreviated symbol or press a keyboard shortcut. I've been working on a moderately large C program with Emacs and clangd[1] recently and have been amazed at how 'immersive' it feels, and that's from someone who's used to the comfort of a Lisp REPL! [1]: https://clangd.llvm.org/ https://clangd.llvm.org/
  - sodapopcan 3y ago
hirvi74 3y ago
> As an engineer for 10+ years with pretty severe ADHD (unmedicated... How did you do it? I wasn't diagnosed until my early adulthood, but even with medication, I feel like I can barely keep my head above water.
- dkh 3y ago
  I was diagnosed and treated young (around 12-13). I was not very well controlled at all at the time, and wouldn't be until my 20s, but I at least was aware of the problem and seeing a doctor regularly from that point on. Everyone is different, but the key things for me were 1) never settling medication-wise until I found something that truly worked well for me (a process that took years but well-worth it) and 2) utilizing my newfound focus to put systems in place to help me be productive while working around my particular weaknesses. (By this I mean how I handle todos, calendars, notes, workflow processes, etc.) #1 was absolutely crucial and is when I started "feeling good" but #2 is what took me from "feeling good" to "reaching goals". Regarding the medication, I had a very good doctor. In the beginning, medication would either not work for me, or it would, but for a limited period of time. I was very used to switching things frequently. So later when I would land on something that was okay-ish but not great (a point where many people consider themselves lucky and stop experimenting) I would note that it was helpful in case I wanted to return to it later, but we would move on and try something else, hoping for something better than "okay". And eventually we landed on something lesser-prescribed but that worked quite well for me and continues to work to this day. #2 was still a multi-year battle that I haven't fully won, but I've made enormous strides and I so badly wish I had gotten myself to this point a decade earlier.
  - DoingIsLearning 3y ago
    > 1) never settling medication-wise until I found something that truly worked well for me Diving into the detail, what medication have you tried and how did it work/not work for you?
BaculumMeumEst 3y ago
Finely aged, unmedicated, severe ADHD fist bump! I share your struggles. I find drawing lots of diagrams helpful.

by dkh 3y ago

bestouff 3y ago

Hey you are a younger version of me ! I completely agree, and I am now very selective wrt where and with who I work and I still love my job.

deleted 3y ago

[deleted]

Netcob 3y ago

Same here. I try to see the bright side, where I am basically forced to write "clean" code because anything else just doesn't fit my buffer. And I feel a kinship with current LLMs with small context sizes.

elcritch 3y ago
It's funny, my input buffer may be small and it's a large mental drain to read busy code (ADHD con), however once I grasp how a code base works it's just there (ADHD pro). It makes me wonder if it's related to the hunter-gatherer origin hypothesis. In that scenario covering large tracks of land was beneficial and that ability can be used to mentally map code. The flop side this also leads to distractibility and boredom paying attention to monotonous details.
- dkh 3y ago
  This is true for me as well, but the amount of time/effort it takes to get to that point can vary wildly, sometimes being a bit prohibitive, other times never fully getting there for the duration of the job. If I wrote the code, or was present for most of its growth, or have spent whatever time it took in this instance, I am pretty damn efficient with it indefinitely, as long as I don't for whatever reason take a huge break from working with that codebase. (As a ZFS fan, the silly analogy for my brain that I half-jokingly give people here is that I have a high amount of L2ARC)
dkh 3y ago
I did have this weird lightbulb moment a few weeks ago where for a moment I felt like an LLM was the perfect parallel to describe how my brain worked

rightbyte 3y ago

> flounder when debugging if I feel unable to visually see or mentally hold the entire problem in my head at once Surely this is a general problem and not specific to programmers with ADD? Or do you mean you are relatively worse at "needle sting debugging"? You second paragraph is just sane things in general. I wish your mindset was more common among my colleagues ...

dkh 3y ago
Relative to my peers I have often found myself to have lower tolerances in these areas. It sometimes surprised people when I felt something was complex (to work with, not conceptually) when they did not, or at the length of time it could sometimes take me to fix something that involved digging through a lot of code.
VHRanger 3y ago
ADHD is a quantitative disorder, not qualitative. To some extent, everyone gets mild versions of ADHD symptoms, especially if tired/bad nutrition/no exercise, etc. ADHD is when these symptoms harm quality of life significantly across many domains and since you were prepubescent (it's a brain malformation, not a series of bad habits)
- steve_adams_86 3y ago
  To expand on that, I think it can be clarified somewhat by describing the mechanism at work. People without ADHD have a generally-working motivation/reward system which is undergirded partially by dopamine. This neurotransmitter is relatively low in ADHD brains, which seems to lead to signal:noise issues. That’s likely a cause of having a highly distractible baseline state, but also leads to bursts of dopamine seeming more salient and arousing. You have a harder time regulating motivation and evaluating perceived rewards. A lot of what happens in the brain is based on relative states. If your dopamine is always low, something making it spike will seem more interesting than it necessarily should. If your dopamine trends higher, you’re going to have an easier time regulating interest, motivation, and an ability to transition through things you need to do — particularly things you don’t want to do. The inverse of a dopamine spike is a dopamine drop. This impacts the brain in important ways as well. In a person with ADHD, going from a high to a low can often cause serious declines in mood and energy. In a more typical brain, the same effects are present but less severe. So while these are all normal challenges people face because they’re the product of the same brain mechanics, a low dopamine baseline makes these mechanics more extreme in people with ADHD. They are primed for distraction and clinging to things which increase their dopamine. This could be video games, relationships, drugs, hobbies, etc. It could even be work too. They’re also primed far harder falls from their highs. This extreme oscillation often means some aspect of life suffers due to a lack of balance. That’s why it can be a disability. Hopefully that helps explain the quantitative aspect.

giantg2 3y ago

"and why I almost exclusively join small/new teams who don't yet have an enormous codebase that I'll have to wrap my head around." How do you find these teams? In my 11 years, I don't think I've ever found myself on a greenfield project.

dkh 3y ago
I live in Southern California where there was no shortage (until recently, at least) of very early-stage startups, and for years I exclusively used startup-focused sites like AngelList (now Wellfound) when jobhunting. The largest startup had 12 people when I joined. I worked for a company of 40ish once, but they weren't primarily a tech company and engineering consisted of only 3 people. I should perhaps disclaim that while this worked perfectly for me for close to a decade and I was never without work for more than a couple weeks at a time, I have currently been unemployed for a few months and have had a considerably more difficult time than at any point in the past.
- TylerE 3y ago
  Going with, in general, a company with less than 50 employees doesn't have to meet many of the requirements larger ones do when it comes to things like the FMLA.
  - dkh 3y ago
    Yeah but the demand for talent was such that, for at least a long time, the benefits and perks at startups usually exceeded those of the bigger companies. This may not be the case now, but I still think what you describe is not true often enough to be considered a general truism
    - TylerE 3y ago
      Not true enough? It’s literally how the laws are written. They exempt companies with fewer than X employees, where X is almost always 50

carlmr 3y ago

>it is easy for me to flounder when debugging if I feel unable to visually see or mentally hold the entire problem in my head at once. So much this. Fuck OOP-inheritance-thinking for spreading implementations to so many files.

pxc 3y ago
I also find this splitting-out that happens with OOP extremely unhelpful. I'd never considered that problem being exacerbated by ADHD, but it makes perfect sense.
- carlmr 3y ago
  The opposite to this: sum types (enums with values). You have all the logic in one place, and if you forget to handle a case in most languages you're forced by the compiler to be explicit.
  - pxc 3y ago
    In my first job after college, we had codebases that took both approaches: an OPP-y Java codebase with lots of inheritance and some FP-oriented codebases that used Scala case classes. As a novice, I definitely found the case class handling easier to browse and understand at the time. The OOP stuff can be made a little easier to work with if your editor can show a lot of buffers at once and makes it easy to search through buffers. Trying to just flip through all of those files with tabs would have been really hard for me.

vanderZwan 3y ago

> unmedicated, I cannot usually even read more than a few pages of a book before either losing focus or feeling drained Tangent: ADHD is strange. I have it too, and yet when it comes to reading my symptoms appear to be the exact opposite (when I was younger I could not stop reading books until I finished them, even if I ended up skipping an entire night of sleep for it). I wouldn't be surprised if in the next decades, as we learn more about it, this diagnosis will split into multiple different comorbid disorders with overlapping symptoms.

patmorgan23 3y ago
Recently I've heard ADHD described as "the inability (or weak ability) to direct attention" rather than a lack of it. So hyper fixation could be a symptom.
flir 3y ago
Already has to a degree - hyperactive type and inattentive type. But you've also got to consider personal taste - hyperfixation happens when it's something you're interested in. Someone else might hyperfocus on video games, or trawling ebay, or researching a topic.
- dkh 3y ago
  I am famous for "ratholing" for hours on some specific thing that caught my interest, usually with little sense of the time that has passed, and almost exclusively on problems that aren't at all what I'm supposed to be focused on at the time
  - deleted 3y ago
    [deleted]
- eyelidlessness 3y ago
  Not a disagreement, more of a yes, and: “interested” may not necessarily be personal interest, and the subject of hyperfocus might not be a personal interest. It can also happen manifest, for example, as obsession with solving some work problem or chore which isn’t appealing at all until begun. Or even some unrelated yak shaving tangent that fits none of these categories.

branko_d 3y ago

> I half-jokingly tend to describe it to people as having a "small brain buffer" The good news is that "smallness of bran buffer" doesn't matter very much if you are trying to implement anything non-trivial. Most useful software is so complex that it's impossible to keep all of it in your head in any case. But we can divide and conquer complexity without holding too much in our limited human heads at any single moment in time. The real art is how you divide and conquer. Having a bigger "buffer" merely delays (slightly) the point at which you have no other choice but to start doing just that.

dagmx 3y ago
I disagree. It really does matter if you have any afflictions that exacerbate it. It maybe doesn’t matter for relative performance versus other developers but it does matter for the individual. Having frequent context switches just to keep on top of your work can be really draining. How much it matters also really depends on the languages you’re working in. Taking a couple languages I use regularly for example: Python (or any dynamic language ), as much as I enjoy it, can be a nightmare because of how dynamic it is. You have to keep way more of any given app in your head at a time. Rust by comparison (or any similarly static language) is much easier for me to just focus on the very local code without caring about the rest.
- formulathree 3y ago
  Modern python is no longer dynamic. Type checking is a big part of python now. Python also has ADTs which match it in power to rust.
  - sneed_chucker 3y ago
    That's great if you're in a codebase at a workplace which enforces python type annotation checking. Unfortunately, I can tell you from experience that out in the real world, at fortune 500 companies, there are millions of lines of untyped Python doing critical work while being full of subtle type errors which should be compile time errors but will rear their heads as runtime errors when it's least expected.

Natuerich 3y ago

[dead]

npunt 3y ago

This idea of a 'small brain buffer' is why I love writing small atomic notes in wikis [1]. It lets me break problems down into simple pieces that I can later assemble upward in abstraction, rather than try to hold complex ideas in my head and compile them together in one big document. The buffer waxes and wanes, and I need to be able to adapt my writing process so I'm productive no matter where it is at the moment. [1] https://notes.andymatuschak.org/Evergreen_notes https://notes.andymatuschak.org/Evergreen_notes

tomjakubowski 3y ago
I've been doing this too in Obsidian and really like it. Notes can be as short or long as feels right. If they need to grow they can grow, sometimes they get split into sub notes. I have notes with titles like "Cardboard furniture", "Staging patch changes in VSCode", and "Hilbert Transform". Some are one or two sentences, some are more like essays with subheadings. Small notes tend to have one or two links to other notes. Longer notes have more links and tend towards centralization (eg all booking info about an upcoming work trip). Search makes it easy to find the notes that don't have links.
- vogon_laureate 3y ago
  It's been a game changer for me. I always did this anyway in other Notes apps, but Obsidian just does a great job of making it feel like it almost prefers you to write notes like that.
- npunt 3y ago
  Yep, Obsidian is the best! Two patterns I use a lot to help with this small brain buffer problem are collections & streams. Collections (sometimes called 'Maps of Content') are sets of internal & external links or resources around a particular topic, e.g. 'Self Deception', 'Creativity', 'Air Quality', etc. The page names represent the topic so they're easy to name, and if I can't find a page I go to these first before search. Streams are pages with date headers that contain small notes around a broad topic. For instance, 'Passing Thoughts' are random ideas, 'Story Prompts' are ideas for stories, and 'Inbox' are links to read and any notes I have on them. Streams do three things for me: 1. I don't know how big an idea is until I write it, and this stream pattern lets me optionally break ideas off into their own pages if they get to a certain level of size/complexity. 2. I can quickly capture without having to create a new page, since I'm at ~2000 now and each subsequent page makes search less effective. 3. I can avoid the challenge of naming pages, which is often harder than it seems. For instance, I've taken to naming certain pages like Andy M's evergreen notes style of declarative claims/statements, like 'Recognizing our influences empowers our creativity', 'The curiosity driving information addiction may be due to a sense of deprivation', and 'Good ideas deserve good stewards'. To do this clearly, concisely, and scoped correctly is its own challenge and worth the time investment because it really lets me build on strong foundations, and it prevents similar pages from proliferating in search by being easy to find.

devjab 3y ago

Interestingly I do the same as you, partly because the single responsibility part of SOLID, but also because it just appeals to me to write clean easily understandable code. It’s for different reasons than you, however, my ADHD brain can “buffer” massive amounts of code… for a while. So I mainly write things simply because it’s much easier for me to “get back to” after 6 months, well, and because it’s clean code. I think it’s interesting that we end up with the same sort of code architecture though, despite not being affected by our ADHD the same. For me the real struggle isn’t focus or “buffer”, it’s when things are boring. For almost all code work, even debugging, my hyperfocus grinds into gear, and if I’m left undisturbed I can quite literally work for 10 hours straight without eating. I don’t, because there is a bill to pay after doing so and I’ve worked on myself for decades to the point where I know to take breaks, eat and go home, but the hyperfocus is there. Until things get boring. Luckily this is rare with code. Not so with everything related to the process of being allowed to write code. I try to work in places where the process people bother you as little as possible, and if I can avoid it, I’ll happily go through the rest of my career without ever pretending to listen in another standup meeting ever again.

deleted 3y ago
[deleted]

rpastuszak 3y ago

> It is for this reason that I try to write what I feel is very obvious or self-explanatory code [...] I don't have ADHD, but, for different reasons, my brain seems to work in a similar manner. And, I have developed coping strategies similar to those applied with people on the ADHD spectrum [1][2]. My anxiety around coding has reduced a significantly when I learned about TDD and started writing code made of very small, composable chunks. I even use the same "small buffer" metaphor when talking about this! I know that some people with ADHD use the writing tool I built for myself. If you have a moment, feel free to give it a shot and let me know what you think: https://enso.sonnet.io https://enso.sonnet.io (the web version is free, and has complete feature parity, no need to pay me) - [1] https://sonnet.io/posts/hummingbirds/ https://sonnet.io/posts/hummingbirds/ - [2] https://sonnet.io/posts/sit/ https://sonnet.io/posts/sit/

naikrovek 3y ago
> My anxiety around coding has reduced a significantly when I learned about TDD and started writing code made of very small, composable chunks. you definitely do not have ADHD, then. I find these absolutely impossible to trace through when I want to find out what a program is actually doing, in reality. if I have to find the actual logic used in main or whatever event handler, and it's in a function called by a function called by a function etc., then I will forever despise the developer who felt that this was anything approaching an acceptable design, or even an acceptable idea. codebases like that are impossible for me to absorb. put the logic where it fucking goes, inline with its use! right there! nowhere else! don't nest it behind abstractions you don't NEED. functions that are very small and used in 100 places in the codebase should be inlined in the source code so I can read it. there is no function used this much in an application I've ever even considered working on, anyway. I always prefer to copy and paste a little bit of logic around than to wrap 5 lines in a function and call it from everywhere. if the function is 100 lines of complex code, put it in a function and call it ONLY if it is used in more than 2-3 places, and NEVER if it is only used once. today's "best" practices serve only to shut me and others like me out of participation and are exclusionary. this does mean that I have to take the time to find very good names for everything, which takes time, but always pays off in readability, for everyone, not just me.

MSFT_Edging 3y ago

I relate to this, one reason I avoid IDEs is the "window" where you can actually see code is so limited. It feels like coding through a paper towel tube. I'll make my life way harder in order to optimize the view of the code.

sodapopcan 3y ago

> why I try to keep functions/modules as simple as possible and ideally not longer in length than I can see on my screen at once (when possible) This is the paradox of "readable" code. Each person has a different definition of it. I also prefer to write as dumb code as possible (well, these days I do, I of course tried to be extra clever in my earlier days). But for me it's the jumping around that makes me lose focus. My limit is about 3-4 jumps. This is not to say I write long meandering functions, but I personally couldn't imagine a codebase I'd be happy working in that is made up of modules that fit on a screen. Maybe it's possible! But the projects I've worked on that have a linter rule of "100 lines per file" or whatever end up being these rabbit holes. It's so hard to come up with code design guidelines everyone can agree on. As a side note, I despise things like imports and aliases. I'd prefer that when I do jump to a function, I can read it without having to check if anything is imported or not. I always opt for fully qualified function calls, regardless of how many characters it is.

s_trumpet 3y ago
At my firm we’ve standardized on import being used only for a short list of well known first/third party modules (e.g. Ecto.Query and Plug.Conn). Application modules can be aliased, but not library modules. This is so that we don’t need to keep repeating the name of the application throughout the codebase while preserving clarity as much as possible.
seabass-labrax 3y ago
> As a side note, I despise things like imports and aliases. I'd prefer that when I do jump to a function, I can read it without having to check if anything is imported or not. One idea might be to use an LSP (Language Server Protocol) interface. It could describe the fully qualified symbol for you when you, say, select the abbreviated symbol or press a keyboard shortcut. I've been working on a moderately large C program with Emacs and clangd[1] recently and have been amazed at how 'immersive' it feels, and that's from someone who's used to the comfort of a Lisp REPL! [1]: https://clangd.llvm.org/ https://clangd.llvm.org/
- sodapopcan 3y ago

hirvi74 3y ago

> As an engineer for 10+ years with pretty severe ADHD (unmedicated... How did you do it? I wasn't diagnosed until my early adulthood, but even with medication, I feel like I can barely keep my head above water.

dkh 3y ago
I was diagnosed and treated young (around 12-13). I was not very well controlled at all at the time, and wouldn't be until my 20s, but I at least was aware of the problem and seeing a doctor regularly from that point on. Everyone is different, but the key things for me were 1) never settling medication-wise until I found something that truly worked well for me (a process that took years but well-worth it) and 2) utilizing my newfound focus to put systems in place to help me be productive while working around my particular weaknesses. (By this I mean how I handle todos, calendars, notes, workflow processes, etc.) #1 was absolutely crucial and is when I started "feeling good" but #2 is what took me from "feeling good" to "reaching goals". Regarding the medication, I had a very good doctor. In the beginning, medication would either not work for me, or it would, but for a limited period of time. I was very used to switching things frequently. So later when I would land on something that was okay-ish but not great (a point where many people consider themselves lucky and stop experimenting) I would note that it was helpful in case I wanted to return to it later, but we would move on and try something else, hoping for something better than "okay". And eventually we landed on something lesser-prescribed but that worked quite well for me and continues to work to this day. #2 was still a multi-year battle that I haven't fully won, but I've made enormous strides and I so badly wish I had gotten myself to this point a decade earlier.
- DoingIsLearning 3y ago
  > 1) never settling medication-wise until I found something that truly worked well for me Diving into the detail, what medication have you tried and how did it work/not work for you?

BaculumMeumEst 3y ago

Finely aged, unmedicated, severe ADHD fist bump! I share your struggles. I find drawing lots of diagrams helpful.