Id Software Programming Principles
blog.felipe.rs
Id Software Programming Principles
1–10 of 83 posts
Re: Id Software Programming Principles
#2> 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.
This really stood out for me. I'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.
Re: Id Software Programming Principles
#3> 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. This really stood out for me. I'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.
Yeh totally..simple but so true
Re: Id Software Programming Principles
#4Some 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.
Re: Id Software Programming Principles
#5> Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters.
This one is also nice, especially for mid to large software houses. As long as a common denominator is respected, I guess.
Re: Id Software Programming Principles
#6> 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. This really stood out for me. I'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.
> "Write code that is easy to delete, not easy to extend."
Re: Id Software Programming Principles
#7> 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. This really stood out for me. I'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 completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somewhat, but I think this is a clear distinction between two kinds of programmers those who love the code; and the craft, and those who like making products. Have too many of one kind and you'll ship a mess. Too many of the other and you'll never ship)
Re: Id Software Programming Principles
#8> 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. This really stood out for me. I'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.
This is basically the Mythical Man Month in a few lines.
You once wrote something specific, and it was great. Then you had to write a second thing, and you remember things from the first, so why not make it more general for the inevitable 3rd, 4th, 5th to come? And, then, you fail to deliver the 2nd.
Re: Id Software Programming Principles
#9> 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. This really stood out for me. I'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 completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somew…
I've never thought of it this way. While I don't necessarily agree, I'm thankful for this insight.
Re: Id Software Programming Principles
#10It reads like a "get shit done" 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.)
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.