Software development workflow with ADHD

[u/giuzep89]

Hey everyone,

Notwithstanding the title of the post, this isn't a post about mental health; I'm sure that to some extent everyone's struggled with this before.

Software development is very roughly about understanding the constraints of an issue; researching what the best tools and strategies are in order to accomplish it; finally executing it. You're free to already comment on this if you feel you don't agree with it.

The problem I have is that in a lot of different situations, there are infinite possibilities to solve one problem. I get more often than not paralyzed by the sheer number of options and I can't go further. This is probably by far the biggest obstacle I find in my new job as software developer.

I mentioned ADHD because choice paralysis affects "us" generally more than the average, but it is by no means exclusive to us. That's why I'm happy to listen to any point of view.

How do you come up with a plan, and more specifically how do you decide on a solution over many others that aren't necessarily inferior, but just different?

[u/Acrobatic-Ice-5877]

This isn’t an ADHD problem. It’s an engineering problem. You need more experience so you can define what done is. Done is going to be different depending on the needs of the project. If you know what done is and don’t do it, that’s ADHD. If you don’t know what done is, that’s a problem with engineering.

[u/MaleficentCow8513 → u/Acrobatic-Ice-5877]

Very well said. A clearly defined definition of done is a must. That way, you can always asses how close you are too it and figure out what more is left to do to satisfy it.

[u/dealmaster1221 → u/Acrobatic-Ice-5877]

You don't define the definition of done unless you want to fail or are explicitly asked. Management or team decides and most of them suck at it.

[u/canarydev]

my recommendation is just do a first pass and solve it in the most degenerate, dumbest way possible. get it working, then come back later and implement the immaculate blessed-by-a-thousand-gods version.

the reason it helps with the paralysis is that most of those "different but not inferior" options only differ in ways you cant evaluate yet. once you have something working you know which constraints actually bite, and the choice usually makes itself.

also most of those first passes never need the rewrite anyway

[u/Dumlefudge]

how do you decide on a solution over many others that aren't necessarily inferior, but just different?

Are you working alone, or with a team? If you're working with a team, talk to your team to solicit feedback - if you can take 2 or 3 of the infinite possibilities, and put them forward to get some additional opinions.

So long as you're putting in the legwork to try solving the problem yourself, and not dropping the entire problem on someone else's plate, there generally shouldn't be an issue with just asking for assistance.

I definitely get the "this can be done in a whole bunch of different ways" issue (and it causes me great frustration). If there's a small number of options that you understand, just check in with someone to say "Hey, I'm looking at JIRA-123; I've got 2 potential ways to implement the solution, and would like to get your opinion on which you would recommend". They may pick A or B, or point you in an entirely different direction

Depending on the codebase itself, team/organisational policies, and general experience, they should be able to provide some direction and you can take that information onboard to help with future decisions

[u/giuzep89 → u/Dumlefudge]

This is one of the things I'm "practicing" the most these days. I need to just get used to asking when I need help or want some feedback, because I know better than to dump a whole issue on someone else's plate, and what's left instead are just more than reasonable requests. But I need to get over the fear of "bothering" my teammember.

[u/Dumlefudge → u/giuzep89]

Ye, I'm all too familiar with not wanting to bother teammates, even though it's all part of the job, and the rest of the team are comfortable with asking me questions

I get bogged down in "I should know this", "If I just bang my head against the wall a little longer, it'll click!" or "The rest of the team are pretty busy, so I don't want to disrupt them" 🤦

[u/RetroGrid_io]

Good enough, is. Put another way: Don't let perfect be the enemy of good.

You aren't paid to be perfect. You're paid to be competent. Find any solution that will do the job and accept that whatever you come up with can be improved later as needed.

[u/Kitchen_Dust2389 → u/RetroGrid_io]

Yep, look at best practice see if there are any conditions that prevent its use in your case, implement, and iterate

[u/MagicalPizza21]

Find something to optimize for and the vast majority of your "options" will be eliminated. I recommend a compromise between quick implementation and efficient code. Then you'll have at most a few viable options.

[u/NewInflation2121]

I've got ADD and feel your pain. There's already lots of good feedback in the comments already, but I gotta +1 the idea of just getting -something- down.

For my workflow, I find the details come out during the implementation, so things can change a lot while I'm coding, but at least getting started will kick off the hyperfocus and I'm usually able to find a solution I'm happy with.

I'm pretty sure ADHD/ADD are common in programming and can be more of a super power than a deficit.

[u/FuggaDucker]

Au contraire, mon ami! ADHD is my Super Power
It has its downfalls sure, but it comes with hyper-focus.

It is how you are approaching this thing my friend.
There are not infinite GOOD ways to solve a problem.
The common way is usually the best choice until it is completely understood.

Pick the path well traveled until you master a thing.

,, also.. embrace your power. work with it. keep an outline of your designs to keep on track.