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?
Definitely this, mind the complexity you introduce in your code. Looking smart is not the goal here...
As always from Kent Beck, an excellent set of advices to improve you programming skills.
Faster with less effort doesn't seem to lead to quality code overall.
This is a good set of advices for beginners. I especially like the ones about best practices, trying different things and why it makes sense to be conservative tech wise.
Nice state of the art view on how dynamic dispatch is implemented in several languages. Does a good way showing the trade-offs involved.
An interesting interpretation of what was behind the "move fast and break things" motto which is nowadays blindly followed by some. A bit of a long piece but does the job and propose a more complete view and an alternative approach.
Interesting move, I'm wondering how far this will go. Reuse of those functions in other Wikimedia project will be critical to its success.
Somehow unsurprising, this is often the case: less validation code, but also less automated tests. With types you can write unwanted states out of existence.
This is a good set of properties to strive for. Since the SOLID principles start to show their age this might be a worthwhile alternative.
Interesting dive on the limits of destructors and when they're called. This can have implications on how programs are stopped.
Nice little article with simulations demonstrating why you want exponential backoff and how jitter is an extra layer of protection for the server.