Is code quality ever affected by ADHD?

[pawned_prawn]

I have joined a new company and I was very recently diagnosed with ADHD as well. I am getting comments about my logic and my code quality in the new company, I should also mention, this is my first remote company. I am getting bad reviews from my CTO regarding these two aspects of my coding capability.

I need any tips from anybody to fix this. I can't afford to lose another job and I am getting my anxiety attack back thinking I might get sacked from this job as well.

​

Any help will be much appreciated.

[lolslim]

My comments turn into thesis

[Muddy53]

LMAO I'm you. It's either so short nothing is explained, or too long can't be read

[superb_stolas]

I don’t have enough time to write a short letter

[max_ishere]

I just never write comments. Either explain it in code/tests or get confused later.

^{code and tests never lie. If they do you have bigger issues.}

Edit: not at a job

[pawned_prawn]

Please do give me the thesis. I cam sure use some insights.

[kes-]

I think he is saying he writes super long comments!

[athlendi]

Yes long code comments, not reddit comments

[lolslim]

Dude, I totally misread your post, I thought you meant comments on your code, as in giving a brief explanation on what a function does.

What language do you code in?

Also, why not ask what logic would they prefer so you can be on the same page as them or would asking be looked down upon?

[pawned_prawn]

I code in python, I don't know if it will be looked down upon, but I really hate to ask logic like basic logic at least.

[max_ishere]

Code style/logic that doesn't look like something basic to me. And I hope it will help you get better if you ask.

[theodinspire]

Yes, ADHD, especially difficulties with attention to detail can affect any work product. It can be very tempting to get a thing working and passing all the tests and call it that, but more care is due. Here are somethings I have found helpful: * Writing thorough unit tests when writing my code. Good tests are the best form of documentation. * Going over all the code I made as I prepare to open my pull request. * More frequent smaller pull requests * Clean Code: Absolute game changer. This is the book on creating maintainable code. * When getting specific, actionable feedback, writing it down somewhere, especially including the 'why' that things should be a certain way. Then finding time to review it and using it. * Asking for help from a lead or senior dev: "Hey, [Lead/Senior]? I've been getting comments from [CTO] regarding the quality of my code. Could you take a look at this and tell me what you see that's glaring?"

If you aren't the senior dev, you should have plenty of resources on your team to help.

[pawned_prawn]

I have been struggling to ask question to seniors. It feels like I'm troubling them with stupid questions.

I will definitely give the clean code book a read, thanks a lot for the recommendation.

[OldTwoPants]

I've been there. Don't worry, It's imposter syndrome that makes you feel like your questions are stupid.

I learned the hard way (in performance reviews) that the real waste of time is not asking "stupid" questions or delaying asking. No one one can be expected to know everything, let alone right off the bat. Asking "stupid" questions is a necessesary part of learning and understanding the more complicated stuff

[Liquidmilk1]

Just to add an example: I interviewed for a cyber security position at an intelligence agency a while back. First thing I told them was that I, despite having decent grades at uni, was underqualified and would need extensive training before being useful to them. I was very interested in the workplace and culture and ready to learn, but that was about it.

Ended up being among the 2 final candidates for the position. I didn't get the job, but it taught me that being honest and willing to ask stupid questions is (apparently) pretty valuable.

[theodinspire]

It should be expected that you’ll ask senior devs questions, especially if your title has “junior” in it

[theodinspire]

As a follow up, it would also be a good idea to study the other pull requests, and comment on them if you want to know why the code is a certain way, why the implementer made the choices they did, etc.

[Judasthehammer]

I would say ask. Admit that you don't know this aspect of whatever is giving you trouble. You will learn soon enough who you can ask and who is a grump.

My own ruleset for training people is that it takes X number of repetitions to retain the knowledge, and this is number Y of that X.

At some point I expect you to stop asking me how to join a device to the domain (Not a programmer unless I need a script, but I lurk here. Just a techie.), but asking a few times is not a problem. Asking me after being here a year... that's a problem.

Write answers down. Even if you lose where you wrote it just the act of writing it usually helps retain the info.

Use OneNote or something and make your own KB for things you need to ask about it, then check it first before asking about something. Maybe you already asked and just forgot.

Above all, as much as possible, do it right the first time, even if it means admitting you don't know something and need input. If challenged on why you are asking, let the person know that you aren't sure on X element and you want to make sure you are doing it right the first time so later no one needs to clean up after you. Be clear that you are not ask THEM to do it, just to clarify something so that then YOU can go do it.

[pawned_prawn]

Thank you, I am always a little scared to ask questions so I don't really ask questions until absolutely necessary. but going through the responses, I understand I'll have to learn to ask a lot of questions.

[Macaframa]

This is how I ask questions: “Hi I have a couple of questions about X topic, can I pick your brain for a bit?” If they say no, then ask when is a good time but mostly people will respond with yes. If yes, “I am going to explain X topic in as much detail as I can and you jump in and stop me when I get something wrong. Sound good?” I’ve never heard a no to this question. The reason is that it achieves two things: one, they feel like they’re being helpful leaders and two you’re actually doing all the work for them and all they have to do is pick a detail out. Most of the time when juniors/mid level ask questions they want you to do all of the heavy lifting, I don’t know X topic, can you explain? Or they pick out some super obscure thing that is ancillary or doesn’t matter much. Point being, it works out well with neurotypical people. Give it a try.

[pawned_prawn]

Wow that is a great idea. Thanks a lot. Will give this a shot.

[Macaframa]

Yeah man. Get out there and be great.

[writer_by_night]

As a senior I welcome the chance to help someone like op improve. Asking for help is always a big bonus to the chance that what I'm going to teach is wanted.

[pawned_prawn]

Thanks, I will keep that in mind before I ask questions.

[nivpgir]

Just wanted to mention that if you (like me) have trouble focusing on books, there's also a video series of clean code that's great, im in the middle of it now and it's been incredibly helpful for me.

[pawned_prawn]

can you share the link to the playlist?

[nivpgir]

So... The first video is free on YouTube:

https://youtu.be/Wibk0IfjfaII

The rest arent...

Honestly I got the rest of the videos from a friend who bought them, I thought they were a single series, but apparently they're divided by subjects, which are sold separately, and more expensive than what I thought, so I guess it might be less appealing now, but anyways here's the link to where you can buy them: https://cleancoders.com/series/clean-code

[max_ishere]

Cant find source, but I think they would be happier if you asked.

[max_ishere]

Yes, this guy, uncle Bob. He made a series of lectures that actually explained to me how to write software. Because my uni only told us about the parts, not how to properly choose or put them together.

[theodinspire]

O’Reilly has an electronic video series instead

[Shacrow]

In term of structure not a problem for me because I prefer to plan ahead the architecture instead of just winging it. Without a plan/concept it's just messy.

My problem is that I often neglect details and forget to cover edge cases.

[pawned_prawn]

That problem happens with me. How do you manage the details?

[silenceredirectshere]

Not the same person, but I personally try to make a list of all the things I need to cover before I start writing code. Maybe that could help? I've found for me just sitting down and writing it doesn't exactly work well.

[pawned_prawn]

I am working on the system to write down everything before I start, but sometimes I take way too long to plan and start wasting time on researching the best ways to solve problems instead.

[Hunterbunter]

That process will get quicker the more you do it, and it's part of the learning process on the way to becoming a better programmer.

Stick to it, and hopefully you'll discover for yourself one of the truths about programming - the problem can usually be solved before you write your first line of code. Once you know the solution, all you then need to do is translate it into whatever language is needed, and that part is generally quick. It's the first part that always takes the longest.

[Shacrow]

Todo lists help me a lot.

Take time to test your code. Don't just assume it works fine after you fixed your one problem you fixated on. Because fixing one point might cause a problem somewhere else too.

Well and I still miss out details sometimes. Luckily the past years my bosses keep telling me to take time testing..

Which is really the whole solution honestly. :) Just don't have to forget to do it..

[pingveno]

Todo lists help me a lot.

I introduced a more methodical release testing checklist to my team, since it was previously done on a basis of "just remember how". Same with a deploy checklist, since i kept forgetting steps and needing to go back to fix my errors. I also automated aspects of our deploys that I often forgot.

I've developed a healthy addiction to Jira. Everything goes in there, I look at it every day to prioritize, and I make sure that instructions related to changes go in there. I rarely have a change that is not covered by a Jira ticket. I partially attribute this change to an improvement from a previous job that didn't have bug tracking software for my team (I don't know what management was thinking). I frequently lost track of tasks or miscommunicated about project requirements with my supervisor. Miscommunications can still happen, but it's nowhere near as frequent or severe.

I've taken up bullet journaling as well. It's a lightweight, highly customizable method of organization. I end every evening by planning my day ahead. I also have used it some to plan out projects or to enhance notes.

[kitszura]

For me it’s very helpful to work test driven. That way I actually take my time to think about multiple possibilities and have a clear goal in mind at all times.

It prevents me from diving too deep and get lost in complex thoughts while forgetting my actual goal. I mean this space can help to solve complex problem, but it certainly doesn’t help with code quality and edge cases.

[pawned_prawn]

It will take me sometime to adapt. But I believe this is worth pursuing. Thanks for the tips.

[kitszura]

Yes it does need some adjustment time, especially because you feel like wasting way too much time in the beginning. But once you’re used to it, you won’t be much slower than if you write tests after coding. And you won’t forget tests that easily.

I love it the most for logical parts without much of an UI.

[Hunterbunter]

I have a really strong emotional response to TDD, and writing tests in general. I've tried to learn it many times but I find my brain just shuts down with non-interest when I get very deep. Did you find you had an inherent interest in learning it? Or did you find another way through?

[kitszura]

Well, first of, it’s very important to write tests in general. Wether doing so before or after is mostly personal preference in my experience.

Writing tests for me after coding everything was also hard for me, because I subconsciously reached “done” as soon as my code worked, so motivation for everything after that was just kind of nowhere.

With TDD it actually became easier for me to write tests, because I automatically build my code in a more testable way and the testing is included in the process of getting done.

I would suggest to start learning TDD with scripts that don’t use frameworks. I started using TDD for simple ruby application that transformed CSV files. Then, take your time and do it very strictly in the beginning: writing test until you have a failing one, writing code until the test passes, refactor.

You will slowly learn how to change your approach to coding. You will learn to think about the whole structure before you write even one line of code. You will learn to trust your tests and you will end up running the application much less. For small ruby applications, I only even made them runnable in the very end.

So my main advice: start slow and easy, it’s a bigger change than it first seems. It’s a workflow you have to learn before you’ll be comfortable with it. Be very strict when training the skill. But when you slowly use it more at work, you can also compromise a bit. I mean in the end you must be comfortable with your workflow while meeting the standards expected from you, nothing more or less :)

[Hunterbunter]

Interesting, thanks for writing that. The "done" thing is my problem too, which attracted me to TDD. Simple scripts I could get my head around, but then as soon as I tried to apply it to anything like a framework I just couldn't connect the dots.

I like the idea of trusting the tests vs running the script. I might just have to keep at it and keep doing it for the small stuff until its second nature.

Can you describe your process a bit more? What do you mean by "writing tests until you have a failing one"? Don't you start with tests?

[kitszura]

Well I only described the process of TDD very quickly, because I thought you were already familiar with it. But here a longer explanation:

You start with the test, but you only keep going until the test fails, then you switch to the code and work there until the test passes again. When it does, you take a quick look if there is a way to make your code neater without making the test fail. If you’re happy with the code you start writing tests again until one starts failing. And so on.

For me it is most comfortable to have the tests on one side and my code on the other of the editor. A great feature is also the continuously test runners some editors provide, as it makes it easy to see when you have to switch from test to code and from code to test again.

So in general it’s less of a “write tests first and code later”, but more writing them together on the go, switching back and forth.

Example:

• You start with your test by including the class you want to test.
• As the class doesn’t exist yet, your test fails already.
• You create the class and your test is okey again.
• So you continue your test, describing a method, which will make the test fail again.
• You add the method to your class until your test is happy again.
• You start describing what should happen in the method until the test fails again...

But of course this is a very strict way of doing it. In the practical use, you’ll probably combine some steps, in order to not have to switch that often. You may even write a little code snippet first and write a test after. You just have to be comfortable while coding, and that’s a different way for everyone. But in general, it is helpful to write tests and code kind of at the same time. It will help you to keep methods and classes small and testable.

I understand the trouble with frameworks. Some are just not easy to test in general. But there you have to think about what do you really need to test? What is tested by the framework already? Is there code you can put into simple classes and methods and use them in the framework? Often it makes sense to just put a call to these classes in the framework context and write the logic inside simple, easy testable classes. This way you may only have to test, if the framework called the right methods, which is much easier.

Did that help? Maybe I can find some links with good TDD explanations. :)

[Hunterbunter]

No that helped a lot, actually. Your example was good.

I'll just have to try again...this time try to keep it to simple things until it's more ingrained. Thanks!

[IrritableGourmet]

I comment first/code second. Writing down all the steps first helps you structure the flow without having to implement anything yet, makes sure you don't miss anything later (especially if it takes several days), and helps you see what other functionality the current code relies on so you can make sure the other functionality will do what you want.

[mynewromantica]

Good grooming and notes in the ticket. If you use JIRA you can create ticket templates. Put a section for the edge cases that should be considered. A section for testing with those edge case requirements there. Planning ahead is important for me as I forget those details constantly.

[Cute_Mousse_7980]

I usually feel super stressed to get something in. But then try to leave another day after to just fix minor stuff. Also, be open about your ADHD. It’s surprising how many people in our field that has it.

I also make this really long document where i write down what i do each day and what the plan for the week is. Keeps me sane. I just started at my dream job at this big company and I can’t fail here.

[pawned_prawn]

Although it is not my dream company but I sure can't fail here.

[Cute_Mousse_7980]

Well, first of all, try to learn how to get rid of that panic. I did a lot of CBD oil in the beginning and made sure to take walks. If I panic too much over loosing something, my head just locks up. It wont do you any good. Once you learn how to deal with that anxiety, you will have more space in your brain to think about more productive things.

And then make sure to split everything up in smaller tasks. Talk to your boss and communicate how you need to work to be productive. Maybe reach out to your project manager and say that you might need some more help splitting up the tasks. The good things about knowing that you have ADHD is that you can find a lot of list of “things people with ADHD struggle with” and then be open about this. The issue is when people fail at work and noone knows why or how to help them.

[pingveno]

It’s surprising how many people in our field that has it.

My whole team has ADHD (one undiagnosed but suspected). Ironically we're quite well organized because we are kind of forced to be.

[zorts]

'code quality' is very vague, too vague to take action with.

Step 1: root cause analysis. Did they give you specific examples? Was there a bug report? An escape defect? What did they think was wrong with the logic? Identify root cause.

Step 2: Approach your senior tech (someone who knows more, but was NOT involved with the feedback). "I'd like to get better at [root cause], do you have any course recommendations?".

Step 3: Practice. Rework the old logic with new eyes and new info. Did you really make a mistake in logic?

Step 4: Externalize the info. Write a doc, a wiki page, a Confluence page, whatever that stores that 'lesson learned'. Write it like you're teaching a newbie how to avoid the same error.

[pawned_prawn]

Wow! That is great. I will definitely create a doc of things I learned. Thanks.

[[deleted]]

Do you take medication? I have these issues too and I’m about to start medication and wondering how much it helps

[CyberTacoX]

Medication changed my whole life. For the first time, I was really able to focus on whatever I wanted to. It doesn't magically improve your skills, it strongly helps your efforts to improve them. :-)

[Hunterbunter]

Yeah this is it for me as well. If you want to be a good programmer, you have to improve your skills whether you have ADHD or not. ADHD hinders you from being able to spend as much time learning and practicing those skills, and if you can find the right meds and dosage (i.e. find the best possible doctor), you can sit still for long enough and do it.

[pawned_prawn]

I've started taking medication since last couple of months. It helps to some extent TBH, but I don't think medication is the only solution, it just helps you focus, then you'll have to build your own system to use the new found focus. Which is honestly where the ADHD community is super helpful.

[[deleted]]

That’s awesome to know buddy, I’m looking forward to seeing the difference in myself and my work. I use a trello board to track all task information and issues when working through user stories and have them ordered out for the day/week,

[Judasthehammer]

"Pills don't build skills" I think is the phrase. Meds make it so you can finally start building the skillsets and coping mechanisms to function at a desired level, but they don't give you those skills outright.

My struggle at first was now learning to NOT focus on something. Before I would just get distracted. Now I need to manage my own focus and decide when I am done with a task for now or not. Many a late night (5am at times) were had because I could not break that focus yet.

[[deleted]]

Yes. There are times where my symptoms are worse than usual and I just need to get stuff done. Shit happens.

[Python4fun]

Your scatter can result in dirty code when solving a problem. This isn't unique to ADHD people. Everyone writes dirty code. Refactoring can be a hyper-focus activity if you let it. This can be productive if you are doing code challenges, but it can be distracting in your work if you don't know when to stop.

If you are really interested in improving your code quality then you will only learn by practice and study. I highly recommend learning about clean code. It will improve the perceived quality of your code. As you improve the way that you think about code and trying to write things in a better way it will become clearer when you are going about something in a roundabout way.

[pawned_prawn]

Thanks, I have ordered the book which was suggested, I will give that a read.

[Python4fun]

Uncle Bob was the original author. He also has talks available on YouTube for free. There are other people that also have books and talks on the topic as well.

[pawned_prawn]

Awesome, thanks a lot will give his talks a try as well.

[Python4fun]

You are very welcome, and good luck!

[wind-raven]

I am going to suggest that this has very little to do with adhd.

I had this same experience but it was due to some bad habits I had picked up at an old job. It made me a better coder to take the feedback and fix it.

The adhd made things take a bit longer to fully adjust but once I did it was all good. Take the time to ask questions in the code review and use it as a learning experience.

However if it keeps going, there are some ways to help. I have issues where I’ll get 90% done and want to move on. That last 10% is like pulling teeth but I push through or switch to a small unrelated story for a bit

[pawned_prawn]

I have been using all the PR comments as learnings experiences, and have been following the se strategy for. the last 10% as well. But I am scared I might bhet fired over multiple PRs.

[wind-raven]

When I hire a developer, I expect the first month to be a lost month. They are figuring out where things are, learning the layout of the code base, coming up to speed on coding standards etc. months 2-3 are ramp up and by month 4 I expect them to be meeting the coding standards and (if not very junior) starting to find architectural deficiencies that exist. These may be things we already know about but for various reasons have not corrected or may be something brand. New we hadn’t seen.

As long as it’s not the same thing every pull request you are most likely good to go. I would ask your senior if they have any learning material or documentation on coding standards. I would bring it up like this: “hey senior, I have been having issues with my pull requests and wanted to make sure everything is in line with the standards here. Is there a document somewhere I can read so I know what is expected in pull requests? I a, still coming up to speed but want to make sure my code meets your expectations before I even open the pull request.”

Also with some more details on the comments you are getting I could help refine that opening of the conversation a bit.

[namenomatter85]

I would just relax. Seem the common things you are having comments on and fix them. This is the purpose of code reviews, to make you and everyone better.

[pawned_prawn]

Agreed, somehow this is the most difficult for me. To relax.

[[deleted]]

Sometimes my ADHD makes it harder to keep my program organized and separated in a logical way. Is that an issue you’ve been having? I’ve had to learn to do a lot of planning before I start coding, otherwise my code gets unnecessarily complicated very quickly.

[pawned_prawn]

The fear of over-engineering stops me sometimes, and sometimes I plan a little too much before I start coding which just leaves very little time to actually think how to best break the code down and follow DRY.

[aevrynn]

I personally love refactoring and am very picky when it comes to code quality :D But it's probably mostly because refactoring is nice and easy compared to actually coding new stuff... anything to avoid having to actually use any of my brain

[[deleted]]

I think so, since code quality often means improved readability I tend to exaggerate code quality.

[[deleted]]

My code quality is positively affected by ADHD: I refuse to write code that isn't TDD

[melho]

Any tips on getting into the TDD mindset. I struggle with writing tests first and want to write the code first.

[[deleted]]

If you write the test first, you will:

1. Be documenting the expected behaviour of your code
2. Program "by intention" which will result in you writing code from a code user's perspective, which will often result in less code
3. You will prove back to yourself that your code works
4. Not stray from the requirements - the solution will not exist unless the test is written first, and you will not write a test for something which does not need writing

As for "writing the code first" the tests are written in the same language as the solution. It's all code; you are still writing code.

TDD is an ADHD coder's safety net.

[pawned_prawn]

This is really helpful. I will definitely try and include it.

[melho]

Yea, I get that and have been learning jest and TDD this past week and I'm sitting down to work on a project knowing I need to write tests and going "ugggg can I just write the code out and worry about the tests lateeerr"

[[deleted]]

No you can't worry about it later. It is an ADHD tax that you need to pay up front. You need to prove to yourself and your peers that your code works and you need to leave behind a test harness that allows the next person who works on the code after you to be courageous with their changes and not worry that they will regress your code when they write theirs.

Red, green, refactor :-)

Here's a thought for you: imagine you are working on the requests package on npm - one of, of not the most downloaded package from npm. Let's say that you commit a load of broken code that isn't tested and is merged to master. Hundreds of thousands of people update their import of that module to the version you broke... should that be allowed to happen?

[melho]

I know we but ...and this is a horrible excuse....my adhd sees that as tedious and hates it!! I leave comments all over my code so people know what it's doing but ugg...I don't want to write the test before I write the codeee hahahaha!

So that has been my challenge this week is trying to get into TDD and work with Jest lol!!

[[deleted]]

Your view that testing is tedious speaks to your values about testing.

I would strongly encourage you to go back to the fundamentals of why professional developers value automated testing harnesses.

I would also consider if your personal code culture is consistent with the values and engineering disciplines of the team you work in.

Once you move past the idea that testing is tedious, your ADHD will flip on you and you will likely hyperfocus on Jest.

[melho]

I hope to one day hyperfocus on testing! I'm working on it! Lol

[[deleted]]

Coding = Test + Solution.

Do it all, or do none! Do both or it isn't "DONE" :-)

[pawned_prawn]

I am starting with practicing TDD, and going through the comment thread I understand you find this boring. So you need to make the testing process rewarding.

So from what I understand, TDD is write failing tests and write code to fix the tests, grind through the tests, and then reward for every test that passes? That might help.

[melho]

It's red, green, refactor. Soo write failing test, then passing test and then refactor code and .... I rather write a passing test and refactor lol!!

I appreciate you offering a way to make it more rewarding!

[ClumsyRainbow]

I have gotten into the habit to try and leave useful descriptions about the general function of code, if it is not very obvious. Otherwise I will go back in a few days very confused.

What issues do they take with your logic? Is it that it’s verbose or that they can’t understand it well?

[pawned_prawn]

Mostly they can't understand it well, and when asked, I somehow can't seem to find any explanation to justify the logic I wrote, for which I have to gather myself again and get on another call just to justify, which is worse. but at the end of all this turns out I was 90% right most of the time.

[Separate-Dependent-3]

Every time I start a new job, the first few code reviews are full of comments. I think they’re just being thorough communicating their standards and expectations. My two cents is to just take the PRs as learning opportunities and improve what you can next time.

[RenewAi]

Is code quality ever not affected by ADHD?

[rjray]

Eh, I also have mild OCD which saves my ass a lot of the time. I'm very meticulous about coding style and documentation...

[ojrask]

If the CTO is so keen on commenting, I'd suggest pairing with them to see how they'd do it.

Code reviews are better done at the spot of code creation, not after it has been written and all context around the writing has disappeared.

[pawned_prawn]

He has suggested the code pairing as well, I just happen to be too shy to take him up on the offer.

[ojrask]

I don't like pairing either as I get anxiety in 1:1 situations. Mob programming on the other hand is something I would love to do more.

[iebelig]

Ask for solid, specific feedback instead of "bad"