Reminds me of a Julia Evans post Iin a good way). earthly.dev/blog/chro…

Wondering about doing the Cloud Resume Challenge. www.youtube.com/watch

I love little tool improvements like this memray/pytest decorator.

I think this is probably true in most cases:

Our diagnosis is that individual developers do not pay for tools. Their manager might, but engineering managers only want to pay for discrete new capabilities

It feels like this is where the big players like Atlassian and Microsoft have such a huge advantage because if you can bundle your tool into something the org already pays for it is such an easy win.

I would be reluctant to get into the “build a dev tool” market unless I was just looking to get acquired or wasn’t looking to make money.

I’m not convinced at all about the whole AI coding thing (sending data plus the ethical bit plus the actual value outside of demos).

I pay for tools, but I feel like I’m an exception.

It’s nice that they open-sourced most of their code when they ended. www.kite.com/blog/prod…

I still tend to blunder around the command line picking up things here and there. Summaries like this one are super informative. h/t Kostas.

Really detailed story of the early days of Python.

Working at Sentry remains an all-time career goal. If only they did (world) remote, or would open an office in NZ :) blog.sentry.io/2022/11/3…

Good post on investing in documentation early on. Documentation is so important and so simple to do incrementally - the key is to get started.

I think I have heard 100% of these. twitter.com/forrestbr…

This post about challenges with usernames is old but something that we’re still hitting every so often.

I’ve always used count(*) and never really considered the difference from count(col).

xkcd on point as usual. xkcd.com/2730/

I agree with most of this summary of what software development is really like. Although, I’m not sure that people were really saying anything different.

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