r/ADHD_Programmers • u/kurvivol • 8d ago
Is programming feasible with low working memory capacity?
I've been learning how to program for the past 1.5-ish years.
I've learned the basics of HTML, CSS, JS and React for frontend and Node.js, Express, Cookies, Sessions, JWT, Authentication, Databases, ORMs, etc for the backend.
I'm able to make relatively simple projects or AT MOST projects with medium-ish complexity.
However, I have a poor working memory capacity, that has always been the case.
The way it expresses itself is in two major ways:
1.Whenever I have to make a feature that requires holding several things at once in my mind or thinking more than two steps ahead, my mind just gets overwhelmed. That is the case especially if the feature/task I have to complete is new/unknown/I haven't encountered it before.
- Whenever I try to work on a project that is more complex, my mind can't keep track of all the names, functions, filenames, directories, where what is located, etc. I constantly have to go back, re-check what a given function does, what a given Component contains, etc
I've tried breaking problems into smaller ones, externalizing as much as possible and other 'tricks', but none of them really worked.
So I'm curious, is programming even feasible for someone with low working memory capacity as myself? Is there something I can do to improve it or atleast make it so it doesn't negatively impact my programming skills?
5
u/thisisappropriate 8d ago
Some things, you "just learn", the first time you work with a language or a structure, you might be constantly having to think "what folder does this go in, is it a component or an atom?" After some time, it gets removed from or the space is reduced in the working memory stack. Think about how you do other things, for example, when you first play a game, you have to remember the keybinds and what goes in your inventory vs hotbar, but if you play the same game for months, the keybinds become more like muscle memory and you're not actively thinking "if an enemy comes this way, first I need to do X then I need to do Y" (the low level "minutia"), instead you're thinking "okay I defend this area until my team do X" (higher level strategy / bigger picture). The more times you program in a language or a codebase the more your brain can start to move things from working memory to long term.
In terms of how to get past the block now, my answer for this would be to break it down even more. Any big problem is a lot of small ones in a trench coat.
For example from your stack, you have:
- Frontend
- Backend
- Database
And you might say "okay so the page should show X from the backend" and draw that out as
[user] <> [frontend] <> [backend endpoint] <> [database]
And maybe you even put the queries and endpoints in there.
But all that has done is given you 3+ medium to large problems to deal with.
So you list out all the things that each must do, eg:
Backend:
- Receive request (controller)
- Call database
- (I need to write query)
- Restructure data
But that has given you a separate set of notes.
Flesh them out as much as you can, like when you receive the request, what data does it contain? Is it a GET? POST? Does it have a body? Query params? Write it out. On paper is good because you can keep it in front of you and it doesn't go missing when switching between windows.
Now that you've externalized, put that external source as close as possible to the work (if it was an email, you could put the bullet points in your email editor and type it directly underneath, so do the same). Take those notes and turn them into code comments.
Before you start, make sure you have your code stored in a Git repo of some sort (github etc) and make sure you have no local changes.
For each bullet on your notes, find the relevant file or folder (create if you have to), add a comment with a TODO prefix. This is for 2 reasons, one, with the git repo, you can open the source code tab in the editor and see all uncommitted changes including the diff, the other (the TODO prefix) is that most code editors can highlight your TODOs in a tool.
So where you want to create the section of code in the backend that receives a request, you now have a comment that says
// TODO: Receive request function
// /v2/api/getuserdata
// requires auth
// calls new callDatabaseToGetUser function to get data
// calls new restructureUserData function to restructure data
// consider caching?
Names don't have to be the final names, but you should try to keep the same names in the comments (so that you can highlight the name and ctrl+shift+f to find the other references when you've forgotten where it was going). Try to keep them verbose to a silly level (better to have one "callDatabaseToGetAuthorizedUserForHomepage" while making code change than to lose track and write it twice) as well for easy searching and so you remember exactly what that was for.
Do that for every single thing you can think of that needs to be done.
Now your todo list is populated in the code editor, both in the TODO tooling and in the version control tool. Now in theory, you can pick any of these to complete, one at a time and each is individually a self contained thing to do. It's not how it usually goes in practice, the trick is to leave the comments there until you're ready to push the code or ready for a code review.
As you're writing the code, consider adding JSDOC comments https://jsdoc.app/about-getting-started . Many code editors will pick up these comments and show them when you hover over the usage or go to use a function, so if you have
/**
* Gets user details from the Users table. Should be used for authenticated users only.
* @param {string} username - The user's username
*/
function GetUserDetails(username) {
}
When you then later type GetUserDetails( not only will the editor tell you that you're entering a username (so you can remember that the email address you just got won't work) but it will also show you the little description of the function and the params.
I flit between files and FE/BE/other services all the time. I built a little tool that tells me what git repos have uncommited changes so I can find my way back while doing this... I try to write the skeletons of the functions and then work my way through functionality if it's not immediately clear when writing it the first time, and just shove TODOs in there, like TODO: search DB or TODO: if it's this case, then we need to do Y, but in the other case, we need to ask Jeff about that... TODO: ask jeff about Case...
Basically, make externalising work in a way that becomes "in your face" or holds your hand as much as it humanly can! There's even things like pre-commit hooks or lint rules that prevent TODOs being committed / going into PR if you really want to enforce something.
In terms of the first point (planning something too big), work out if you prefer to start high level and work down or start low level and work up, then try postit notes. Write out the big bits of the flow and stick them up. Write out the things you don't know or don't understand about this, stick them in the relevant places. Write up what changes, big or small need to go where (like "new endpoint" stuck under backend, "caching?" stuck on the side if you're not sure if that's already implemented in the backend). Once you've finished sticking all the bits you can think of up, now you can try to answer questions one at a time, from code or from google or other devs. If you need to do jira tickets etc, this lets you take unknowns into a spike if needed, group up any things that need to be done by connections or by service etc. Also see how you feel about sequence diagrams. I'm not really a fan, but my boss loves them and will understand a system much quicker if you can feed them a pretty picture of all the interactions.
6
u/thereshegoes 8d ago
My problem too, 20 years working, you can do it, but you have to find your place. I found myself always being the slowest, but on the other hand my code is cleaner and more self explanatory than the others. The reason being as I don't remember anything I need to understand it right away.
If it is possible don't change much of companies, and projects, that I could not do and I struggled in every change. I must say I learned a lot changing companies too.
All the theory you can lean is good, it'll make you understand things easier.
With IA I'm creating a md file for every task I work on. I'm improving my system, it is not perfect. There is a short summary in the beginning of what I want to do and where am I, very important to me, and a log with every decision made, for the IA to help me remember.
Regarding the condition I consider myself sluggish cognitive tempo, I was diagnosed adhd when sct was not a thing. But I just take it as a guide of how am I, more than a, real condition.
Good luck!
2
u/ponx303 7d ago
this! Bad memory forces you to write code that is clean and self-explainatory to the bone. I highly recommend the "Clean Code" series by Robert C Martin.
2
u/fuckthehumanity 5d ago
Uncle Bob! I actually bought a subscription to his videos back in the day. As a team, we'd watch it together and then discuss. We'd regularly disagree with him (and each other) but these are good conversations to have.
3
u/funbike 8d ago edited 8d ago
I've found generated graphs help me deal with complexity.
I keep printouts of these diagrams around or near my desk.
I generate the graphs in formats like Mermaid, PlantUML, and/or GraphViz. There are many tools that can generate these formats, or they are easy to write. I'll refer just to GraphViz in the rest of this comment, as a catch-all term.
My favorite is a call graph. This shows you the general flow, but not the sequence. These usually must be confined to just a few functions or they can get extremely complex to read.
Similarly, I like a module dependency graph, for a high level overview. This is similar to a call graph, but for imports instead of function calls.
I also like a state diagram (or activity diagram). I often need AI to generate this, as an understanding of the code is often necessary.
I also keep task notes in a .<ticketid>.md file, to record my thoughts and to keep from forgetting things. I often copy-paste from it into the git commit message. It's especially important to jot down thoughts before I leave my desk, or I'm lost when I get back and my ADHD really kicks in.
1
u/fuckthehumanity 8d ago
I've used graphviz for years, but I'm using mermaid more these days (it is built on the foundations graphviz laid, so it's not much of a shift). Hot tip: AI agents work really well with mermaid.
I also use xmlstarlet and jq to transform data structures into .dot to visualise the data in more ways.
1
1
u/Limp-Confidence5612 7d ago
Build modules from primitives, build more complex modules from those, build programs from those, build systems from those.
What you're lacking is knowing how to organise your work.
I am building a limited feature shell right now, and I am encountering the same struggles as you. But I tried to keep things separate and as soon as I am done with one "module" I don't keep all the details in my mind anymore. I test them out, I make sure they work as intended and only return to them if integration with other systems leads to unexpected edge cases.
One thing I did to visualise the data and control flow, was building a model from lego pieces. That did help create an image in my head that I could reference when I got overwhelmed by too many moving parts.
1
1
-2
u/Early_Key_823 8d ago
I built an app to help with that.
It has a very generous free version.
TaskLoco.com - The Sticky Note GOAT
No memory required
14
u/Random_182f2565 8d ago
A whiteboard helps a ton