.webp)
Let’s bring critical thinking back to programming!
Now there are frontend, backend, and fullstack developers, test automators, infrastructure developers, data engineers, integrators, and hundreds of other roles.
This isn’t bad—on the contrary, it has enormous benefits from the perspective of problem resolution, market needs, productivity, project management, and the resources required. However, amid so many roles, methodologies, frameworks, and programming languages, we are drowning in a world full of practices which, though beautiful and promising in theory, are taking our critical thinking, creativity, and ability to contribute to solutions out of the equation. We are increasingly limited to merely “programming” what businesses want, “however you can get it done,” as long as it works, and also it should be secure, cost-efficient, fast, and turned in on time.
Probably this idea of “however you can get it done as long as it works,” sounds familiar to many, and perhaps it sounds a lot like your average workday. For many of us, this represents a constant conflict, in which user expectations are not always compatible with the reality of what can be completed in the time allotted by the project directors, turning everything into a battle against time. In addition to being less than enjoyable, this leaves little (or no) time to devote to other key aspects of the process of constructing software, such as stability, alignment with functional processes, company strategies, support during daily operation, and the end user.
Recently, the lack of emphasis on these aspects has brought consequences that many of us know and have seen in our own work, from unstable applications or recurrent failures to serious errors due to unforeseen circumstances that can lead us to improvised solutions that put much more than metrics or software features at risk.
When we consider software errors, we see that today not many professionals are aware of what could happen if something fails, because the focus is on coding and completing, and we often don’t look beyond those completion and quality metrics, beyond the code, beyond the services, or even further, to the people who use the software, the end users. We must be conscious that if something fails in the software we build, someone will be affected.
This can take the form of situations from not being able to complete a task at work, not being able to make on online payment or with a card at a restaurant or hospital, to generating calculation errors for a debit, leaving someone without money who then needs it in an emergency. It might sound dramatic, but that’s the reality. And we don’t always have a sense of the impact this can have, whether because we don’t realize, because our users don’t report back on the projects, or because we don’t even think about it because we think the most important thing is delivering “on time” or that the code “works” and that’s it.
The goal of raising these ideas is to invite us to be more sensitive as professionals, to use our critical faculties without fear or embarrassment, to ask questions that go beyond what they ask us to code, to see the impact of what we do, to think that, to develop good software, it’s not enough to simply program and adhere to the project timeline. I think we should also think like possible users or clients of what we’re building, always consider that something could go wrong and prepare for it, thinking ahead to solve it.
We should involve ourselves fully in what we are building to understand the why and who we are doing this for. Then, in the end, our job doesn’t merely consist of writing code that works well according to the requirements (because the user isn’t always right) and creating documentation that supports it, it isn’t about the hundreds of metrics and “lab” tests that don’t reflect reality, it isn’t about knowing a lot about technology, frameworks, or programming languages. It’s about being sensitive, about understanding the context and the needs that we will meet with our technology, embracing software development in all its dimensions, from the theoretical, the corporate, and the commercial, to what can happen to everyday people who use this technology or are benefited or affected by it.
That’s why I think software development shouldn’t just be about technology and writing code well. What do you think?
We should involve ourselves fully in what we are building to understand the why and who we are doing this for.
Then, in the end, our job doesn’t merely consist of writing code that works well according to the requirements (because the user isn’t always right) and creating documentation that supports it, it isn’t about the hundreds of metrics and “lab” tests that don’t reflect reality, it isn’t about knowing a lot about technology, frameworks, or programming languages. It’s about being sensitive, about understanding the context and the needs that we will meet with our technology, embracing software development in all its dimensions, from the theoretical, the corporate, and the commercial, to what can happen to everyday people who use this technology or are benefited or affected by it.
That’s why I think software development shouldn’t just be about technology and writing code well. What do you think?
