“Clean” code, horrible performance
Malicious compliance for C++ programmers. This is the person who thinks they&#x27;re clever for breaking stuff because &quot;You didn&#x27;t say not to&quot;. Managing them out of your team is likely to be the biggest productivity boost you can achieve.<p>In the process of &quot;improving&quot; the performance of their arbitrary benchmark they make the system into an unmaintainable mess. They can persuade themselves it&#x27;s still fine because this is only a toy example, but notice how e.g. squares grow a distinct height and width early in this work which could get out of sync even though that&#x27;s not what a &quot;square&quot; is? What&#x27;s that for? It made it easier to write their messy &quot;more performant&quot; code.<p>But they&#x27;re not done, when they &quot;imagine&quot; that somehow the program now needs to add exactly a feature which they can implement easily with their spaghetti, they present it as &quot;giving the benefit of the doubt&quot; to call two virtual functions via multiple indirection but in fact they&#x27;ve <i>made performance substantially worse</i> compared to the single case that clean code would actually insist on here.<p>There are two options here, one is this person hasn&#x27;t the faintest idea what they&#x27;re doing, don&#x27;t let them anywhere near anything performance sensitive, or - perhaps worse - they know exactly what they&#x27;re doing and they intentionally made this worse, in which case that advice should be even stronger.<p>Since we&#x27;re talking about clean code here, a more useful example would be what happens if I add two more shapes, let&#x27;s say &quot;Lozenge w&#x2F; adjustable curve radius&quot; and &quot;Hollow Box&quot; ? Alas, the tables are now completely useless, so the &quot;performant&quot; code needs to be substantially rewritten, but the original Clean style suits such a change just fine, demonstrating why this style exists.<p>Most of us work in an environment where surprising - even astonishing - customer requirements are often discovered during development and maintenance. All those &quot;Myths programmers believe about...&quot; lists are going to hit you sooner or later. As a result it&#x27;s very difficult to design software in a way that can accommodate new information rather than needing a rewrite, and yet since developing software is so expensive that&#x27;s a necessary goal. Clean coding reduces the chance that when you say &quot;Customer said this is exactly what they want, except they need a Lozenge&quot; the engineers start weeping because they&#x27;ve never imagined the shape might be a lozenge and so they hard coded this &quot;it&#x27;s just a table&quot; philosophy and now much of the software must be rewritten.<p>Ultimately, rather than &quot;Write code in this style I like, I promise it will go fast&quot; which is what you see here, and from numerous other practitioners in this space, focus more on data structures and algorithms. You can throw away a <i>lot</i> more than a factor of twenty performance from having code that ends up N^3 when it only needed to be N log N or that ends up cache thrashing when it needn&#x27;t.<p>One good thing in this video: They do at least measure. Measure three times, mark twice, cut only once. The engineering effort to actually make the cut is considerable, don&#x27;t waste that effort by guessing what needs changing, measure.