Is this really to improve your work? Or make you dependent? In the end it might be the user which looses.
There is a real question about the training data used for the coding assistant models. It's been a problem from the start raising ethical concerns, now it shows up with a different symptom.
The definition of legacy code is ambiguous enough. We generally mean "bad code" (the wrong definition to me...). What about seeing things differently and trying to leave a great legacy behind us?
This is very true. It's not like whoever produced bad code is particularly stupid, in most cases it's the context around which breaks the people.
A good list of characteristics to aim for. Gives clue about the quality of your software architecture.
This is something I've definitely seen indeed. There are clearly a threshold effect in the amount of code you have to manage. Solutions working at smaller amounts don't work anymore a couple of order of magnitudes higher, and vice versa.
There's a balance to strike on quality. Too much or too little and you won't be able to progress towards the user needs.
It's all written oriented toward C++ use. That said I think most of it equally applies whatever the language.
The trend keep being the same... And when the newer models will be trained on FOSS code which degraded in quality due to the use of the previous generation of models, things are going to get "interesting".
This needs repeating but yes, quality matters in test code too.
Decades that our industry doesn't improve its track record. But there are real consequences for users. Some more ethics would be welcome in our profession.
I'm not really a fan of the leaderboard part of their approach. That said, if the maturity of the organisation allows it, having such bug squashing sessions is a good idea.
Didn't know about that clippy feature. This is neat, allows to precisely target some of your project rules.
A good list of code smells to pay attention to in Rust. Also provides patterns to avoid such smells.
A good reminder that you don't want your code base clean to the point of being sterile. You have to fight off the mess yes, but some of it can stay if it provides affordances.
An interesting set of principles for code reviews.
An explanation about where the SRP comes from and what it really means. It's very often misunderstood or overlooked.
I'm not fully aligned with all of this article. That said, it's an interesting way to frame the topic of how we're having to make tradeoffs all the time.
Easy to misunderstand as an elitist stance... But it's not the way I read it. Churning more code faster isn't going to help us, you need to take the time for people to grow and improve. It's not possible to achieve if you're drowning in eager beginners.
A good reminder that long hours are not a sign of success with your project... on the contrary.