errors in claims of good and bad style
The primary way that we learn is from studying our errors - recording them into archives, sifting and sorting the error archives into piles, taxonomies, ontological schemes and then using that structure as we move forward to reduce error.
When there is a dispute between two programmers regarding whether a piece of code is in good style, there are two varieties of error that I've seen (and there may be plenty of other kinds). On the one hand, the programmer claiming that the code is in bad style may be underfamiliar with the code.
Modern industrial code (as opposed to theoretical future code) is a bit like anime-powered-armor. Each suit of powered armor is different, just as each application is different. Without a pilot/maintainer, it may be able to do a rigid, ritualistic mechanical task, and if the world is very stable, it might last for ages. However, if the world is changing unexpectedly, or if conflict with a non-empty suit is necessary, then you would greatly prefer the combination of suit+pilot/maintainer.
A pilot climbing into a long-abandoned suit overgrown with vines, or a suit maintained by someone else and reeking of their sweat, may find it uncomfortable, awkward to handle, or disgusting. When managing a team of powered-armor pilots in this sort of reverse-engineering or technology-acquisition situation, you should close your ears to the pilots complaints of awkwardness, inefficiency, and disgustingness, and encourage them to familiarize themselves with the capabilities and construction of your newly-acquired suits.
However, there is another kind of error; a programmer claiming that code is in good style may be overfamiliar with the code. Pilots grow accustomed to particular wonky glitches that need to be worked around, and the arcane rituals required to keep their suits running. To some extent they even have an incentive, in the form of job security, to keep the glitches and rituals. As a manager of a team of powered-armor pilots, if you do not prod your pilot/maintainers into the kind of steady improvement that modernity expects, your pilots will (accidentally, with all the best intentions) lapse into overfamiliarity.
In particular, there is a pattern of organizational failure that managers and their pilot teams fall together into, which is largeness. The team (or the most experienced leaders of the team with the power to overrule the others) have become overfamiliar with some aspect of their suits. As the world changes (and the world is always changing, due to the steady improvement of modernity if nothing else), the team responds to each change by increasing the suit's size, or the team's size, or both. The manager trusts the team when they say they need to make the suits bigger (after all, they're the experts) and is somewhat flattered or otherwise advantaged by the resources required.
Therefore, when managing a team of powered-armor pilots, one way to prod your pilot/maintainers into steady improvement is to repeatedly demand the suit to be smaller.
To recap, here is my advice for managers of anime-powered-armor teams:
When there is a dispute between two programmers regarding whether a piece of code is in good style, there are two varieties of error that I've seen (and there may be plenty of other kinds). On the one hand, the programmer claiming that the code is in bad style may be underfamiliar with the code.
Modern industrial code (as opposed to theoretical future code) is a bit like anime-powered-armor. Each suit of powered armor is different, just as each application is different. Without a pilot/maintainer, it may be able to do a rigid, ritualistic mechanical task, and if the world is very stable, it might last for ages. However, if the world is changing unexpectedly, or if conflict with a non-empty suit is necessary, then you would greatly prefer the combination of suit+pilot/maintainer.
A pilot climbing into a long-abandoned suit overgrown with vines, or a suit maintained by someone else and reeking of their sweat, may find it uncomfortable, awkward to handle, or disgusting. When managing a team of powered-armor pilots in this sort of reverse-engineering or technology-acquisition situation, you should close your ears to the pilots complaints of awkwardness, inefficiency, and disgustingness, and encourage them to familiarize themselves with the capabilities and construction of your newly-acquired suits.
However, there is another kind of error; a programmer claiming that code is in good style may be overfamiliar with the code. Pilots grow accustomed to particular wonky glitches that need to be worked around, and the arcane rituals required to keep their suits running. To some extent they even have an incentive, in the form of job security, to keep the glitches and rituals. As a manager of a team of powered-armor pilots, if you do not prod your pilot/maintainers into the kind of steady improvement that modernity expects, your pilots will (accidentally, with all the best intentions) lapse into overfamiliarity.
In particular, there is a pattern of organizational failure that managers and their pilot teams fall together into, which is largeness. The team (or the most experienced leaders of the team with the power to overrule the others) have become overfamiliar with some aspect of their suits. As the world changes (and the world is always changing, due to the steady improvement of modernity if nothing else), the team responds to each change by increasing the suit's size, or the team's size, or both. The manager trusts the team when they say they need to make the suits bigger (after all, they're the experts) and is somewhat flattered or otherwise advantaged by the resources required.
Therefore, when managing a team of powered-armor pilots, one way to prod your pilot/maintainers into steady improvement is to repeatedly demand the suit to be smaller.
To recap, here is my advice for managers of anime-powered-armor teams:
- Do not punish error (your team might begin to hide it). Instead, record error into append-only archives; their monotonic growth is how you get stronger.
- Require the members of your team to demonstrate deep familiarity with the technology before listening to vague complaints of ugliness/awkwardness/bad style.
- Repeatedly prod the most senior members of your team out of overfamiliarity by requiring them to shrink the technology.