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.
Indeed, be careful when using "just". It's often doing more harm than anything.
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.
Oh that looks really cool... will need quite some time to go through this though.
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.
Nice succinct form to present a strategy.
Interesting framework for sustaining a strategic train of thoughts for the long term. This can't be a fix thing, it needs to live and breather which this approach seems to foster.
Interesting take on burnout as an organizational phenomenon and the consequences. This is not simply about the amount of work.
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.
Finally out of Google Docs it seems. Better version for sharing around. Still an interesting list of case studies and opinions around SAFe. I learned a few things, I didn't realize it's creation was so disconnected from the pre-existing agile community. It all seems to confirm my opinion that it's better to stay away from it though. The few organizations I know of which use it are clearly very much in a command and control mode. This is going backwards.
If you like remote work, then you need to make sure your written communication is good. There's a handful of proper guidelines in this paper. Good reminders.