14 Comments
Mar 26Liked by Thorsten Ball

Absolutely beautiful stuff, distilled to its purest form. Thank you for this

Expand full comment
author

Thank you!

Expand full comment
Mar 25·edited Mar 25Liked by Thorsten Ball

I've organized your points into [this](https://share.cleanshot.com/ck5x1FbQ). I like it even better with this structure.

I've also added the list to a "review my performance against Thorsten's baseline" item for the last Sunday of every March.

Expand full comment
author

Incredible. It's very interesting how you perceived some of bullet points, i.e. I wouldn't have grouped the "read the docs, the ..." under "work to PRs", but I can see why you see it that way :)

Expand full comment

this is really wonderful, I shared it to my team

Expand full comment

Great list! "Never trust a test you've never seen fail" is one of my favourite pieces of dev advice, and I like how you worded your own take 😄

Also enjoyed the ones possibly related to meetings! I'd add "no agenda, no attendance" 😄 If you're putting a meeting together write a clear agenda... so people can do their homework and stand-out, as per your advice!

Expand full comment

That's a really good list of things to aim for. I'd augment it with: don't follow instructions blindly, be curious. I believe it is a more general way of saying "know why your fix is a fix".

Anyway, very good post. I'm recommending it to my friends and in my newsletter too: https://open.substack.com/pub/bitmaybewise/p/abend-dump-9?utm_source=share&utm_medium=android&r=915pz

Expand full comment

What do you do when you have colleagues who are missing more than a few of these basics?

Expand full comment
author

That's a tough question and the answer can range from "ignore it" to "give them advice" to "talk to their manager" to "leave" and it depends on a lot of things. Really hard to answer. I'd say the first step is to try to have patience, accept that different folks are different, then what exactly you'd want to see changed (this step might reveal more than one might think), then think about how to achieve that in baby steps, then try the first baby step.

Expand full comment

Let’s say it’s the “quick review please” basic. Im not sure whats the baby steps are here, tried going through manager but our manager (we are in the same team) kind of didn’t care 😅

Expand full comment
author

Maybe the first baby step is just talking to that person and telling them (a) what you perceive to be the facts (b) how that makes you feel. No accusations, no insults, just stating facts: input (situation) and output (your feelings). Then check whether they see it the same way or differently. If you agree on the situation, then continue to talk about how to change it.

Expand full comment

One thing I personally would add is that before you ask for review all commits are squashed or if there are several commits all of them should make sense and none of them is just WIP that was completely reversed two commits later in the same PR

Expand full comment
author

I'd say that depends on what the workflow in the repo/team/company is. Some teams squash & merge, others merge. I personally only look at commits one by one if the reviewer asked me to. Otherwise I look at the complete diff.

Expand full comment