#i can't even choose which among them is best they're all soooooooo good

[poguniversity]

gojo is ungodly sexy in all the dubs they did this on purpose

[krakenartificer]

When I got my ADHD diagnosis, I looked at the questions on the screening form and thought, "If this result comes back positive, then I'm definitely not the only person in my family who has it." Questions like

"Have difficulty finishing one activity before starting another one" and

"I finish others' sentences before they can finish it themselves" and

"have trouble staying on one topic when talking"

...I thought were just weird quirks of my family, but no. When I got my results, I contacted my cousin, and she contacted her sisters and mother, and .. .. yeah. Basically everyone in my dad's side of the family is ADHD.

Now there are some problems with that, obviously, (getting family reunions to stick to a schedule is lol no) but there are some really fantastic perks. For one thing, no one in that family minds if I interrupt them while they're talking ... everyone's happy to keep 3 conversations going at the same time .... and no one minds if you fidget constantly.

But the best perk -- at least that I've found so far -- is that all of our parents have coping mechanisms, and passed them on to us. When I found myself unable to handle tasks with more than one step, my father didn't say "WTF are you talking about? It's easy! Just do the thing! Stop being lazy!" No, he could relate completely, and he sat down and taught me how to handle that.

So today, I'm going to pass on to you the coping mechanism my dad taught me for handling the "cannot put tasks in order / cannot get started / forget what I'm doing" problem. You'll need to adjust it for your own needs and your own struggles, but hopefully it'll be helpful in setting up your own process.

I'm going to walk through it with a big project I'm doing at work, just to have a concrete example. That will make some of the discussion specific to computer programming and technical writing, but I do the same thing for all my projects, so hopefully it'll be generalizable.

So to set the stage:

I was supposed to modify this piece of code -- we'll call it "Rosetta" -- to make it handle call data as well as what it was already doing. I did that.... but we now need the code to be able to handle calls (if that's wanted) but also to be able to handle NOT having calls (if THAT'S wanted).

Which is just .... ugh. So much. SOOOOOOOO much.

So. Break it down.

Step one is to get some recording mechanism - pen and paper, whiteboard, blank computer document, whatever

(Technically, this is a different coping strategy, so we'll just take a quick detour: WRITE THINGS DOWN. Your brain is shit at remembering things, and anyway you've already got limits on your working memory; why would you choose to tie up some of that limited resource in something that could be accomplished with literal stone-age technology? Don't even try to remember things. WRITE THEM DOWN.)

I like sticky notes: they're readily available in all offices, they're pretty cheap, and (most importantly) they can be rearranged if it turns out that I forgot a step or put the steps in the wrong order (which, like, let's be honest, I am definitely going to do). But they kill trees and create unnecessary methane emissions, so I've recently switched over to using virtual sticky notes. That's the format I'm going to use for this example, but you can use anything that meets your purposes.

So, you've got something to write with, you're ready to start.

The first question is: what are you trying to accomplish here? What would "done" look like? What is our goal?

I need to end up with a version of Rosetta that will make the correct results if you don't want calls, and will also make the correct results if you do.

The goal here is that you end up with a statement that you can definitively say (a) Yes this is what I wanted or (b)No this is not right because _______

In this case, in order to do that, I'll need to define "correct results" for both call- and non-call versions. But if I have that nailed down, then this statement meets that criterion: I'll be able to say "Yes, this is what I wanted: see, it makes the correct result for calls, and it makes the correct result for not-calls". Or else I'll be able to say, "No, this is wrong: see, it makes the correct result for calls, but on not-calls it does X and we wanted Y."

I have a clear, definitive standard about what I need to do and whether or not I've done it.

But there was a prerequisite there: I need to define "correct results".

So that goes on a sticky note: Create test that will compare my results to existing call!Rosetta-results and to existing not-call!Rosetta-results.

[ID: Two blue boxes, one on top of the other. The top one says in white text "Create test to compare my results to call!results" The bottom one says "Create test to compare my results to not-call!results"] OK. So now we know what we want. The second question is: what do we need to do in order to get that? Here's where the sticky-note recording system really shines, because you don't have to answer this question sequentially. You just start writing down every single thing that is not the way you want it to end up.

I need it to remove commas in the python script, not the bash script

I need to delete the first part of the get_runs() function, which doesn't do anything

I need to delete the rest of the parameters passed to build_query_script() function, because runs encompasses all the others

while we're on that subject, runs doesn't even need the group_variable, so let's pull that out of the parameter document

we also have a dmf defined, which the bash script demands but doesn't use; let's change that demand

since we're changing the structure of the parameter document, we don't need to pull new metrics for each run, so let's move that outside of the runs() loop and only run once

right now the parameter document is ALMOST but not quite "one row per template". Make it so it's actually one row per template.

among other things, that's going to require making it possible for a template to be followed by nothing at all, since it's the assumption that a template will have a metrics block after it that makes it not quite one row per template. So make it possible to publish a template with a null block

the other thing that's weirdly hard-coded is the definition of what a block looks like. Would it make more sense to separate that out into an input file, like the parameters document? On the one hand, that would make it much more flexible; on the other hand, that's another piece that can break. Don't know. Put a question mark on it.

etc

Here's what it looks like at the end of this step:

[ID: A black and white background showing many boxes in two different shades of blue, all with white text. Some of the boxes are overlapping each other.]

As you can see, at this phase you don't need to worry about any of the following:

ordering the tasks. Just stick 'em right on top of each other for now

how you're going to do any of this. Right now we just need to know what, not how

sticking to only one project. As I was working on this, it occurred to me that this whole process would have been a heck of a lot easier if someone had just made a user manual for this, and since I have to go through all the code line-by-line anyway, I might as well write up the documentation while I'm at it. (To help out future-me, if nothing else.) So I put those tasks on another color of sticky note.

making notes that make any ***ing sense to anyone else. This process is for you, and only you need to understand what you're talking about it. Phrase it in ways that make sense to your brain, and to hell with anyone else.

on that topic, also don't worry about making steps that are "too small" or "too dumb" to write down. This is for you. If "save document" feels like a step to you, then write it down.

You also don't need to get every single step involved in the project right now. Get as many as you can, to be sure, but the process is designed on the assumption that you ARE going to forget important steps, and is designed to handle that.

When you can't think of any more steps, then the third question is: what order does it make sense to do these in? Are there any steps that would be easier if you did another step first? Are there any that literally cannot be done unless another step is complete?

This is also a good place to group steps if they fit together nicely. When I used physical sticky notes, I used two different sizes; digitally I can of course make them whatever size I want.

So I have several documentation steps that (a) do need to be written to make sense to other people and (b) I really need to know what's going on before I can do that. I could write them now, but if I did, I'd just end up re-writing them based on things that change as I'm coding. So we'll move those to the end:

[ID: Three dark blue boxes with white text. They read "Create step-by-step instructions for creating your own metric agg", "Create step-by-step instructions for modifying a metric", "Create step-by-step instructions for modifying a query."]

These parts, though -- if I had all the variable structures written down, I could look at them while I'm coding. Then I won't have to keep scrolling back and forth in the code, trying to remember if it's an array or a dictionary while also trying to remember what part of the code I was working on. Brilliant. Move that to the front.

[ID: Seven dark blue boxes with white text, three large, four small. The first one is large and says "Write up explanation of how Rosetta works." The second one is large and says "Document structure of all variables." Attached to that one are four smaller boxes that say "All_blocks", "Runs", "metric", "New_block". The third large one says "Document what qb_parameters.csv contains"]

Also, while I'm at it, I should get the list of variables I need to document -- then I won't have to keep scrolling to find them. Make those sub-steps.

I definitely keep needing to look up what's in the parameters document, so I should write that down, too. For the user manual I also should write down what's in the metric document, but I don't need that for myself, so I can send that to the end.

[ID: The same three dark blue boxes from two screenshots ago (create step-by-step instructions for metric agg, modifying a metric, and modifying a query), now with another dark blue box in front of them with white text that says "Document what granular_metrics.tsv contains."]

These five are all small steps, and are all related in that they don't actually (hopefully) change the functionality of the code; they're just stuff left over from prior versions of this code. So we can lump them all together.

[ID: Five light blue boxes with white text that say "Delete first part of get_runs()", "Have build_query_script only receive the "run" parameter" "Delete dmf" "Move metrics=get_metrics() outside build_all_blocks (all the way up to the top level?" "Delete group_variable from qp_parameters"]

My brain likes this better, so that I can keep track of fewer "main steps", but that's just a peculiarity of me -- you should lump and split however you prefer to make this process easier for you.

[ID: The same five boxes from the prior screenshot, now all made smaller and attached to a larger box that says "Remove Legacy Code"]

Keep going, step by step, sticky by sticky, until you've got them in order. If -- while you're doing this -- you remember another thing you need to do, write it on a sticky and slap it on the pile; you don't have to stop what you're doing to deal with it, because it's written down and it's on the pile and it will get processed; you can just keep working on the thing you're on right now.

[ID: All the same boxes from the first screenshot, now in a neat row. Some of the original boxes have been grouped together. The ones that were said to be at the beginning of the process are on the left and the ones that were said to be at the end are on the right.]

Step four: for the love of all that's holy, SAVE THIS LIST.

Write it on your cubicle whiteboard where it won't be erased

write it on a piece of paper and tape it to the office wall

send an email to yourself

take a picture with your phone

I don't care but save it.

When I used physical sticky notes, I kept them all on the hood of my cubicle's shelf. Now, as you can see, I use Powerpoint, which is irritating af but does allow me to keep everything in a single document, which I can write down the path of.

[ID: White text on a black background says "open ~/Documents/Rosetta\ Modifications\ and \Documentation.pptx" The next line says "Notes in Rocketbook pg 10-12, 16" The next line says "Turn that into documentation that can be used for making modifications."]

And now (finally) you can answer the question "How would I even get started on that?" You look at the first thing on the list, and you treat it as its own project. You can hyperfocus on this step and completely forget about everything else this project requires, because everything you need to remember for the rest of it is written down.

If, as you're working a step, you think of something else you need to do for the big project, write it on a sticky and slap it on the pile. Don't even worry about trying to order it or identify sub-steps; as long as it's not blocking the thing you need to work on right now, you don't have to care. Just stick that bugger anywhere at all on the list, and go back to what you were doing. When you un-hyperfocus and come back to look at your list, there'll be a big sticky note stuck sideways across all the rest of the steps, and you'll remember to file and order it then.

Other benefits of this system

1) The first question really helps with unclear directions from your boss. You can take whatever they told you to do, and translate it into a requirement that is clearly either met or not-met, and then run it back by the boss.

If they say, "No, no, we want ______" then phew! You just saved a huge miscommunication and weeks of wasted work! What a good employee you are! What an excellent team player with strong communication skills!

If they say "Yes, that's what I want," then you know -- for sure -- what it is you're trying to accomplish. Your anxiety is reduced, and your boss thinks you're super-conscientious.

(And if your boss is a jerk who likes to move the goalposts and blame it on their subordinates, then have this conversation over email, so you can show it to their boss or to HR should it become necessary.)

2) Having this project map means that when you spend an hour staring at the requirements and trying to figure out how to get started (which, let's be honest, you were definitely going to do anyway) ... When your boss/coworker comes by and says, "How's it going?" Instead of having to say "I haven't even started 😞" You can say, "Pretty well! I've got all the steps mapped out and am getting ready to start on implementation!" and show them your list, and they think you're very organized and meticulous. 3) Sometimes, especially in corporate jobs, you and your coworkers will run into a problem that's too big for even Neurotypicals to hold all in their heads. At that point, the NTs will be completely lost -- they've never had to develop a way to handle projects they can't just look at and know how to get started. So then you pipe up in the meeting and say, "OK, well, what exactly are we trying to accomplish?" and everybody at the conference table looks at you like you're a goddamned genius and you don't have to tell them that you use this exact same process to remember how to make a sandwich 😅

4) Having this project map makes it so much easier to stop work and then start it up again later, but this post is already really really really long, so I'm going to address that in a separate (really really long) post.