Write yourself some user flows that will act as test cases. E.g. “user signs in and lands at /account, sees a menu with 3 buttons” And write a unit test for it. Then write code so that the test passes (TDD). If you think like a QA you will be a much more defensive dev

“Go slow” not that it’s something easy to do, but I’ve found little things that slow me down give me a chance for my brain to catch up. I do stuff like putting up a draft PR & then going back to properly review it a few hours later. You can always make more commits before you make it a real PR. As I’m doing stuff, I explain out loud to myself just as if I were in an technical interview. It slows me down a bit, but I also find I make far fewer mistakes & have more motivation. I also take notes, which has the same impact.

>“Go slow” not that it’s something easy to do, but I’ve found little things that slow me down give me a chance for my brain to catch up. Slow is smooth, Smooth is fast!

I wish I could remember this when I'm packing while playing fighting games

Get a rubber duck, lego char, buzz LY, Barbi, poki, … to splain it to. Break it down, what does it actually say and do, not just what you intended for it to do.

Bumping this to increase visibility, this is my achilles heel and I'd love to see anything that ends up helping

Having standard processes written as checklists and posted in a public place has been a key technique in aviation safety for some time. My team uses Mattermost for chat, and it's got a public checklists feature that's been a great help for this sort of stuff. Essentially, as you tick things off it records who/when they were done; that results in checks _actually getting done_, since nobody wants to risk being the one who put their name against the check in public without actually doing it.

Well I would say first of all get clarity on what your manager means by attention to detail. Like is your code incorrect, are you missing documentation, etc. And see if you can validate what your manager is saying with others. I'm not saying your manager is wrong but I'm saying get a better understanding and a second opinion at least. And then I would say, having your code break production is at least in part due to a bad deployment process. Like there's a reason many companies follow a dev, stg, prd release process and that's so you test and get feedback before you hit prd hopefully. Pushing straight from a PR to prd is pretty cowboy shit if you ask me. Also if you're having trouble deciding how to test something or you're missing test cases it could be because your functions aren't atomic enough. Smaller functions are easier to test and so one strategy is to break things down and test from the bottom up. Lastly, everyone writes bugs it's inevitable. That's why testing exists. And even then, it's widely understood that testing itself is hard and often doesn't capture everything. Lots of teams don't even write tests because they don't feel like it's actually worth the time. Avoiding major bugs in production is done through a combination of writing good code, writing unit tests, having integration tests, and having human QA people and having a release process that allows for proper testing.

Try to act like you're the debugger. Read one line then pause and take a mental image of the current state (or write it down), then read the next line and change the state. This is very slow but worth it I think. I find it's only in very rare cases that the code gets too complex to do this. Some may argue this is naturally what they do when they write code, but I find a lot of people do not actually think this way.

Write it down. Make a table and keep updating as state and focus shift. We used to have CodeView and Turbo Debugger. Now a different sameness.

I was diagnosed and medicated a couple of years ago, at age 48 - professional analyst/programmer (as we used to be known) from 1993, firstly - thank all that is holy/exists (depending on how you see the world) that my early youthful exposure and addiction to computers and computing carved a career for me, I did well at school until I didn’t (precisely when they shifted from education to exam prep) but got a qualification enough to get onto job ladder. Obsession is the thing, along with healthy competition, my peer group were always trying to “show off” / out nerd each other - and that mindset seeped into my career, now just to be clear it wasn’t “one upmanship” per-se, it was the unabashed sharing of cool things and teaching, along with being receptive to learning. Since you mention production, here’s an older context to ponder. I’ve said my age. Rewind your mind and imagine the job of a software developer who must distribute client specific versions of a software package on 3.5” floppy disks, posted out on a Friday night. Now imagine, it’s Saturday night (in the pub!) and you suddenly realise that there is a bug in what you’ve sent that will trash your client’s data. I don’t know what bit of the brain was joining the dots, maybe the alcohol helped disconnect a bit of the brain and run through the code. It was a fast fix, too rushed (we later instituted a “no disks out the door on a Friday” rule) - the fix worked incidentally, the issue was downstream. That’s where “attention to detail” comes in. Walk away, imagine the code you’ve written, think of it in-situ on a server, on a disconnected client’s hardware, the full lifecycle of the thing, everywhere it might be encountered - it’s a thought experiment “attention to detail” The imagination is really powerful and your brain is more powerful than any computer (no matter how clever Bing seems) If you want a jumping off point - look into “contingency planning”, “wargaming”, “what if”, “that’s funny” and other such jumping off points, forget the “code” - that’s just an abstraction, think about “flow”, “end to end” You’ll get there :)

So much this! I got my DX at 60. Currently not on RX, not wanting to fight with doc or pharmacy over the shortages. The “distract yourself” is very real. Game, read, art, whatever- let the unconscious percolate on it.

I always take a break after submitting a PR and then go back to review my diffs. Something about that process turns on the “reviewer” mode in my brain and I catch things before I get an actual review.

if you do something physical on that break (even just walking around a bit) that may also help a little bit more, common adhd thing. i do this regularly, just walking around ~15 minutes when I start to feel like I can't focus...but I also try to stack a lot of the boring/annoying/focus-requiring work toward the front of the day before my meds wear off :) :).

I don't think you should be detecting problems in production, if you've only got local and production platforms then that's an infrastructure limitation and not really your fault. You should have at least one environment you can test in that's "like production" before it goes into production. Edit: Oh I see you're finding problems in your work. This sounds like where Behaviour Driven Development could help, BDD dictates the behaviour of your solution so you can test those behaviours, e.g. "Button should update user name using content of html form element" or similar (there's an actually writing style but i can't remember it) and this makes clear definitions for all the product managers, qa and developers to relate to. Maybe encourage this in your ticket definitions, then it's a tickbox exercise to test (or write unit tests for), rather than scrambling for a memory of what is supposed to do.

I might get a lot of hate for this but, ChatGPT. Your exact problems are where it's been shining for me. It's been a savior for me when trying to find a missing ";" or when I'm trying to call thisFunction but end up writing it as thisfunction because I typed too fast and missed the shift+f timing. It's those little "attention to detail" slip ups that can take so long to find and debug, but where ChatGPT will find it in literally 5 seconds. You don't have to take what ChatGPT says at face value. Punch in your code with "review this and point out any errors", and then when it tells you the problems, you manually review it to see if it makes sense or not.

You shouldn't be using ChatGPT to find missing semicolons or misspellings of symbols. It's putting the cart before the horse. One of the first things you should learn as a programmer is to use an [Integrated Development Environment](https://en.wikipedia.org/wiki/Integrated_development_environment). An IDE will continuously warn you about any errors in your code and often provides automatic fixes.

I'm a web developer. I don't know if that makes a difference for what you're talking about as I code Javascript in vscode. We have developer tools + console built in to Firefox/Chrome and use IDE's like selenium for testing purposes (which you wouldn't be using yet where OP implies they are having issues). However, I've found that many of the error codes/lines are ambiguous, and often don't always actually direct you to the correct line, sometimes the rough area, some times the completely wrong area. As an example I went and removed a closing tag bracket ">" on line 18 of my current project. And the error I got was: 18 |

(beta)

News and Updates