A Microsoft survey finds roughly 15% of engineer time is spent actually writing code. That increases to 30% if count fixing bugs, which I’d argue should not count as the efficacy relies on being able to understand code that already exists. The point here is, the majority of the value engineers bring is their ability to understand the problem space and how their system solves that problem.
However, the survey also finds that engineers prefer days where they get to write code (a good day is 18% coding, a bad day is 11% coding). To have more good days, time must be taken from other parts of the job, so from these meetings, etc, where the engineers’ understanding of the system is necessary. One way to take time from those is to ensure the system is easier to understand, thus explaining it, or solving new problems in the domain are less time consuming.
So, be selfish. Make your system simple. Avoid promotion oriented design.
I wrote an entire talk semi-related to this, Quality Qualities.
Code is for humans, not for computers.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
-Brian Kernighan; Kernighan’s Law