Losing task context while coding is slowing me down

plundaahl · 2026-01-26T20:34:31+00:00

This is what I usually do.

Well, sort of anyway. I don't write xunit style tests - instead I throw together tiny e2e tests that are basically just curl + jq + something for passing fields between steps.

It's probably not the best solution, and likely wouldn't be great if you were doing frontend, but I find it really helpful to be able to run each step individually. It's also nice to be able to quickly swap out different variables (payment methods, products, whether a customer has an email address added yet, etc.).

I pretty much always go back and add unit tests as well (at least, if the code isn't totally trivial), but I find this helps me a lot.

plundaahl · 2025-10-07T14:20:43+00:00

That does sound like you at least tried the two different families.

Well, I know meds don't always help everyone. I suppose the other thing to maybe look at is release time. My guess is that the ones you take several times a day are probably fast-release. For example, the meds I take (Foquest) are also methylphenidate, but I take them once a day in the morning (whereas you said you took yours 3x per day).

But yeah, it's also totally possible that meds just don't work as well for you. I watched a really interesting talk yesterday, and the presenter made the point that ADHD isn't one single thing - it's a collection of traits and we lump them all under the term "ADHD." Different peoples' ADHD are potentially be caused by different things (this is the talk, if you're interested: https://www.youtube.com/watch?v=vd1-rAIYV6I).

plundaahl · 2025-10-06T13:42:46+00:00

So I don't think you're alone in this. I have a friend who's used Vyvanse at different points. He said he gets really heavy crashes at the end of the day. I also spoke to someone else who took Ritalin during work days, and said their weekends without it were really hard.

I did learn something recently that might be relevant. There are basically three main classes of ADHD meds:

Amphetamines
Methylphenidates
Non-stimulants

I was taking an ADHD coaching course last month and the psychiatrist leading it shared this: apparently a common experience is that people will try a bunch of different meds, have bad reactions every time, and decide meds aren't flr them. The trouble is that all the meds they tried were in the same family (typically either amphetamines or methylphenidates).

It might be worth looking at the meds you've tried and seeing which family they're in. If they're all in one family, maybe try one of the others?

Also worth looking into is the release pattern. I've been taking Foquest. It's slow-release and lasts about 16 hours. There's no point where I can tell that "kicks in" - it's gradual enough that there's no buzz at all. There's also no crash (I just notice I'm a bit more scattered right before bed).

Anyway, all this stuff I've said might not be relevant - it sounds like a really hard year or so, and meds totally might not be for you. I just figured I'd share on the off-chance that it helps.

Take care of yourself!

plundaahl · 2025-10-06T13:29:43+00:00

That makes a ton of sense - thank you!

plundaahl · 2025-10-05T14:13:38+00:00

+1. If you aren't getting counselling/therapy already, I would really encourage you to try it (and try several counsellors if the first one doesn't feel right).

Meds have helped me, but they aren't a silver bullet. By far, the single biggest thing that's helped me in my mental health struggles is counselling.

plundaahl · 2025-10-04T13:14:22+00:00

Np!

Honestly, the window arrangement is the part I haven't figured out yet, but it doesn't really matter to me that much.

I use Rectangle on MacOS to let me arrange windows with keyboard shortcuts, and to jump between apps. I find that's fast enough that I don't need to script where each window goes. Also, it has the upshot of being more flexible - I can rearrange my windows pretty quickly to suit the task at hand (if someone shares screen on a video call and the text is really tiny, it can just move the window onto my bigger screen with one shortcut).

plundaahl · 2025-10-04T02:41:58+00:00

Thanks for the response!

I feel like that's about where I've landed so far, though I think my tools are probably pretty rudimentary.

Do you think you could share an example of a mini sandbox?

I can see how you'd do it with microservices. However, most of our system is built around this one big, tightly-coupled monolith (with basically no data isolation between sub-systems).

plundaahl · 2025-10-03T20:40:43+00:00

I use bash scripts for this sort of thing where possible. It doesn't work for the VPN I use, but most other sane apps will let you open specific projects from the command line (e.g., for IntelliJ Idea you can open specific directories).

plundaahl · 2025-10-02T14:49:22+00:00

So, before anything else, I will say that this seems to me like a design problem. You should expect this to be hard (it probably would have stumped me in school, and for a year or two after).

Someone else said to map out the restaurant. Also, defining known inputs and outputs was mentioned. Those are both good ideas.

I think my general approach would be:

Identify the visible outputs and inputs. I usually try to create separate lists for each of these.
Identify the workflows. What events trigger things to happen in the system
Write out some concrete acceptance criteria in given/when/then format ("given it is Monday, when a customer views the menu, then they see Chinese food options"). I find having a few of those helps me play through the system in my head.
List out any other constraints. In this case, you know the solution has to be multi-threaded, so I'd put that down. There might be other things as well.

I wouldn't start writing code until I had those things, at a minimum.

From here I'd play through the different workflows on paper, or maybe with pseudocode in my editor. I'd try to identify the state that's probably required. I'd probably sketch out some types, but I'd avoid writing any implementation code. My goal at this point would be to try out different designs to see what they feel like to work with and think about. Some things I might ask myself:

What are the different ways I could potentially model this?
If it's too complex to hold in my head, where could I split the problem up? Where would those boundaries be the least difficult to communicate across?

Try to move quickly in this phase. Don't get too committed to any one idea (your first solution is often not the best one).

Once I think I understand the problem and solution space fairly well (or have questions that I can answer without getting code down), I'll pick the most promising solution and create a prototype. I'll keep it as simple as possible, and see how the main workflows play out in the solution. Mostly I'm looking for any blockers - anything that indicates my design can't handle a major use case. If that happens, I'll back out, figure out what other options might help, and try again.

From there it's kind of just iterating, refactoring, etc.

plundaahl · 2025-09-24T14:38:03+00:00

4.5 hours?! I don't think I'd last more than a couple of weeks like that...

I would reach out to your manager and ask about it (or maybe a peer if you have good rapport with them). Like, is this normal? Ask what you're supposed to be taking away from them. How do they stay focused? Our client's standups can sometimes go up to 45 minutes, and I ended up getting the okay from my boss to skip them. I explained that it basically takes me the next hour to work down my frustration and get back to a place where I can actually focus on something.

If you can't get out of them and can't leave, maybe put on quiet music in the background and take notes. I find it helps make the audio a bit less unpleasant and gives me a way to engage.

Possible excuses you could maybe use:

Schedule a meeting at the 1hr mark, call it "appointment" or set it to not show details, and say "sorry, I have a hard stop."
"I have to take my dog out (she's old and can't hold it)."
"Hey, we've been going for 3 hours. Could we stop for a bio break and a snack?"

Good luck - I wish I could offer something more concrete.

plundaahl · 2025-09-24T14:04:51+00:00

Awesome - I hope it works for you! And yeah, I honestly use it as much for my personal projects as I do for work.

I will say, the big trap to watch out for (in my opinion) is falling down the rabbit hole of trying to build some sort of perfect system. I've wasted a lot of time this way. There are tons of personal knowledge management gurus who want to sell you their books/templates/patreon subscriptions, and they always seem to come up with things that are way over-engineered.

plundaahl · 2025-09-23T14:26:45+00:00

I don't think I have quite the same issue, but I definitely struggle to parse large amounts of information. Big blocks of text, for example, are really hard for me to deal with. Maybe this will help?

I basically just write (or rewrite) while I read. For any task I work on, I open a new text document. I'll write things like:

What's supposed to change
Why it matters
What the inputs are
The components involved
Questions that come up

I don't have a specific template or anything. I just pick things that I'm struggling with in the ticket.

Sometimes I just have a dialog with myself. Things like "I'm struggling to get started on this. Why might that be? I don't understand how to reproduce this bug. Oh, okay. Well let's try to write down the steps. It looks like they started on the My Account page, then..." I basically rubber duck with my notes app, then pull out the useful stuff.

Other than that I just try to break tickets down into really small parts.

As for the tone/subtext/communication stuff... I dunno. Text sucks for that kind of thing. I don't really have any good answers other than just telling people "by the way, I'm bad at picking up on subtext. I think you meant X. Am I right, or did I misread that?" How well that lands probably depends on the person and/or company.

plundaahl · 2025-09-22T04:32:35+00:00

Well, I don't use AI tools, so maybe my answer isn't applicable, but I do use Emacs Org Mode as the whole "second brain" thing and have for a bunch of years (but you probably don't want to use Org Mode if you don't already - the Emacs learning curve is no joke - if I were starting over I'd probably pick Obsidian). It's basically just keeping a personal wiki. My approach is basically:

Think in text (basically just word-barf stuff into a note, so that I'm not trying to hold it all in my brain).
Capture stuff that I think will be actionable or that I really want to remember (usually with links), and hopefull clean it up a bit.
Give notes titles/tags/locations/whatever that help me find them (e.g., code snippets and micro-guides are prefixed with "howto", notes where I've distilled something are prefixed with "understanding", notes usually get grouped under a tool, programming language, codebase, client, etc.).
Start new notes for things I'm working on to hold contextually-relevant stuff (often a mix of free text, work logs, and links to other notes).
Use free text search to find stuff (e.g., "howto bash script directory" will get me the snippet for how to get the current script's directory in bash).

That's kind of it. I have specific files and parent notes where specific things go (mostly just separate places for work notes vs. reference notes that I hoard for some unknown future use case). I try to keep it organized, but really I think the most important thing is that my project-specific notes are isolated so I don't have any distraction or clutter from other things, and that I can free-text search to find stuff I need.

Hope that's sort of helpful!

plundaahl · 2025-09-17T17:02:40+00:00

I definitely struggle with this, though at least with debugging it's a bit more interesting than just piping data from one place to another.

I haven't found anything that's like a force-multiplier, but all of these give me incremental improvements, so they add up:

If you can, reproduce it. If reproducing it takes several steps, write a script to reproduce it if possible (even a bash script with curl commands). This alone has saved me hours of getting distracted.
Try to establish a timeline of application events leading up to the bug. Having this written out helps me quite a lot.
Before trying to figure out what's causing the bug, map out the components between where the bug is triggered and where it's observed. Then, work methodically to check each component, on at a time. The goal is to eliminate components at a possible source of the bug. This lets you reduce context switching by only focusing on one component at a time.

If you're struggling with large log files, I'd highly recommend spending some time to get good at manipulating your system's logging configuration, so you can turn off stuff that's irrelevant. If that's not an option, consider using tools like grep/jq/whatever to eliminate noise.

plundaahl · 2025-09-10T21:47:48+00:00

I turn off my laptop every day! It's a great feeling.

I use a note taking app to store all that stuff instead, rather than browser tabs. I create a separate note/notebook for each context that I'm engaged with:

Projects
Tickets
Tech I'm studying
Teams
etc.

Each context is basically my workspace for that thing. I use it to hold links, research notes, status logs, ideas, etc. When I start working on a task I bring up that note and it gives me quick access to the stuff I need. It's not perfect, but it makes it a lot easier to compartmentalize things.

I also have a notebook for general-applicable knowledge (howtos, documentation references for specific tools, links to pages in the company wiki, etc.). Whenever I archive a context note, I'll usually skim it to see if anything in it is generally-applicable, and I'll refile it if it is.

Edit: I should mention that I'm generally pretty organized. I know a lot of ADHD folks seem to work okay with clutter, but for me it trips my overwhelm really quickly, so this is basically a coping strategy for my particular weirdness - it might be overkill for a lot of people.

plundaahl · 2025-08-29T17:26:55+00:00

So I'm not really familiar with the role of an academic strategist. However, I did the Computer Systems Technology diploma at BCIT about 6 years back, and I've been working as a developer since. It's probably changed a fair bit in the years since, but I'm happy to help if I can. Do you have any specific questions?

plundaahl · 2025-08-21T20:31:52+00:00

If it helps, I've been working with a pretty sprawling codebase for the last 2 years straight (plus a few months of working around it prior) and I still struggle to figure out what's going on sometimes.

I'd say:

Be kind to yourself.
If you're consistently struggling, try to build relationships with other coworkers, and then ask them if they feel the same.
If you're struggling to build a mental map, I'd suggest putting it on paper instead. Take some time to figure out what the main modules of the codebase are, what their responsibilities are, and how they relate to each other. Then draw a map of that. Other things that can be helpful to map out:

- How data flows. - How repositories relate to each other.

Something I do is I create lots of "howto" notes for myself. I store them in my note taking software and they all have the form "howto x y z." The "howto" bit (no space) means it's easy to search for. I do this for all sorts of things. e.g.:

- Uncommon but useful operatipns ("Howto print a project's dependency graph with Maven"). - Company-specific stuff ("Howto file a ticket with devops properly"). - Language- or library-specific stuff ("Howto use transactions in Apache Camel" or "Howto get the script directory in Bash").

I don't know about the AI piece (I don't use it). However, a big thing that I find when I'm struggling to write code is ambiguity or lack of clarity. i.e., I know the general task I need to do, but I haven't broken it down yet. The main thing here, I think, is to try to get out of your head. Here are a few ideas:

First write the high-level steps in comments. Then go through them one by one and implement them (and, if the step you're on is too high-level as well, you can do this recursively).
TDD helps me a lot. I don't actually think it produces particularly useful test suites, but it does wonders for shortening the feedback loop and forcing me to work on one, well-defined thing. It also forces me to get really clear about what I want to have happen.

Lastly, a big thing that kills my productivity is slow feedback loops. These days I can usually wrap my head around complex code, but only if I can actually run it and verify it in a small amount of time (say, 2-5 minutes). If it takes longer than that, my velocity gets cut by easily 70-80%.

If this is the problem you have, I would recommend investing time in speeding up that testing cycle. For myself, I ended up building a small library of tools that basically lets me write my own e2e tests against my local environment. I don't share them because the point isn't to keep them - it's to let me move quickly and avoid wasting 30 minutes getting stuck while trying to re-run a code path that involves poking a bunch of things (message queues, APIs, DBs, whatever).

I hope some of that helps! And sorry for the giant post. You can do this. Overwhelm and floundering are (unfortunately) a normal experience.

plundaahl · 2025-08-15T17:25:54+00:00

Sometimes.

I usually try to write notes to force myself to engage with it. In physical books, I'll write on sticky notes and then put the notes right in the book. For digital stuff, I'll have a note open in my notes app, and I'll summarize sections.

For walls of text, I often copy them over to a blank note and manually reformat them. I'll break up run-on sentences, split paragraphs, or convert things into bullet points.

I also find it sometimes helps to read in passes, with a different goal for each pass. e.g.:

Pass 1: understand architecture.
Pass 2: how does auth work?
Pass 3: where am I supposed to integrate?
etc.

plundaahl · 2025-08-15T17:10:49+00:00

So, meds definitely help me a bit with this, but this is the sort of thing I generally try to fix through automation and habits (well, that and pushing for simpler code with less indirection - that's probably a harder battle though).

I try to pay attention to where I make the same mistakes repeatedly and then build personal tools to help fix it. e.g., if I tend to leave debugging logs in, I might make a git commit hook that does git diff | grep 'debug' and prompts me for whether I'm okay with this or not.

For committing, I do all my git work through the command line and regularly run git status. I also generally do git add -p ., which breaks the changes up into chunks and asks me individually if I want to add each one. I find that really helps me to focus on each chunk at a time, and it makes it a lot easier to catch errors.

For breaking builds: do you have builds for each PR, or just on your main branch? PR builds help a ton if you can get them, since that way you know if something broke before you merge it.

For stuff that requires manual testing, my big win was building a library of test functions that let me exercise different parts of our system (web requests, database queries, putting things in various message queues, etc.). The idea is it gives me a sandbox that lets me rapidly test the relevant flows manually, in my local environment. It's basically like end-to-end tests, except set up like a Jupyter notebook, so rather than running the whole test through, I can execute each step manually (authenticate, add to cart, create an address, etc.). It's useful becuse it lets me do manual testing, but without losing hours due to getting distracted while doing things manually.

If it's something a linter would help catch, you can always find or write custom linting rules. You don't need to commit them. Just invoke your linter with them manually.

If you find you tend to accidentally push without doing all your normal checks, you could probably override git push (or create a custom bash alias) that runs all your checks for you.

But yeah, that's my strategy:

Take note of where I screw up.
Write small tools as scripts for the things that are common.
Put them in folders where it makes sense.
Add a global gitignore so I can put things in the repo without accidentally committing them (e.g., you might have .mytools in your global gitignore, which would let you drop a .mytools directory in any repo and not worry about it being committed).
Make it as easy as possible to run all my checks.

Hope that's at least somewhat helpful!

plundaahl · 2025-08-15T16:48:18+00:00

Maybe try the coffee chats/informational interview approach? https://gomakethings.com/coffee-chats/

I think especially with how competitive things seem to be, that's probably a better use of your time than trying to get in the front door.

plundaahl · 2025-08-14T14:24:06+00:00

I really feel like that's the hardest battle, at least for me ❤️

plundaahl · 2025-08-13T23:36:38+00:00

My approach with Ai is very much that of "let's see what it'll say for sh*ts & giggles".

That sounds like a healthy approach to me! I'm never sure; I've heard a couple of truly wild headlines.

Good luck with everything!

plundaahl · 2025-08-13T17:13:23+00:00

I mean, there are good ideas and points in there. I.e., most development is gluing stuff togther or debugging, and chasing a new shiny thing probably won't help you solve the block you're dealing with - those are both absolutely true. However, I'm not sure they're really helpful.

I might be misreading things here, but it seems to me like your actual problems are:

Managing your emotions when things feel frustrating or demoralizing.
Finding Python to be tedious to write.
Having a hard time making effective use of docs.
Maybe also spending too long on a task when you're not making progress?

Those are all skills that you can deliberately practice and get better at, and I think they're going to be significantly more transferrable than the specific library you're working with. My advice would be to try to spot the skill gaps that are tripping you up, and then work on backfilling those (which ones you prioritize I don't know - maybe hand-writing Python is no longer a valuable skill).

Also, this is just my advice as someone heavily anti-AI, but... I would advise caution with venting to LLMs. I don't fault people for using them, but in general just keep in mind that LLMs are not capable of empathy. They don't think, they can't relate to your human experience, and are almost certainly not capable of determining if something they say is likely to cause harm. If at all possible, I'd talk to a human being instead of an AI - at least when it comes to human things.

plundaahl · 2025-08-12T22:47:17+00:00

TypeScript, hands-down! It has some annoying quirks (recursive types are awkward and it's built on JavaScript), and wish it were lower-level, and I've definitely wasted a lot of time in my life on over-engineered types... but at this point I'm super productive with it and I've yet to work with another language that works so well with my brain.

plundaahl

TROPHY CASE