Not until recently did I ask myself a question: Am I not a team player?
In my sophomore year at university, we were in a class where we grouped ourselves and were given a task. The task was to take turns drawing an animal on the board. Basically, each person had to continue the lines drawn by the previous person until everyone had taken their turn and completed the drawing. I was the last one in my group and I ended up erasing some of the drawings by my groupmates because they made the figure look awkward. In the end, the teacher preferred the other group’s drawing and made a comment about ours that was clearly directed at me personally. She said, “You should trust and believe in each other.” It haunted me for quite a while. It even comes back from time to time.
During the early part of my career, I always felt the pressure to know all the new tech and fancy frameworks. And I did fall into that trap. After jumping from one framework to another, I realized one thing: I wrote the same code. The same poor-quality code. New frameworks didn’t really improve my work. They were just another cover for the septic tank containing the smelly, ugly, and unmaintainable pieces of work I’d done.
From then on, I went on a mission. I needed to understand the fundamentals of programming: the principles, design patterns, clean code, and tests—all the things required to create maintainable, robust, and easy-to-change software. That mission was never easy. It took me years of making a ton of mistakes, late nights firefighting a burning production, and enduring borderline insults just to understand the wisdom of a craftsman or craftswoman.
I’m not saying that I’m one of the best programmers out there because I’m certain that I’ve only seen the tip of the iceberg. However, I would say that I’ve made an enormous amount of mistakes and, with the help of all the bright people I’ve worked with, I was able to correct them. And now, I’ve gained the wisdom to avoid certain paths before even going down them because I’ve been there before.
Fast forward to the present time, I am now standing again in a familiar situation. Somewhere inside my head is a constant battle between enforcing my knowledge on a particular coding practice because “I’ve been there, done that” or letting it slide and waiting for it to blow up so I can tell everyone “I told you so.” This may sound like I’m a douchebag, but to give you some perspective, I’ll cite an example.
We were working on a new feature, which was basically just CRUD operations in a nutshell. Part of this was implementing a homepage template customization. If no custom page is defined, the system should return a default one. Now, I wasn’t part of the team doing the planning because I was working on other issues. But needless to say, I was aware of the whole feature.
To my surprise, they came up with a really complicated solution for a very simple problem. The problem was how to store the default page. For me, the easiest way was to just create dedicated default entities with default configuration. That’s it! But their solution? Put them in YAML files, load and cache them due to the anticipation of potentially facing a million requests based on the number of users on the platform. I have experience with caching, and that famous line about naming things and cache invalidation being the two hardest problems in computer science is very true. And these guys had no idea about it.
I confronted them about it and told them all the problems with their proposed solution. They ignored my warnings and proceeded with it. I tried to convince them one more time, but I backed out after one of the guys, who led the planning and self-proclaimed having decades of experience, started to name-drop that he used to work with caching on Yii framework and it was beautiful. I learned from the past that when someone is talking nonsense, it’s better to back out than have a confrontation.
One sprint later, the caching solution had been implemented. So did the issues that came with it. The first issue was testing. The guy who implemented it was a junior who got stuck for some time because he tried to include actual Redis integration in his unit test. I tried to introduce him to mocks and stubs, but to no avail. The second issue was cache invalidation. I asked them how to invalidate the cache if something changed in the data. Their answer? Well, it has a 24-hour TTL, so we can just wait for it. :insert-exploding-head-emoji: Another solution was to use the existing system cache invalidation, but it would wipe out all cached data in the system, and you don’t want that.
I stood my ground on this subject because I didn’t want to debug an issue down the line when it could have been prevented in the first place. So, after wasting two weeks on development, we refactored it to use the simplest solution.
This is one of the things that I had to keep tabs on because it’s very clear that these guys don’t know what they are doing. I keep hearing from upper management that we always strive for quality and that the system is very complex. They always say that the system is heavily tested, but I completely disagree. These guys don’t even know how a simple data provider in a unit test works.
I know this is more of a rant than an opinion, and I do feel guilty about it. It’s not fair to them because they’re probably just doing honest work. I’m aware that there are ways to get around it and let them hear what I’m trying to say. But that’s exactly my problem. My bucket of patience is still not deep enough to tolerate it, and I am aware of it. Patience is indeed a virtue, and mine is still a work in progress. That’s why I’m struggling to keep it cool.
Leave a Reply