The Python Mandate: When Standardization Is a Policy and Not a Plan

A manager decrees: all code must be Python. The team—C, C++, C#, two decades of cruft and a production system that smells faintly of undefined behavior—stops producing anything useful. The neat little model: suppose a manager wants a standard; the cheapest way to signal that to their boss is a rule. The cheapest rule is simple and visible. The actual costs—retraining, porting, testing, the scientists who shouldn’t be touching code—are diffuse and invisible, so they get ignored. (As one commenter put it: “So instead of having that one person learn the languages you already used in their spare time, management had everyone else learn a new language?” Exactly.)

The incentives are the punchline. “You can take classes on your own time on your own dime,” said the memo—translated: compliance is voluntary unless you care about your mortgage. That creates two predictable equilibria: industrious martyrdom (one person sleeplessly becomes bilingual) or collective literalism (everybody reads the policy and does nothing). Reddit’s suggested strategy—what if everyone said ‘no’ and just sat around?—isn’t heroism so much as mathematically inevitable under the rule. Meanwhile the codebase accumulates “infrastructure debt” like a credit card with porn-level interest rates and scientists, who understand experiments not change control, edit production.

Call this phenomenon “uniformity theater”: a performative rule whose primary function is to display control, not to enable work. An imagined memo captures it nicely:

Clause 1: All source files shall be Python. Clause 2: Existing systems shall be ported by personnel unfamiliar with target syntax. Clause 3: Productivity metrics shall reflect rule compliance, not output. Footnote: retired Python programmers exist and are useless for forcing others to change overnight.

So what happened is obvious and instructive: the manager swapped a subtle, hard-to-observe cost (lost velocity, brittle ports, review overload) for a tidy, visible one (a colorable corporate policy to wave at upper management). It’s efficient—if your objective function is “I look decisive in the quarterly meeting.” It’s inefficient if your objective is shipping software. The manager is no longer employed; the rest of the team keeps the codebase and the scars. Small moral: if you want standardization, change the lever (move the one person, change the deadlines, pay for training). Otherwise you’ll end up with uniform code and zero throughput, which is a new kind of compliance nobody asked for.