Why procrastination kills
I work as a software engineer. The company I work for produces software in various areas of a specific sector. I am part of a team that deals with ERP management software.
It’s all rubbish.
The database is rubbish, the development language is outdated, and the approach to the project is at the level of a middle school kid.
Why this?
Because the company has always procrastinated.
The world of software is dictated by continuous, rapid, even excessive evolution; technical debt accumulates every day if nothing is done to prevent it.
Sometimes in projects, the people who wrote the code are not all engineers or expert computer scientists, so they don’t have sufficient IT background. It’s up to those with more expertise to remedy the situation of the frustrated, burnt-out fifty-year-old who writes code like a fifteen-year-old.
I’ve seen things you people wouldn’t believe. [Blader runner’s iconic phrase]
The ability to write good code is not dictated by skill in the language itself, let alone by qualifications acquired, it’s all about the skills developed over time. Using logic to discern good practices from bad ones is essential for writing clean, structured and efficient code.
Some people are afraid that robots will steal their jobs, but don’t worry, there will always be that colleague who ruins your day by introducing terrible code into the project codebase, and if you think you don’t have colleagues like that, well, I have bad news for you.
How to
It is not strictly necessary to build complex data structures or use trendy technology (LLM, I’m looking at you), but to stop and think, “Is it a good idea to write this query, leaving it open to SQL injection attacks?”, “Why use an object-oriented language if I don’t know how to define a class?”, “Does leaving the default password in the database make my software, on which the profits of million-dollar companies are based, less secure?”, “Is it right for this password to remain hardcoded in the source?”.
These last few sentences are entirely based on real-life experience in the workplace. My colleagues have always worked poorly, and mistakes have accumulated over the years, turning into decades.
Not only was there no desire to resolve the issue, there was not even any desire to learn how to resolve it.
Why me? I didn’t study to do better than this. And we have always done it this way in our company.
Improving yourself means never stopping studying. Books, magazines, and YouTube videos keep your mind constantly active. You may not apply that particular vector-based algorithm, but you know it exists, and it may inspire you to create an algorithm that is useful for your needs. Hiding behind pitiful, self-absolving answers will not improve you or the company you work for at night (dear colleague, if you are reading this, you probably aren’t because you don’t know English; I saw the file changes in the middle of the night).
Just because software works does not mean it is reliable, or even well built, which is why it is necessary to write clean code from the outset.
Errors accumulate, you won’t have time to fix them, it’s up to you, you can’t delegate.