I’d rather read than watch stuff in general, but I found this fairly interesting (although not a lot that’s super new): www.youtube.com/watch

7,643 unique error messages seems like rather a lot? wix-ux.com/when-life…

I love that these are so accessible, but never manage to find time to watch as many as I would like. www.youtube.com/playlist

I would add Sentry (or a similar tool) to this list: lukeplant.me.uk/blog/post…

💯 this:

“Now the argument always goes: Sure, but you have to manage these machines! The cloud is so much simpler! The savings will all be there in labor costs! Except no. Anyone who thinks running a major service like HEY or Basecamp in the cloud is “simple” has clearly never tried. Some things are simpler, others more complex, but on the whole, I’ve yet to hear of organizations at our scale being able to materially shrink their operations team, just because they moved to the cloud.”

Although it always seems an oversimplification to pick one or the other - in most orgs there will be a mix of systems, some that suit the small or unpredictable wins of public cloud and some that suit going the other way.

world.hey.com/dhh/why-w…

We use chardet quite a bit - if I had dev time still, this would be interesting to check out: pypi.org/project/c…

I found my SAFe training really interesting, and there are elements of Scaled Agile that I’ve found to work well. I’ve also never had to work in a situation where “full SAFe” is really required. But interesting food for thought: safedelusion.com/. h/t Kostas

I’m generally unconvinced by the current wave of generated text tools (except for very specific use-cases) but ignoring practicality, this is pretty cool: twitter.com/chadwhita…

A bit US centric, but personally relevant right now: pages.hired.email/rs/289-SI…

Lots of cool new dev tools, no time for dev any more :( github.com/charlierm…

Great post about handling people leaving. larahogan.me/blog/step…

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.