A bit of an unusual view about cohesion. The approach is interesting though.

Nice piece, aren't we loosing something when we eliminate boredom from our life?

When hype meets group think, you can quickly create broken culture in your organization... We're seeing more examples lately.

I like this piece. In most case it's the thinking which is important not the writing. So even if the language is subpar it's better if you write yourself... except if it's not worth the effort in the first place.

Looks like the productivity gain promises are still mostly hypothetical. Except on specific limited tasks of course but that doesn't cover for a whole job. Also, when there is a gain it's apparently not the workers who benefit from them.

This also carries privacy concerns indeed even for local models. It all depends how it's inserted in the system.

This is almost by definition. The post mortem needs to be wisely crafted to look also at previous incidents and the actions to mitigate them.

Nice trick! Using vim as man page viewer. I shall try this.

The introduction of concepts has indeed been a nice improvement to the language.

I wonder how much the focus on Python biased that study... Still, maybe we've been wrong at so much emphasis on math skills for computer science and computer engineering curricula.

Nice and down to earth tips for your technical talk to go well.

Interesting trick in Java internals which is especially improving map lookups.

This is an important position paper in my opinion. The whole obsession towards the ill defined "AGI" is shadowing important problems in the research field which have to be overcome.

This move is really unsurprising... It's bound to become another channel for advertisements to try to cover the costs of running it all.

A bit long and dated for a some advice. Still it does a very good job going through all the different type of tests you'll want to find on your project and how they're structured.

Need to teach security basics to your family, friends and neighbors? Here is a nice resource to do a good job there. We often approach the task the wrong way.

A good in-depth article about pair programming. Shows well the pros and cons.

We often hear that question about the trade off between quality and cost. The question is badly framed though. If it's low quality it's requires more effort to add or change features... and so it's more expensive mid-term (not even long term).

A good reminder that reviewers have many things to keep in mind and evaluate. This is why what can be automated should be automated.

This is one of the best references I know on the topic. It's not that long, to the point and all developers should know it.