Not sure how much of this post on tech debt handling I agree with. These seem naive:

• The first rule is not to create tech debt in the first place.
• The PR (Pull Request) that creates tech debt should come paired with the issue to deal with it.

This seems like a nice idea but challenging:

• It is recommended (but optional) to demo the results in the next team demo.

In general this seems less flexible than just saying “20% of the quarter is allocated for tech-debt”.

We’ve tried a bunch of solutions along these lines over the years. I’m not sure which of them have been most successful.

Really interesting post giving examples of how dynamism in Python is valuable. Interesting not only for the main content and it’s rebuttal ro another piece, but as examples of tools doing interesting things.

Interesting thoughts on older languages (C++ in this case) and memory safety. h/t Dorin.

Solid coverage of how email works. h/t Teo.

This leaddev post, however, does go into what to actually do about monitoring debt. h/t Kostas

This SO post on monitoring debt seems to miss over half of what monitoring debt actually is. Too many things being monitored. Bad noise levels in alerts. Knowing when the monitoring itself is failing. Updating monitoring systems both for just general bug fixes and for new functionality. Old monitoring that is no longer required. Etc.

A very long time ago, I designed a CS course that I felt would fill in the missing gaps of Massey’s CS degree. A lot of it was material like this “missing material”, except I only had the outline, not all the content. h/t Kostas

Nice post from fly.io about where issues have been and what’s being done about them. I wish more people were allowed to be this transparent. Maybe it’s just the people I interact with, but I feel everyone values this. h/t Kostas