I don’t think that this is C++-specific. It applies to every language. It comes down to, “When possible, write boring code.” And I would generally agree with that directive. Cleverness usually requires a certain insight into the problem that is rarely formed before actually trying to solve it.
I’ve heard people say that they prefer maintaining code written by mathematicians or scientists who are competent programmers over that built by professional software engineers. The former set are content to write boring code to solve a problem they find interesting, whereas the full-time programmers have a lot of their professional identity tied up in being able to do the hard stuff. To tell the truth, I think that most corporate programmers, although well-paid in comparison to almost anyone else in a time of collapsing wages, know that they’re underemployed and therefore either (a) deliberately over-engineer things in order to prevent their bosses from finding out, or (b) in the more common case, earnestly and benevolently (but dangerously, from a maintainer’s perspective) over-solve problems out of a desperate need to make their jobs more interesting than they actually are.
It’s also a fact of our field and our mindset. It’s not socially acceptable to stop learning and stagnate and, moreover, most of us don’t want to. This means that we have to learn something new in order for a project to be worth doing. The boring approach that meets business requirements but isn’t intellectually interesting gets ignored. And to be fair to us, it’s probably faster to do things in the interesting way, because most of us are wired so that we drop by a factor of 5-20 in productivity if we’re bored. It does mean that sometimes (and this is far from always being the case, because intellectual effort can be spent on communication and pedagogy, just as it can be spent on cleverness and opacity) we produce things that are more complex than necessary and hard to maintain.
If we were machines, the solution would be to separate out the business-grade programmers, who write software according to business requirements and the needs of stakeholders, and the research-grade programmers, who come in and solve the intellectually difficult challenges. They’re two different jobs, and the confusion about which one a “programmer” is supposed to fill causes a lot of unhappiness and mismatched expectations. (To me, Agile Scrum seems to be largely built to shoehorn engineers into the business-grade developer role, which is why highly intelligent people dislike it.) Of course, we’re humans, and very few people want to be seen as a “business-grade developer”. So I don’t know what to do about that.
I don’t think that this is C++-specific. It applies to every language. It comes down to, “When possible, write boring code.” And I would generally agree with that directive. Cleverness usually requires a certain insight into the problem that is rarely formed before actually trying to solve it.
I’ve heard people say that they prefer maintaining code written by mathematicians or scientists who are competent programmers over that built by professional software engineers. The former set are content to write boring code to solve a problem they find interesting, whereas the full-time programmers have a lot of their professional identity tied up in being able to do the hard stuff. To tell the truth, I think that most corporate programmers, although well-paid in comparison to almost anyone else in a time of collapsing wages, know that they’re underemployed and therefore either (a) deliberately over-engineer things in order to prevent their bosses from finding out, or (b) in the more common case, earnestly and benevolently (but dangerously, from a maintainer’s perspective) over-solve problems out of a desperate need to make their jobs more interesting than they actually are.
It’s also a fact of our field and our mindset. It’s not socially acceptable to stop learning and stagnate and, moreover, most of us don’t want to. This means that we have to learn something new in order for a project to be worth doing. The boring approach that meets business requirements but isn’t intellectually interesting gets ignored. And to be fair to us, it’s probably faster to do things in the interesting way, because most of us are wired so that we drop by a factor of 5-20 in productivity if we’re bored. It does mean that sometimes (and this is far from always being the case, because intellectual effort can be spent on communication and pedagogy, just as it can be spent on cleverness and opacity) we produce things that are more complex than necessary and hard to maintain.
If we were machines, the solution would be to separate out the business-grade programmers, who write software according to business requirements and the needs of stakeholders, and the research-grade programmers, who come in and solve the intellectually difficult challenges. They’re two different jobs, and the confusion about which one a “programmer” is supposed to fill causes a lot of unhappiness and mismatched expectations. (To me, Agile Scrum seems to be largely built to shoehorn engineers into the business-grade developer role, which is why highly intelligent people dislike it.) Of course, we’re humans, and very few people want to be seen as a “business-grade developer”. So I don’t know what to do about that.