Knights of The Code Table

08 Feb 2024
Knights of the round table in terms of Software Engineering characteristics

We All Follow an Ethos

We all follow an Ethos. In every walk of life, every profession, and every pursuit, there lies an underlying ethos — a set of standards and principles that guide our actions and define our craftsmanship. Intriguingly, these ethos are not rigid laws of the physical universe, bound by the immutable forces of nature. Instead, they are intangible yet powerful constructs, born out of collective wisdom, ethical considerations, and societal expectations. It is not a mere rulebook - It is the encapsulation of our moral compass, a guiding path of excellence and integrity in whatever respective fields we choose to embark on, to adhere to our utmost abilities the moment we start crafting the nature of our work. Take, for instance, the medical profession. A doctor adheres to an ethos encapsulated in the Hippocratic Oath, a timeless pledge that emphasizes the importance of ethics in medicine. Or say, in the age-old tales of knights and chivalry, the essence of a true knight was not only defined by prowess in battle but also by their unwavering commitment to a code of honor and duty.

This universal concept of an ethos, transcending professions and eras, is equally pertinent in the field of software engineering, where programmers, much like knights of yore or our admirable doctors, we too, are bounded by a code — the code of coding standards.

These standards, akin to any professional standards, are not just guidelines but a creed for programmers to emphasize readability, maintainability, and functionality in the codebase. Yet, I propose that the true mastery of programming, much like a knight’s journey to knighthood, lies not just in adhering to these standards but in creating and imparting them. That is, designing and enforcing our very own standards of writing code! Such is born out of collective wisdom that is naturally provoked by working within the tech industry.

I believe coding standards do teach you the certain nuances of a programming language. But I believe, more so, that creating the coding standards is more effective for learning and understanding a programming language. My key reason is that this particular activity requires a deep understanding of the various bad practices that can occur in programming, along with the development of strategies to mitigate such behaviors. By designing your conventions and imparting these standards to your team, you engage in a comprehensive learning experience. I also believe, within the bounds of learning sciences, that is, learning how to learn, such activity aligns with Bloom’s Taxonomy - an education framework that categorizes one’s pursuit in mastery of a subject. When you engage in the synthesis of a coding standard, you are not just following rules; you are critically analyzing the language, exploring its limitations, and innovating ways to enhance its use cases.

However, in terms of merely following the coding standards, I suppose the programmer will differentiate between good and bad code, which in itself, is a learning activity of understanding the expected programming language lingo. Since there are infinite ways of implementing such a feature, we tend to choose the best path to that feature. The only way to recognize such a path is to understand the programming language at the inner level, balancing optimization and readability of the code we write, set by some sort of social construct, in this case, the programmers construct!

The journey of a software engineer is not merely about technical acumen; it is a deep adherence to an ethos of creating, maintaining, and evolving within our pursuit of our own craftmanship - designing an optimal codebase, a direct provocation to a coder’s commitment to excellence. An ethos we follow.

The Quest for the Holy Code

When I started programming, I started envisioning this personal project that I always wanted to create - a game engine. I was inspired to create an engine that aligned within the game design domain. That way, we can create technical efficient games while adhering to game design conventions. Optimizing a video game for 60FPS as a benchmark is great, but making a game fun for the players is beyond mere programming and technical expertise. How could the idea of implemenenting a binary space partitioning (BSP) tree algorithm for making the exploration of 3D spaces fun for the players? At first glance, they don’t. One is purely technical, and the other has no correlation of making a fun game. In terms of game design lingo, BSP trees actually unlocks Environmental Storytelling and Dynamic World Building. So, if a game requires such features to exist, then my game engine will generate BSP trees for the sake of giving the developer the feature of Environmental Storytelling and Dynamic World Building in their games. Simultaneously, it embeds game design principles directly into its architecture, offering tools and frameworks that help developers create engaging gameplay, compelling narratives, and immersive worlds. Thus, I embarked such engineering odyssey solo.

Yet, I decided to not include ESLint in the beginning phase! Alas, after writing around fifteen thousand lines of code, I began to realize the inconsistencies of my game engine codebase. For example, I found that variable naming conventions were not consistent throughout the code, leading to confusion and making it difficult to understand the code’s purpose at a glance. In some places, I used camelCase, while in others, underscores separated words. Another issue was the inconsistent use of spacing and indentation, which affected the readability of the code. Some blocks of code were indented differently than others, creating a visual clutter that made it hard to follow the logical flow of the program! As I begin to enforce a coding standards later on in my project, I realize that I had a huge refactoring process I must atone too. Refactoring fifteen thousand lines of code.

So how does one enforce such ethos? This is where tools like ESLint come into play, especially for beginners embarking on their coding journey. ESLint is a powerful static code analysis tool used in programming, particularly in JavaScript environments. Its primary function is to identify and report on patterns found in ECMAScript/JavaScript code, making the code more consistent and avoiding bugs. I like to think of ESLint as some form of low-level artificial intelligence. It doesn’t possess the complex decision-making capabilities of advanced AI systems, but it does intelligently scan and analyze code, acting as both a tool and a guiding mentor. It enforces a coding ethos that prioritizes readability, maintainability, and functionality by automatically detecting deviations from established coding standards and suggesting corrections.

Through my experiences, ESLint has always been a pain to integrate for the first time in any coding project. I’ve come to understand that this initial phase of integrating tools like ESLint is not just a procedural step but a fundamental part of creating high-quality software. How often do we, blinded by excitement and ambition, leap prematurely into our projects, only to be reminded that a strong and considered start is not just a step, but the very foundation upon which all great works are built? Let the tragic story of my pursuit of the game engine serve as a cautionary tale.

The importance of this phase becomes even more pronounced when considering the scale of software deployment and usage. Code developed in modern software projects is not just read and maintained by a handful of people; it is often scrutinized by thousands of developers and reaches millions of users worldwide. In this context, the role of a tool like ESLint transcends beyond mere error checking. It becomes a crucial instrument in ensuring that the code is not only functionally sound but also adheres to a set of standards that guarantee readability and maintainability as the codebase grows into more than a million lines of code.

Such ethos is important in software engineering, where the lifecycle of a product often spans several years, and the codebase undergoes continuous evolution and scaling. Consistent coding standards ensure that as new features are added and old ones are modified, the code remains coherent and accessible to new and existing developers alike.

At its very core, the process of integrating tools like ESLint and upholding coding standards in software development reflects a universal truth: in every discipline, there is an ethos that guides and shapes our actions. Just as knights of the ancient era followed a chivalric code that dictated their conduct and defined their legacy, we, software engineers, adhere to a set of principles that ensure the creation of quality, sustainable code. This ethos, though varying in form and application across different fields, is a constant reminder of our commitment to excellence. In software engineering, this commitment translates into practices that not only enhance the immediate functionality of the code but also ensure its enduring relevance and utility. Thus, whether in the age of chivalry or age of computers, the ethos we follow is a testament to our values and a blueprint for the legacy we aim to build. To adhere to sets of principles while coding, we not only fulfill our immediate responsibilities but also contribute to a larger narrative of craftsmanship and responsible stewardship, continuing the enduring relevance of the ethos in all human endeavors.