Interesting take of the cognitive overload in bigger teams which end up with more responsibilities. Indeed splitting the teams and the responsibilities can then be a way out.
There are indeed a few architectural problems with the Fediverse as it is. Can this be solved? Hopefully yes.
Interesting take about how performance optimizations can sometimes leverage even more performance gains than you would expect.
Interesting look at the perception of cellphones before they even existed.
Interesting point of view, also lays out nicely how social networks degenerated into social media. I appreciate this kind of perspective.
Success is a two sided coin. Clearly this mass exodus of Twitter users will overwhelm existing Mastodon users and a few instance administrators. It's understandable that is can be perceived as some kind of assault from people not used to the customs. How will the preexisting culture hold? The Pandora box is now opened we shall see.
Good thinking about the recent Mastodon users increase. Highlights fairly well why it's desirable, why it's a better social media platform but also the challenges ahead... including resources consumption.
A simplified mental model of complexity in software projects. It's not completely accurate but is valuable in the way it is easy to reason about it and probably use it for decision making.
Illustrated with Java, still this highlight fairly well the caveats of mutable collections in multithreaded code.
This is a clever and important use of =delete which I sometimes miss in other languages.
Interesting food for thought. Not necessarily easy to see it used in as many fields as the article claims. Maybe a bit too much on the techno solutionist side at times. Still, that sounds like an interesting guideline and path to explore.
OK, that looks like shell history on steroids. Definitely something I will try out.
OK, this is funny. Clear over-engineering non sense for the sake of it.
A good reminder of what's truly at the root of the container idea.
Interesting story on how power plays can sometimes completely hide the fate of a project until it's too late. Definitely a cautionary tale.
Very early days for research on this topic and the sample is rather small still. That said the results are interesting, there seems to have a few biases inherent to the use of such an assistant, there's also clearly a link between the AI agency and the quality of what gets produced. We'll see if those result holds to larger studies.
Indeed, I encounter that same idea in some people. I'm unsure where it comes from, it feels like reading and extrapolating from something more reasonable (it's like the "one test per line" I sometimes hear about). Bad idea indeed, it's fine to have several assertions, it's probably often required to avoid complexity explosion in your tests. This of course doesn't mean your test should become unfocused.
Very important topic. Nice to see more such teams appearing and thinking now focusing on how to structure them.
What the title said, there's nothing fancy about optimizations. It's mostly well known knowledge, doesn't change much over time or on different stacks... still it's very satisfying.
Definitely this! It's important to model properly your domain and leverage smart value types everywhere it makes sense. This can prevent quite a few different types of bugs.