For Sure I'm Too Stupid #

Recently EA has open sourced the codebase of the game saga Command & Conquer. Looking through it made me raise my eyebrows a few times.

First of all, it is insanely pragmatic and easy to read. For the time I looked around I could not find any "what ifs" implementations. No useless abstraction, no strategy mechanism if its purpose was not clear in the moment, no useless factories just to have them. The matchmaking class should be studied as the way to implement software for your clearly defined problem. Those who wrote the code clearly understood encapsulation and execute properly on that. The whole thing made sense then and makes sense now.

Second, you can see the passage of time and the adoption of new conventions to write code by looking at the comments. Some are more verbose, others more succinct and some even contain the word confidential even tho it no longer has any meaning. A few are funny, like this one // if still present in 2003, please nuke.. Curse words were used sparingly to clearly communicate the importance of following code block.

Third, from the code structure and file structure you can see a clear evolution of the tooling and the coding conventions over time, from year to year, from project to project. An adaptive process to meet the requirements of each new game in the saga with a clear goal of delivering a product not increasing someone's ego. It shows how on each iteration they knew what they were building and kept the scope in check. The CoC Red Alert is rough, the code is rough, the structure is rough. The next one CoC Renegade seems to start with a structure that did not support the final product but they kept at it and didn't push for an unnecessary full re-write just to make it pretty at the expense of getting no real benefit out of it. Then it comes the time for CoC Generals & Zero Hour which is clear they had at least one expansion planned right from the beginning and the project structure goes to show it.

Looking at this relic of the past it shows the modern software developer all the wrong paths taken from then to nowadays. We start our projects with overblown frameworks and then try to be cautious about a few for loops here and there. We fail to make the distinction between how to implement details and how to write the foundation, therefore, more often than not, create unnecessary abstractions just to solve one use case. The modern codebase no longer represents the current version of the product but a speculative end version of it like we won't be learning anything along the way and there won't be any possibility to make adjustments.

This is not only the software developer's fault but the hiring culture also. During the hiring process, the software developer is grilled on how much knowledge they have about writing code, to leetcode this and leetcode that, to solve imaginary problems with the intent to peek into the thinking process of the person being hired. What is really baffling about this is that no one seems to realized that such a process is easier to game than actually writing good code to solve the problems at hand. Nowadays, if you were to show the code of CoC game as a portfolio project you would get laughed out of the office during the hiring process.

We all could use this moment as a wake up call to stop thinking we are less good as software developers for not throwing the entire tree of knowledge about software development at every problem we encounter.