Good piece. I like how it frames the debate, asking the right questions on where might be the assumptions on how testing is done.

A good set of skills to develop to bring technical changes to a project. It doesn't need to be overwhelming or a fight. If you doubt, if you have empathy and if you slice the proposals it can become doable and help the people around you.

Excellent piece about naming things in code. The conclusion is perfect of course: it's hard but it pays off.

Lots of very good points, I'm a proponent of TDD but I strongly agree with this. If it's painful and not fun, find a way to do it differently. There's likely a tool or some API you miss. Manage your effort.

Definitely this. I regularly try to pick up new languages for this exact reason. Every time it improves the way I use the languages I already knew.

Very good list. It sets the bar very high! I know most people will fail on a few of those items. It's fine this gives a good direction and something to aim for.

Lots of good insight for a long career as a programmer. Definitely a few things I live by and a few... I tend to loose sight of. More progress to be made.

Indeed a good list of attributes. Not sure if that's the only attributes you want in a team but that's definitely must haves in at least one person.

I definitely recommend adopting this mindset. Been doing most of that for a long time and this definitely helps.

Very nice catalog! Looks like a useful reference.

Hear hear! It's not supposed to be easy, you need to hone your practices.

Very interesting musing about the technical terms we often use wrongly and how it difficult it is to be understood.

I don't quite subscribe to some of the terms used (even though I see the point of not calling this API). Still I think this is a very good way to approach design, it's also why I like TDD, the tests force you to see how the code is used. If it ain't pretty there's a problem.

Definitely this, showing care is the best thing you can do in services. Otherwise you can only do a mediocre job.

I'm not sure the boundaries are a clear as laid out in this article. That said it's an interesting way to frame things. Also, clearly it's at the intersection of the so called tribes that the most interesting things happen.

Likewise I'm more and more unconvinced about the unit vs integration tests distinction. It's likely a continuum between them. I like the proposed axes for classification here. I wish they'd be a bit more orthogonal though.

This explains fairly well the reason why I spend so much time doing git rebases or push for more readable history in branches submitted for reviews. It helps a lot with the reviews and with finding root causes of issues later on.

As always, what really matters in the end is the context

Interesting interview which explores quite a bit mob programming, where it's coming from, why Woody Zuill pushed for it, how it is done, etc. I didn't expect his opinion on why he thinks the name being controversial actually helped spark the conversation around the practice... Very inspiring how he practiced for years to feel comfortable being on stage. I also love at how humble this person is through and through.

Excellent answer, really loves how humble Ron Jeffries writings usually are. I like how he doesn't prescribe what to do, but instead describes what happens to him when he does something he shouldn't (or doesn't do something he should). He's definitely human and slips like us all.