Overview

Chris Simpson mentioned that he was working on “development tools for gifted brains” in response to my mentioning having created Noted. What follows are my thoughts on what it takes to make a great productivity tool that wont be abandoned, & works for everyone, not just the creator.

The Thoughts

Software is amazing. I love it, & I especially love when developers take the time to really focus on making better tools, or improving the ones they have.

There are also some GREAT things starting to happen in software with regards to helping #ADHD brains.

BUT they almost never stick.

I theorize that there’s always an impedance mismatch resulting from the fact that every 🧠 is different, & has different values & needs.

BEST case scenario for most attempts at ADHD is that they work GREAT for the creator, and a handful of others who happen to stumble on it. BUT there’s a looooong history of ADHD folks going “ooh shiny! that’ll solve my problems!” and then 2 weeks later they’ve wandered off. Given that happens with a LOT of software, BUT we’re kinda “extra” in this regard.

This is why - when it comes to “productivity” & organization of tasks - I turn to paper. Specifically paper with NO organizational structure I have to adhere to. I’m going to explain that, but then I’m going to talk about where those same attributes can be found in software.

Here’s the thinking: The organizational tools that work for other people’s 🧠s are RARELY ever going to be a perfect match for mine. On top of this, no-one really knows what works for their 🧠 until they really start experimenting.

So, I think we need to start with a foundation that allows us to try a strategy, abandon some parts, tweak others, and add new ones.

In the early days, this iteration needs to be able to happen FAST. Like, day-to-day changes. IF we actually pay attention to what is and isn’t working for our 🧠s (HUGE “if” I realize) we should be able to find something that “seems to work well” relatively quickly.

BUT that’s never the end. The longer you spend with a tool the more familiar you become with its strengths and limitations. You’ll find things you want to change after a while. Eventually YOU will change as a person. What’s important to you, where you’re focusing your energy, etc. So, again your tools will need to grow and change.

For example, Bullet Journaling (BJ) https://bulletjournal.com/blogs/faq really is a SPECTACULAR system / tool AND It was created by a person trying to overcome the very serious problems that their ADHD presented them. If you’re having trouble keeping on top of your tasks & schedule & remembering what you did it’s a GREAT place to start.

HOWEVER, very few people stick with the “official” Bullet Journal process, & many that like its approach have jettisoned certain aspects, & changed others.

BUT because BJ wants you to use “blank” paper (lined / dot grid / literally blank) it FULLY supports changing with the user. It’s an amazingly flexible framework built on the even more flexible foundation of paper. The only restriction paper really imposes is the size of the sheet.

In my game design notebooks, I’ve ended up using its “collections” idea, abandoned literally everything else, and inserted my own way of making page headings, subheadings, & noting specific sections of a page as atypically important.

Noted is a collection of physical tools to hold note cards, but what makes it really useful to me is that I have a specific framework for managing and organizing tasks. Sadly, I haven’t documented this publicly yet. Much like Bullet Journaling I think this will be really useful for a lot of people (even if tehy don’t buy my card holders) BUT I don’t expect many people to use it unchanged, & I built it on the amazingly flexible foundation of paper.

This post started with software though. And, all is not lost in that realm. I believe that any productivity tools that impose a strict process that can’t evolve with the user are ultimately doomed. In my experience people making tools for ADHD people to stay on top of their 💩 are atypically blind to this problem.

“Hubris” is one of the “Three virtues of a great programmer”. It leads us to create amazing new things instead of sticking with “good enough”, BUT it also leads us to believe that the fact that our tool works SO amazingly for OUR 🧠 that it’ll also work amazingly for other people’s 🧠s, but it rarely does.

All hope is not lost though. There are two amazing tools for developers which clearly show us, that it IS possible to make software that a user can mold to their needs, even if they’re not a developer.

Vim, & Emacs. BOTH of these tools are IMNSHO absolute dog-shit in their bare-bones configuration. HOWEVER no-one uses them in their default configuration, because what makes them amazing is that they are incredibly flexible foundations that do a core task (text editing) BUT allow users to change almost everything around that.

Imagine a “todo list engine” that had almost no functionality. Out of the box it might be an ugly list manager with barely any UI or guidance that does NOT work the way you want a todo list to work.

Imagine also, that it was ridiculously customizable and that, almost every way you could imagine to interact with, leverage, and style a todo list was sitting right there in a package manager waiting for you to install it. If you came up with something new, you could add it, or ask someone else to.

The creators would distribute it with some collection of things they thought was a good starting point. Some people might even make “distributions” with heavily customized collections of mods. Much like Bullet Journaling these would be a great place to start. Like BJ they’d also allow you to mix and match other ideas, to throw out ones you don’t like, etc.

This, technically already exists. It’s called org-mode. It’s amazing, and it does way more than todo lists. BUT it is text-centric AND Emacs has a reputation for being “hard” and “kids these days”, and the point wasn’t to convince you to switch. ;)

The point is that we have 2 historical references showing us that it’s entirely possible to build software tools that approach a common problem but also support wildly divergent brains.

Once someone “gets” that Emacs & Vim can be easily customized to support how their 🧠 approaches problems they end up molding them into the “perfect” tool for their brain. Over time they grow with you. You add new packages. You get rid of others. The community makes versions of old ones that may work better for you brain, or come up with wildly new tools no-one anticipated.¹ People use these apps for 30+ years because they grow with them.

Emacs built a flexible framework for text manipulation. It did a REALLY good job of that, but more importantly, it not only allowed for, but encouraged people to mold it to their needs.

If we want to build truly great productivity tools that support neurodivergent brains (ADHD, ASD, DID, etc) I think we need to learn from the lessons of Emacs and Vim.

We need to build frameworks that support one core idea exceptionally well and make it trivial for everyday people to mix, & match, & modify tools to support their brains, and not just the brains of the people who coded it.

This is easier said than done, and it means writing a bunch of “modules” to help show what’s possible, and make it actually useful for others. The modular approach means that we can also release a core collection of things that works great for us, and demonstrates the power of our tool, while also saving us from having to write all the possible variant needs for all the possible brains. We “just” need to convince a handful people like us that we’ve created something useful, and support them in making it more useful in the ways that they need.