reading other people's code is quite exhausting, especially if they haven't put a lot of thought into how others might perceive it.

(I too am guilty of this, but I try really hard to make it easier on the cognitive load)

What I've picked up that's worked well for my team (a lot of the rules of good English writing applies to code):

Make your code **scream** each line's intention to the reader with good names and layout.

High-level methods should summarise/abstract low level concepts. E.g. if it's a command class, the main handle() method should be no bigger than 15 lines, and delegate to well named / extracted methods. I should be able to glance at handle() and know almost exactly what the command is doing and _why_. Think of a book blurb or page of contents. This applies to almost everything.

Don't be scared to be verbose in test files - they're literally runnable _specification_. They document it so be clear in what that spec is.

Don't leave misleading and dead code/comments in your code

Or reading your own code a year later...

@MammaNeedHummus

"Don't leave misleading and dead code/comments in your code"

Doesn't this depend on the turnover rate?

@Demolishun which turn over rate? There's a few

@MammaNeedHummus I was thinking some kind of job security.

@MammaNeedHummus yeah both codebases I've had to deal with over the past 4 months have hundreds of lines of methods commented out. I normally just delete things if I don't need them anymore, you have a git history for that, don't you?

@12bitfloat exactly. I came back to some of my very old code I wrote when I was still a junior and it's kinda bad, but at least I made my variable names and method signatures understandable most of the time :D

This is why I try hard to write human-readable code, for my future self.

@jestdotty even that rule can be misinterpreted and abused

@jestdotty I used to do this too, but then I realised I never reference old code and just started deleting things that were commented out. Except TODOs, which should ideally be added to some kind of backlog that's not accessible to nosy product managers that believe dealing with technical debt is not worth it.