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.
Good reminder that "premature" doesn't mean "early". Poor Knuth is so often badly quoted in the context of optimization that it's really sad. The number of times I see "early pessimisation" on the pretense of avoiding "premature optimization". Such a waste...
OK, that looks like cool challenges to train your troubleshooting skills.
Maybe a bit heavy handed in the way it is presented in this piece. Still, constant brainstorming can get in the way of true focus or getting in the zone. This is definitely needed for some problems.
As I could experience both, I concur. Anniversary reviews are just much better for everyone involved.
This feels odd to be hosted on a Google Doc, but this is 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.
Interesting bug in SQLite. In particular look for the conclusion regarding tests and coverage. It's something I often have to remind people of.
OK, the writing is sometimes a bit biased in my opinion (didn't you know Python is superior to any other language?). That being said, this is an interesting resource to get ideas on how the GoF proposed set of design patterns apply in the Python world. I like this kind of "how do things relate" resources.