My proudest dev moment

I recently submitted a job application that required me to delve into my proudest moment as a developer, and I've decided to share that experience here as well, for future reference.

At the time, my role as a developer caught the attention of our CTO due to my clear and structured coding approach. You see, the existing codebase was characterized by thin controllers and unwieldy Utility classes with massive functions. Given the opportunity, I would propose refined solutions for various new modules, eventually catching the CTO's eye. This led to a pivotal moment when the CTO tasked me with creating a new whole architecture that was both effective and easily understandable for junior developers, as our startup lacked senior resources, then refactor the codebase. The challenge included refactoring the existing codebase with assistance from two junior backend developers.

While the details are somewhat fuzzy now, I recall devising a 5-layer / hexagonal-ish architecture, introducing separate layers for view, controllers, 'Actions & Events', repositories and model. Up until that point, our code had been making hundreds or even up to 2000 (TWO THOUSAND) database connections in a single webpage load, causing significant delays. Recognizing the impact on our business model, which relied on Google-friendly loading times, I optimized the system to only make two connections per load.

To address potential errors, I implemented a dual-channel approach involving SQL transactions and rollback commands. One channel would connect to the database on the Actions & Events layer, when either an Action or Event started, start a transaction, then finish it when the Action or Event was done. A second channel would connect separately and throw in a rollback command if anything went wrong, including an error in the first channel. Although this approach might be unconventional, it proved effective in significantly reducing loading times below the Google-friendly threshold, although we never got to see the security advantage as I’ll explain later.?

Additionally, our fetching to the database was unsafe, as a basic dev error could make the database return whatever entity occupied the first row of a table, which was usually reserved for entities only root should be interacting with. I created repositories that would fetch both _ByID and flexible fields (as long as they were not ID), which would be both usable and safe, since it would never return the first row in case of a coding error.

I delegated the extension of the 3rd party SQL library we were using to a junior dev, defining the technical specs, so that it would play nicely with the new repositories and the new transformer, which follows suit.

One notable achievement during this period was creating an entity transformer that converted SQL query results into entities or entity collections, since up until that point we barely used OOP to any capacity even if we were using a modern PHP version. This involved my first experience with self-recursion: a complex function that successfully navigated the interconnected relationships between entities. Despite the complexity of our marketplace, which displayed different entity versions based on user interactions, the transformer efficiently scanned, instantiated, validated, and returned entities and entity collections. Per every entity or collection, it would call itself recursively. I still remember the magical moment that it was to set it on and have it recurse correctly on the first go - I had been anxious it would fail spectacularly.

Previously at my time at the company, the CTO asked me to implement an error reporting system that not only stored errors in the database but also forwarded critical ones to the CTO's email. This system proved surprisingly straightforward to implement, and was promptly added to the new architecture.

The resulting architecture and enhancements were tested in a new module, showing promising results: the transformer, repositories, and error reporting worked fine. The SQL worked for a version 1 but needed a second iteration and most disappointingly, the twin-channel, transaction-based DB handling proved to be a partial success, since the SQL database failed to acknowledge transactions, even though it’d still worked and saved us precious seconds of loading.?

In the end, the unforeseen challenges of a shifting market and the subsequent pandemic led to quick layoffs and the eventual closure of the company. Unfortunately, my architecture redesign, transformer, and other design artifacts were never exported, but the SQL library extension lives on in my colleague's GitHub repository. Last time I checked, he still updated it.

Reflecting on those days, I now find comfort in more established and complex architectures like hexagonal architecture or Go’s proposal for architecture. While I acknowledge that my early endeavors might have reinvented the wheel in certain aspects, there's a sense of pride in the ingenuity and surprises I discovered along the way. Despite the loss to time, I'm grateful for the opportunity to face such a formidable challenge. Who knows, perhaps a similar task awaits me in the future.

note: this text has been grammatically polished by ChatGPT, and so it reads more boring than my usual texts.