<i>&quot;Don&#x27;t write C unless you need extreme performance,</i><p>This is the wrong mindset and has been the guiding principle behind over a generation of poor programming discipline.<p>You might be able to rationalize that you don&#x27;t always need extreme performance, but it&#x27;s not about performance, it&#x27;s about <i>efficiency</i>. Efficiency <i>always</i> matters. We live on a small planet with finite resources. Today, the majority of computing is happening with handheld portable devices with tiny batteries. Every wasted byte and CPU cycle costs power, runtime, and usability.<p>Even if you&#x27;re coding for a desktop PC or a server application - every bit of waste costs electricity, generates heat, increases cooling load. Every bit of waste costs the user real money, even if they don&#x27;t see the time that you wasted for them.<p>Performance is a <i>side-effect</i>. The only thing that matters is efficiency, and it matters <i>all the time</i>.<p>Most of today&#x27;s programming problems come down to laziness and fear of &quot;premature optimization&quot; (which is obviously bunk). It <i>is</i> possible to write perfect C code that runs correctly the first time and every time. You do that by planning ahead. Formal specs are part of this.<p>The same consideration applies to writing, in general. I witnessed this first hand, when I worked at the computer labs at the University of Michigan back in the 1980s. When all anyone had was an electric typewriter, they planned their papers out well in advance - detailed outlines, with logically designed introductions and conclusions. This was a requirement, because once you got into actually typing, correcting a mistake could be expensive or impossible without starting over from scratch.<p>When we only had Wordstar available, and users came in with the inevitable questions and requests for help, you would still see well-organized papers written with a clear logical flow.<p>In 1985 with the advent of the Macintosh and MacWrite, all of that changed: People discovered that they could edit at will, copy and paste and move text around on the fly. And so they <i>did</i> - throwing planning out the window. And the quality of papers we saw at the help desk plummeted. Surveys from those years confirmed it too - paradoxically, the writing scores in the better-funded departments dropped rapidly, commensurate with their rate of introduction of Macs.<p>Planning ahead, making sure you know what you need to write, before you start writing any actual lines of code, prevents most problems from ever happening. It&#x27;s a pretty simple discipline, but one that&#x27;s lost on most people today.