Idris Azeez
What I know about the computer programming life, from my own experience and that of good creators of code I know, is that this is a profession that forces us to learn how to do things better all the time. Sometimes that means re-learning a type of logic we worked on in the past, while at other times it means we have to learn a new language. Ultimately, this leads to the most important thing I think we do: maintain and review code.
No, code maintenance is often not sexy and it’s not always the most innovative thing we can work on. But it’s a critical part of the job.
Why We Update
To make sure all the things that start off being the best stay that way, they need to be constantly re-evaluated, re-analyzed, poked, and prodded. We need to see if they’re still actually useful and good after awhile, right? Think about it: When you buy a car and it works perfectly, you’re pretty happy and don’t think much about maintenance. But what if it develops faults? Do you wait for hubcaps to go flying before you begin maintaining it? The answer is an obvious “no.” Coding, I think, offers us a similar situation.
We maintain our code a little at a time, usually starting the first day. Maintaining a code base is all about finding better ways at doing what you do. And the business of software is all about writing code to solve a client’s problem, not always about solving the problem itself. So you need to evaluate that piece of code often.
We can ensure the code can be updated consistently by writing it in a way that is easy for others to access it. And usually the way to do that is by ensuring it is written using common conventions and communicating any changes. If you do this, not only will the next programmer thank you, but you will also be proud of yourself when you check back into the code weeks later and can still understand precisely what you wanted to achieve with it.
Recently, I had a software issue that made me think about the importance of code maintenance. I was looking through the timetable module code I wrote for a project and it took me a while to realize why I wrote some it. I had to refactor the code at the end of the day and spend too much time spent trying to understand it to refactor it. What if it was a new developer trying to understand the code I wrote? He would have given up and my reputation as a good coder would have suffered.
Team and Code Structure Are Both Important
Before going around changing your whole code base in the name of maintenance, you do have to make sure you have a test structure. This is a type of structure that ensures your code works as it is supposed to after making modifications. It also allows you to think about any minor issues that are a part of the codebase and might wreck the whole thing. Trust me on this: You do not want to make a small modification that makes your code misbehave.
But the creation of a testing structure can be an enjoyable task and it’s also a reminder that fundamentally, coders can’t dismiss even a small part of a code. It’s all important.
But unfortunately, there are lot of lazy programmers that don’t take as much pride in their code as they should. They tend to note down parts of a problematic code they can live with and then tell each other they’ll take a look at it when they have the time. But the truth is that there’s always something to do as a coder and you may not be able to get to that particular soft problem.
As a result, the best programmers at top organizations set aside a time to come together to evaluate their respective code base. It bolsters friendship and communication among team members and most importantly, leads to better code.
Don’t Break It! Or New Features Versus Old Keepsakes
I think one of the major problems in the software development industry today, especially when it comes to new employees, is that there is a weird expectation of it always being a job about developing new features. But the reality is that it often involves developing, rewriting, and reformatting earlier work.
People starting in the industry need to know the language you use to create the digital products we all use every day also changes and improves every day, often in ways we’re not privy to. Old features are deprecated and yes, new features are added a lot.
For those programmers thinking about redoing their work, I have this question: When was the last time you deprecated a feature in your code base and why have you not done so? If it hasn’t been done recently, you got to get on it.
Despite my imploring to tweak your code base constantly, it’s also key to note that the goal is not to go around breaking it in the name of maintaining it. It simply means that it needs to evolve in new ways to not only continue to do the things it’s supposed to do, but to also improve its efficiency. Remember, your code is only as good if it is efficient. When your code fails to achieve that goal, you know what happens to it: It’s scraped off.
As computer legend Brian Kernighan once said, debugging is twice as hard as writing the code in the first place. Would you prefer to do the harder job of debugging or simply writing the best piece of code you can write now?
It is really important that product owners and managers set aside time to review old code and proffer new ways of handling them. Remember, it is not what we do, it is how we do it that makes all the difference.
My Experience
It’s important for me to tell you where I’ve been to ensure you trust my advice and to also provide a valuable understanding of the possibilities available to new coders.
I’ve been programming for the past three years in my native city of Abuja, Nigeria. While not many people around the world know this city, I can tell you it has a good and growing IT industry. There are startup hubs and accelerators such as Startpreneurs and there’s a ton of investments in green technology.
I studied Computer Science at the Ahmadu Bello University in neighboring Zaria. While I was there, I wasn’t totally sure of the path I was going to take in IT because there were a lot of good options open to me. Initially, I worked as a Cisco Certified Network Associate while I went to school and later moved to programming when it appeared it could be a more lucrative option. But I have to confess — the thing that made me most want to get into computer science was not actually long-term thinking but instead it was my watching of the TV series 24. It was such an important aspect of the solutions found on the show that I knew the real version of it would be useful to someone.
While I learned a lot about being a developer at my University, I gained even more working.
My first job was as an intern at an IT firm, working on School Management Software, such as SAFSMS and SRMS, developing features for clients as requirements arise.
Currently, I am a backend developer programming in Java but also trying to test my hands on Python. I have not worked on a lot of Java Projects but at my current job, I’ve worked on almost all of our products built with Java for the backend and frontend. The world of front-end development is also great, as it easily allows me to see the visual result of what I have done.
Recently, I spoke at the GDG and the CMS Africa Conference and one day I hope to try my skills in the United States. I hope to see you there!
