I use the term most for all the things you need to do or not do in C/C++ to avoid undefined behavior and other problems. Without best practices (that your team agree upon, ideally covered by good literature and understanding) you usually end up with faulty garbage code in complex C/C++ projects. So in this case it's not a tradition or pattern or a convention or the fact that I'm an ignorant copy cat. Also new programmers can learn with the team that this is what is expected here in the company regarding coding practices we consider the best. - Ok thinking again now maybe it's a convention. But partly a unwritten convention of expected behavior.
Just said said to make a point that there are some best practices. Sometimes you have to swollow the pill and try to understand later. There is not always the time to give everybody a full lecture on certain topics if they are complex.
On the other side I totally agree on the fact that an engineer always should be able do explain his decisions. Down to the last fraction.
I'm sure the term is used in other context too, and maybe even misused in discussions sometimes.
Just said said to make a point that there are some best practices. Sometimes you have to swollow the pill and try to understand later. There is not always the time to give everybody a full lecture on certain topics if they are complex.
On the other side I totally agree on the fact that an engineer always should be able do explain his decisions. Down to the last fraction.
I'm sure the term is used in other context too, and maybe even misused in discussions sometimes.