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.

A bit on the sarcastic side but there's definitely some truth to it. This definitely goes against the YAGNI principle.

Very good piece about honesty. It's definitely a core principle to have good communication at work. That being said it covers also all the nuances of difficult situations and how to deal with them.

I definitely agree with this. Managing complexity is our trade.

Discovering Kaketsugi, this is a very impressive craft. True labor of love. This is incredible work, feels almost magical. So much patience and attention to details. The amount of analysis which went into it is amazing too.

This article is spot on in my opinion. This resonates so much with my own experience and ethos... I guess I could have written that if my prose was any good.

Bunch of good advice. In a way it boils down to: name things properly and use static analysis tools extensively. Still, couple of nice operational guidelines which work in most languages.

Very good reminder that as an industry we're quick to blame external factors for our own failures. Of course we can be given a bad hand, but sometimes we'd have failed with a good hand as well.

A good reminder that there is not a one size fits all solution in the tech world. Also be skeptical of the silver bullets that "obviously" everyone should use. Project context matters above all.

Interesting musing on the skills required, why it's actually hard to apply them... clearly it's because you never find a real place to learn them so that ends up being on the job.

Good reminder that the words we use matter. Fuzzy terms like "clean" indeed hide various dimensions to look at the code and the tradeoffs we make.

Or why I'm actually glad I'm not certified even though I could be. This is a good way to stay balanced about all this. At least I'm trying to do my part trying to help people also on the technical areas which are mostly ignored by the "Scrum Industrial Complex" (as Ron Jeffries puts it). Clearly the scrum organizations are not interested in taking up that mantle so it falls onto us.

Interesting thinking about going beyond what's strictly needed for a task.

Very good advises emphasizing empathy and holistic view of products.