Profile cover photo
Profile photo
Amir Hajizamani
Communities and Collections
View all

Post has shared content
Rigid programming philosophies are the devil.

Look, I am upfront about the fact that I am not an amazing programmer. I am not even a really competent one. I hack. I didn’t go through a CS degree, I don’t actually know a lot of the lingo, etc.

On the other hand, I have in fact been credited as a programmer on published games. I have programmed in quite a lot of languages, I prototype my own stuff regularly, and my name is on several technical patents. I seem to have a knack for seeing architectural solutions to problems, and for inventing technical solutions. (I generally prefer to partner with a genius coder for the actual implementation thereof — and have been lucky enough to work with many of them!).

So take everything I am about to say with the appropriate grain of salt.

I have seen too many projects get hosed by “the right way to do things”… like say planning your entire game in UML on three hallways worth of paper on the walls, only to find the resulting code too slow to actually use (this is a true story… and I apologize to the many friends and extremely smart folks who worked on the project I am talking about!). Or insisting on the absolute perfect approach to object-oriented or domain-driven design or whatever, when two lines would get you the same result with better performance, less obfuscation, and easier maintainability.

The right way to do things the first time is the way that gets it working the fastest so you can see if your solution even makes sense.

The right way to rewrite it once that works is to make it fault-tolerant and scalable.

The wrong thing to do is build a giant system first, and try to account for every possibility. Odds are very good that you need to write a screwdriver, not a power drill that can double as a belt sander. And really, in the long run, wouldn’t you rather have a tool chest with a solid screwdriver, a decent hammer, and a good pair of pliers — rather than a power drill/sander/screwdriver than can pound nails with its handle?

This doesn’t mean that you don’t plan ahead. Sure — your first pass should include as elegant a solution as you can think of for the actual problem at hand; it just shouldn’t include solutions for problems you invented for yourself. And it doesn’t mean that you might not end up with complex systems in the end. Sure — over time, you will encounter new problems, and it will turn out the hammer you already have can handle them with minor modifications — which can turn into cruft over time if you are not careful.

But why start further down that path than you need to? A is a cool idea and a useful pattern, not a solution to every problem.

FWIW, I feel the same way about religious adherence to project-management-philosophy-of-the-day stuff too. Basically, as soon as I hear “we’re doing this this way” followed by a few buzzwords, I can’t help but heave a giant mental sigh. So hmm, perhaps the right title for this post should have been “dogma is evil.” :)

Lastly, never trust a programmer who says that he only knows one language. The more in love with one language someone is, the more likely they seem to be to fall into the above trap… and if you are one of said programmers — try more languages. :) Each language I have learned has introduced me to a new programming concept that rewrote my mental model of programming in general. It’s OK to have favorites — I do! — but it’s always best to use the right tool for the job.

(FWIW, my favorite at any given moment is entirely based on “what lets me stage up a working prototype as fast as possible”).
Wait while more posts are being loaded