|
I'm currently working on a system that had no locking order defined (and no any other proper way to prevent or handle deadlocks) -- and looking at the face of my colleagues when I announced that, a good proportion (maybe even the majority) never heard about that kind of stuff before (and they typically have been programming for >5 years) It disturbed me a little because this is the kind of stuff you learn in school, and they all have been there. Maybe they did not paid enough attention. Given the kind of programs we are writing, I could be rejecting candidates who don't cite deadlocks has a classic problem, and give a locking order as a classic solution to avoid them, even if they are right out of school. All of that to say: IMO "novice" or "experienced" C++ programmer very often bear the risk of not really predicting the ability to write correct and maintainable code, because for the experienced ones, they can very well never have had any serious approach or mentors to get them to a decent mindset, while at the same time a smart and motivated novice can quickly figure out more and more of what matters, given some predispositions, a proper mentor, and/or a project inducing that. If you find some of the CERT rules basic, you will quickly find most of them in that case. However, they are still useful to be used as a checklist, or for programmers who don't care enough about programming, or simply have been busy implementing piles of features in some kind of spaghetti code (and fixing 10% of the resulting bugs during 75% of their time) during a decade, etc. |
Those that treat it like a craft aim to understand what they are doing, how to do things better.
Those that treat it like "just a job" or a means to an end don't want to know or learn anything beyond what is immediately required to do the task.
An example could be using "git push --force" if git push returns with errors