What most developers fail or refuse to see
From the first day I started working in the software engineering field, I have seen a pattern that keeps repeating in the attitude of most developers I interact with. The most common issue I see is that the vast majority of the developers care about only one thing: the code.
They refuse to see the bigger picture: the utility of the code and what it actually represents. For them, the code is like art, it needs to be perfect there is absolutely no way any imperfection to slip into production. Absolute zero code duplication and the most descriptive variable names that makes a script look like a poem.
We have found ourselves in the situation where the boss or the client asked us to add a feature. Then we add it. Then we find out it needs some major changes. We silently sigh and do the changes. Then a last minute change comes that states that the feature must be totally replaced with another feature. We lose our minds as we fail to understand what’s with these chaotic requests.
We fail to understand (in fact we don’t even wonder why is this happening and blame it all on the management that does not understand that code is life and we need time to make it beautiful so that we can later stare at it and tell ourselves “what a beautiful nice piece of code. I am so proud of what I accomplished). We refuse to accept that there is a reason for this or we think that it’s not our job to think about it. Higher management needs to think about the business part, us, the developers need to look after the code and implement whatever requirement appears in the planning meeting or in the email from our manager.
What we, as developers often fail (or refuse) to see is that we don’t actually deliver code, we deliver value. Because value is that one thing that keeps bringing money and pays our paycheck. And those chaotic requests, in fact, represents how the product we are selling (or the client is selling) evolves and adapts to the market demand in order to have the upper hand over the competition. The client doesn’t care at all if the code respects some code styling standard or if we compare those arrays in polynomial or logarithmic time. They don’t care if we have an army of computers that run microservices using the latest state of the art inter process communication protocol developed by Google or we have a single machine running a bloated monolithic application that speaks XML. All that matters is if it gets the job done in a way so that the clients that pay for it can sit down and relax while our software takes care of their problems.
I was walking that path a while ago. All I cared about was how beautiful my code looks. I cared about that little optimization that made my code run faster with half of a microsecond but in fact I was failing at understanding the bigger picture and put myself in the customer’s shoes.
But not anymore. The more I read about software companies, the more I realize that writing the code is the easy part. In fact, I discovered that a lot of software companies, when they started, they didn’t have any code at all running. They were testing the ground doing some sort of manual labor, until their hypothesis is confirmed and they needed to scale.
So, to sum it up, us, as developers, should ditch the code worshiping and start thinking more about the purpose of what we deliver. It’s the only way to understand the bigger picture and align ourselves with the company’s vision.