This satire is more sad than funny, because it&#x27;s true. A manager&#x27;s job isn&#x27;t to understand good code, it&#x27;s to understand business and to know how to effectively get rid of road-blocks for programmers on the team. But how can they make decisions about how to make progress easier&#x2F;smoother for every programmer, if they don&#x27;t understand programming?<p>It&#x27;s kind of like when my kids are arguing without being able to solve it on their own, and I hear it from my office, and have to go over there to potentially solve the problem for them. What if they&#x27;re arguing over a dispute over Pokeyman cards? I don&#x27;t know anything about Pokeyman, and I can&#x27;t learn well enough to give helpful advice or make firm rules on the spot.<p>It seems like the best solution in both cases is to trust the person who&#x27;s most &quot;senior&quot;, either the senior developer or the oldest kid or whoever, to make a judgment call to know what to do here. Probably the other programmer should be brought up to speed on <i>how that code works</i> so when they encounter it next time, it&#x27;s not confusing.<p>Is that always practical or even possible? Probably not in a large corporate setting. But in smaller companies, I&#x27;m confident it probably always is. Of course, so long as the code isn&#x27;t <i>intentionally</i> clever. As long as it&#x27;s at least <i>trying</i> to be clear what it does, that should be good enough. But intentionally clever code should almost always be rewritten, because it&#x27;s usually so clever that even the author can&#x27;t understand what it does in 6 months&#x27; time.