
How do you avoid making sloppy mistakes while writing code? - jamesvanderbeek
I have ADHD, and my career has basically been job after job of barely staying afloat. No matter how hard I try, it appears I am blind to my own mistakes until they are pointed out in a code review. I am putting in more effort than I ever have. I write tests. I scrutinize my pull requests before submitting them. But no matter how good I feel about the code before it&#x27;s reviewed, there&#x27;s always something &quot;lazy&quot; or &quot;sloppy&quot; that is glaringly obvious to everyone except me.<p>My system for doing productive work is, and has always been, broken. As I get further into my career, not being able to course-correct becomes more and more of an existential crisis. ADHD brings with it countless other problems (many of them time-management related), but these repeated careless mistakes are, once again, putting my job at risk, and making me loathe myself.<p>I would be grateful for advice.
======
zarmin
From a similar thread:

>I've found that copious use of assert statements has done wonders for
reducing the amount of time I spend debugging. Its a good idea to use enough
assert statements that when there's a problem it is reported immediately
instead of propagating and causing weird symptoms that you have to track down.
At the beginning of every function I think to myself "what am I expecting
here" and then put in 2-3 assert statements to make sure my expectations are
met. For example, if I'm passing a data structure that I expect to be filled,
I assert that it is non empty.

>When I encounter a bug I write an assert that reveals the problem before I
fix it in order to prevent having to deal with the same issue more than once.
This is especially big for me since I work with a lot of (other people's)
data.

------
recessionproof
Hmm. Never identify and internalize the logic of criticism. Consider reframing
what you just said in a more positive light.

Let's forget for the second your self diagnosis and think about it as
engineers.

What specifically is glaringly obvious or sloppy about your code? How do
others notice and you don't? What techniques are they using to read the code
that you're not? Are they reading your code while they're well rested while
you were writing the code later in the day? How often do you take breaks? Do
you try to take naps? Do you use coffee sparingly? How is your diet? Do you
exercise?

My point is there are a bunch of things you should figure out before deciding
to be so down on yourself. If you honestly try to answer the questions I posed
then I'm certain you will make progress towards being a better coder.

------
maxk42
Well since you're already writing tests, I think the X-factor here might just
be time + practice. Perhaps you could ask to try pair programming for a while
to improve your skill? Sometimes it's helpful to observe how others approach a
problem.

------
Ayesh
\- Use a proper IDE, and note a text editor with 45 plugins.

\- Use strict typing whenever possible. PHP has scalar typing now, and TS for
JS.

\- Use static analyzers and bake them to your CI workflow.

\- Unit tests.

\- Test your unit tests with mutation tests.

Overall, non-sloppy code takes more time, and you'll often find yourself
spending more time in tests and code architecture than writing the core code.
But in the long term, it will save time. I'm refactoring a project I worked 6
years back, and the test suite brings tears to my eyes, looking how thorough
it was, which made the code decoupled, ending up me spending just a few days
to refactor it all!

------
streetcat1
So first, try to use UML diagrams. Both the class diagram and the seq diagram.

I.e. you should start writing code only after you have the full design in
details. In short, think of yourself as a human code generator.

The issue with programming is that you need to hold both the 3000 level
picture and the 0.1 level, so working with diagrams should help.

The second thing to think about state machine, especially one that are
specified by tables.

Before you write the code, make a table of each input state, and map it to
your program output state. This would make sure that you did not forget
anything.

Look at the work of David Parnas in this area.

------
kace91
Have you considered favoring languages and environments that work well for
you? Strongly typed languages, static analysis, good linting tools, etc. The
more things caught by your machine, the less you have to take care of.

You could also try asking your colleagues what they look for in a code review,
then mimicking their method when judging your own work before submitting.

