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 :)
Thorsten – I’ve so enjoyed coming back to this piece over the last few months. Each time I mull it over and gain additional value. I wanted to post a short piece on how I think about the grouping of these, and I’ve done so here (https://go.michaelflores.io/The-basics). I hope you’ll find your work is attributed appropriately here. Please let me know if I’ve erred in referencing it, and I’ll be happy to correct. But more than that, happy to hear any thoughts on the grouping. Cheers!
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!
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".
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.
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 😅
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.
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
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.
Absolutely beautiful stuff, distilled to its purest form. Thank you for this
Thank you!
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.
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 :)
I think a lot about this post. Almost everyday.
Excellent post! thank you
Thorsten – I’ve so enjoyed coming back to this piece over the last few months. Each time I mull it over and gain additional value. I wanted to post a short piece on how I think about the grouping of these, and I’ve done so here (https://go.michaelflores.io/The-basics). I hope you’ll find your work is attributed appropriately here. Please let me know if I’ve erred in referencing it, and I’ll be happy to correct. But more than that, happy to hear any thoughts on the grouping. Cheers!
Thanks for sharing, Michael! And glad you got something out of it :)
this is really wonderful, I shared it to my team
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!
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
Amazing.
What do you do when you have colleagues who are missing more than a few of these basics?
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.
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 😅
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.
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
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.