Bumped into this. It's indeed nice, full of good advises for handling code reviews.
This is a good summary of why I like my type system to be "tight", strong and statically checked.
Good (and long) exploration of the field, going into the different variants provided by various languages.
Nice extracts with comments about finding joy in your (work) life or not. Two paths really... which one are you on?
Too bad this is stretching a bit too far on the politics side (although it's not unjustified, I think it muddies the initial message in this context).
Nice comprehensive list of the smart pointer types in Rust.
A nice list of interesting nuggets from the functools python module.
Interesting use of mob/ensemble programming to tackle technical debt on projects.
Very good points about why elegance matters in code. It's definitely something I try to keep in mind in code reviews. One has to be careful not to use too obscure features of the language though. For instance, you're mostly fine in Python where what it considered idiomatic is somewhat well defined, you're much more in trouble in C++ which isn't as cohesive.
This is actually a good list. Clearly doesn't try to invalidate YAGNI at all, focuses more on this infrastructure things you need on most projects anyway either for debug purpose or because they allow you to change the system easily later which in fact... supports YAGNI.
Very good rant which explains nicely why rewriting some software from scratch is almost never the right answer.
Second time I bump into this book being mentioned somewhere. This good summary really makes me want to read it. At least it gives a clear overview of complexity and how it's tied to other softer topics. I especially like the distinction between tactical and strategic, it's one I do often. I think I'm particularly willing to read the chapters about comments and TDD... from the summary it seems it's where I'm the most at odd with the ideas in there.
I've been banging the testing drum for so long I'd have a hard time to not violently agree with that article. I have a couple of beefs with it though, like the sacrificing encapsulation point but other than that...
Interestingly, I'm going through this book right now and indeed I have to agree with most of this article. It didn't age well, it's become a mix of nice advises, things which are kind of obvious nowadays and points which are clearly obsolete. I find that "The Clean Coder" (different topic I know) aged way better. I think I'll give a shot to the proposed alternative book to see...
Like everything, Pair programming also has a dark side. It's obviously more potent if you do it too much.
Interesting simple exploration. This seems to confirm that there's a lot of hype all around. Whatever the language, even if it is hot today it probably won't look as fun tomorrow when you'll have to maintain millions of lines of it.
Plenty of good advices for code reviews. Fairly comprehensive since it covers both ends of the review.
Good reminder of why idempotence is a very important property.