Effect of perceptual load on performance within IDE in people with ADHD symptoms

These findings don't merely apply to coding, they're applicable to any type of focus-driven work. Case in point, I use VSCode to type all of my work-related research and writing drafts instead of using Word for the simple reason that the Word UI is cluttered, distracting, and makes writing difficult. By comparison, VSCode is so much more pared down and lets me focus on what's actually important - the content of my writing!

Is feature-creep the inevitable fate of any software environment? As a product gains momentum, I think there's always going to be pressure to add new features to either justify monetization or user retention/growth (and, more cynically, to justify what an employer is paying a team who is staffed on that piece of software).

I do think that FOSS is more immune to this problem. There's no incentive to grow or monetize, and so you end up with software that can be feature-complete for its purpose and left relatively alone (the downside is that there's a lot of half-baked FOSS out there as well!). Hopefully when feature-creep takes over VSCode, someone will fork it and continue the project as-is.

It's def not as pervasive yet as Typescript.

And too bad Eclipse's Mylyn doesn't make anyone any money. It's brilliant for this.

Extra cognitive load slows everyone. It's just that the effect is measurably distinct in people with executive function (distractability) issues, with respect to speed. The distinction between debugging and coding is not really active vs monotonous but driven by your own ideas vs chasing (a problem). The study isn't realistic, but it's designed to get a measurable result (and to showcase the "efficiency tracking" plugin).

Anecdotally, everyone adjusts their IDE, or accommodates what can't (easily) be changed. Too bad that wisdom is lost and hard to share.

I think the solution here is more configurable UI's, with the configuration being automated/scriptable so that once you've established your preferences, you can replicate them through upgrades, etc.

The most configurable IDE of course is Eclipse (which is in decline because no one gets paid directly to write for it, and it's cheaper to publish a language server for your new language than build an IDE). You can arrange views as you like, change menu and toolbar visibility, change key bindings, and of course add whatever plugins/features you need. If you use Mylyn, you get task-based filter that hides elements not required for your tasks, and highlights the files relevant for that task in a way that can be shared via bug-tracker. You can save view configurations as a workspace and save various preferences. But because components come from everywhere, support for configuration capture varies.

People share their dotfiles for shell and vi/emacs configuration, but not their IDE configurations. It's too bad, because then there would be a configuration population to analyze when raising UI issues.

ADHD and ASD are a broad spectrum. It may help to join the tribe because it validates our experience, but then we can fail to recognize our brain's specific biases. Worse, anyone over 7 has been getting good at compensating, which hides the issue, and our culture of excellence/competition/success == good (therefore failure bad) further obscures with shame, defeat, and self-sabotage. Legal requirements for accommodation help set a global floor, but may also work as a local ceiling by supplanting ordinary fellow-feeling.

For reading fatigue, consider a dyslexia font, e.g., https://opendyslexic.org.

If an idea flashes into my head, I quickly write it shorthand anywhere. See my other comment (https://news.ycombinator.com/item?id=36726680) on having 'Streams' pages that offer an immediate working space to write. I let the idea expand with that progress & velocity, and once I've reached the end of my writing juices, if it's important enough I copy/paste it into a better place. Organizing is one task that can be done when the winds of flow state calm.

Similarly, breaking ideas into small bite-sized parts helps because those are easier to complete with less energy. Better to make incremental forward progress than keep trying to do the same big thing over and over.

Also, I try to start with a summarized version of what the thought is. Again, shorthanding the key points is helpful. It's easy to have a big thought that has several constituent parts and immediately dive into some details on one of those parts, only to find that the big picture sort of disappears. Better to capture the TLDR first.

Finally, I'm okay with abandoning ideas, I trust that the important ones will come back, and I make sure to leave affordances for myself so I can always return to what I was doing later. Some things I do to make revisiting ideas easier include:

1. I'll review my 'Passing Thoughts' stream at least once a week to see if my new context or a new perspective allows for the ideas to come back.

2. I keep track of work-in-progress work with a #WIP tag and new pages I've made in 'What's New' stream.

3. I keep track of my thought process with occasional self notes in 'Whats New', e.g. "I dove into X by expanding Y and Z but think I have to reorganize section A to fit it in"

4. In the organizing step I think carefully about how I name pages (including using aliases)

5. I densely link all related ideas so there's many ways to find them.

There are tons of libraries in many companies that use dynamic attribute lookups for efficiency reasons, when adapting to different data sources and the like. Or pass through lookups on nested objects. Or they’re dynamically looked up on bound libraries from other languages and frameworks.

And these type checkers cannot detect it. Python’s dictionary access is not guarded by the type checkers and neither is __getattr__.

If you’re making such wide sweeping statements you need to be more familiar with the subject matter.