And that might not be true of the more important activity. It's a procrastination-like thing: let's convince ourselves we're being productive planning this trivial thing while the other big, scary, difficult thing lurks behind us ominously...
Almost never do the structural elements of good code organization get discussed. Instead we wrap around the axle arguing about things like bracket placement and whitespace. Usually in a manner which damages team cohesiveness rather than building it.
It doesn't matter what conventions you adopt. But not adopting any creates unnecessary friction.
You can reduce the white space conversation to picking a good code formatted. But no formatted is going to fix your nightmare code that you claim is “self documenting”. Fuck that guy. Or better, fire him. Get that weak sauce outta here.
Cleaning my desk or going through my inbox instead of doing whatever needs to be done is just my brain cargo-culting "working at a computer in an office", not unlike a toddler imitating grown-ups. At this point it's very useful to train yourself to talk to somebody about what you need to do, or write a list of the steps you need to take and keep breaking it into smaller parts, until you find it's easier to do what you were about to write than to write it.
It's a classic trick, I call it "starting with a corner", from when you were a child and you had to color the entire background with blue -- it was so off-putting, even if you knew /how/ to do it, it was so much work. But if you start with a corner, at least you got somewhere.
Two tricks in my bag for this:
1. Exactly you already said: "write a list of the steps you need to take and keep breaking it into smaller parts" :)
2. Play competing heel-dragging tasks against each other, when possible.
It's related, because that shortage of expertise is what leads the committee to spend more time on the bikeshed's paintjob than on the safety of the reactor. Everyone's an expert on bikesheds.