Ever wondered how this operator is implemented in Rust? It's not that complicated.

It might not look like a lot from the outside, but "just implementation details" in fact hides quite some work and complexity.

That's what happens where references are half hidden in a language. You think each closure get a different copy but in fact they all refer to the same object.

Definitely a nice Python trick. Fairly elegant, I'll try to remember it.

Definitely this. In a world where LLM would actually be accurate and would never spit outright crappy code, programmers would still be needed. It'd mean spending less time writing but more time investigating and debugging the produced code.

Interesting research! Is reading code a math and logic task? Is it a language task? Well... it might be its own thing.

Good food for thought. Explains quite well the factors which impact software development.

Interesting take about the mantras often used in our profession. They shouldn't be treated as laws, but as proverbs carrying a piece of contextual wisdom. It's thus unsurprising that they tend to contradict each other. This contradiction should make us pause and think.

Well, maybe our profession will make a leap forward. If instead of drinking the generative AI cool aid, if we really get a whole cohort of programmers better at critical skills (ethical issues, being skeptical of their tools, testing, software design and debugging) it'll clearly be some progress. Let's hope we don't fall in the obvious pitfalls.

Since there's a clear tendency in the developers I meet to "extract at all costs", this is a good reminder that sometimes you need to inline the code first. This very often brings better clarity in the context of use. In turns this leads to a better final extraction.

Funny read, it has lots of good advice for starting up with Rust.

Indeed, naming, comments and communication styles are three aspects often overlooked during reviews. They are very important though and shouldn't be neglected.

Hopefully nobody is handling configuration by assuming the user will modify the source code or build scripts by hand. Unfortunately I still encounter it from time to time...

Wondering how one can design a coding assistant? Here is an in depth explanation of the choices made by one of the solutions out there. There's quite some processing before and after actually running the inference with the LLM.

All the good reasons why productivity increases with code assistants are massively overestimated. To be used why not, but with a light touch.

Good criteria to decide to pair or not. This is still not practiced enough. Maybe knowing when it's best to reach out to pair will help get more into it.

On the importance of invariants and consistent requirements in our trade. Admittedly it's a long demonstration but it show the point well.

Very interesting piece. The DORA metrics are a good thing but I always felt they're kind of dry and missing something. On the other hand surveys which are more qualitative give also interesting results but come with their own biases. The idea pushed here for better qualitative surveys and to combine them with quantitative metrics like the DORA one is definitely a tempting way forward.

Definitely this. It might ultimately impact the abstraction levels accessible to us for coding... but the skills will still be needed. Natural language is too ambiguous for the task.

Interesting how feeling stupid can actually push you toward good engineering practices, isn't it?