Id Software Programming Principles

&gt; Write your code for this game only - not for a future game. You’re going to be writing new code later because you’ll be smarter.<p>This really stood out for me. I&#x27;m always tempted, while writing something specific, to generalize it. I try to resist that, when I recognize it. Writing a ThingThatImWritingFramework risks ThingThatImWriting never seeing the light of day, or never being used.

It reads like a &quot;get shit done&quot; manifesto, and good rules of thumb for most programmers tasked with doing just that. Worth remembering that iD had some of the most advanced 3D and networking code for years and really pushed the envelope and the industry forward in many ways (first huge shareware company, first big company to allow mods, first big company to make code open source, etc.)<p>It is easy to slide into an OCD mindset when programming, to make things tidy and proper. It feels dirty to make stuff just work, to make stuff disposable, but evolution operates a lot like this - many little, reversible mistakes that add up to big improvements quicker than any other method.

&gt; Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters.<p>This one is also nice, especially for mid to large software houses. As long as a common denominator is respected, I guess.

Some of these things, like focusing on the task at hand and trying to be as simple as possible, not thinking too much about the potential futures is important to me. If all would do that maybe there would not be 1000s of weird half baked npms and such.

He described how literally hundreds of projects were successfully completed in C, targeting multiple platforms, while being first to market with innovative technology, with a small team in a pre-Internet world,<p>These are achievements beyond belief.

I&#x27;d very curious to hear Carmack&#x27;s take on this. After all Romero was making game levels, not the engines.

This is first class post-hoc bullshit. They weren&#x27;t making prototypes or reusing code, they sure as hell weren&#x27;t composing high-sounding principles.<p>They just got on with it because they were talented experienced and motivated. For that reason, the rest of the talk is very inspiring - so listen to the hour-long video (half talk, half questions), and not the article which only has the post-hoc bits. <a href="https:&#x2F;&#x2F;youtu.be&#x2F;E2MIpi8pIvY" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;E2MIpi8pIvY</a>

&gt; &quot;No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.&quot;<p>I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.