As a programmer, composing code is the core part of your job. In your programming lifetime, you should manage various types of code demands. Each request will force you to make difficult decisions. That all is OKAY. Nothing wrong with that. This is what everyone expects from you, as a programmer. However, here is a question:
Should you write all the code that is requested from you?
Programming is the art of solving any problem. As programmers, when we have a new problem, we get excited.
And that is OKAY because we are programmers. We love writing code initially. However, getting too excited about writing code makes us blind. It causes us to ignore some important facts that can cause bigger problems we will have to deal with in the future.
So, what are those important facts that we tend to ignore?
As Rich Skrenta wrote,
CODE IS OUR ENEMY
“Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean the old code has to be adapted.”
It’s so valid, would it say it isn’t? The programmers who motivate you with their efficiency and coding mindset are the individuals who realize when to state no and when not to code. The software that is easy to maintain, that lasts long and keeps helping their client is the one that doesn’t contain any unnecessary code lines.
How can you know when not to code?
It’s normal to get excited when you’re dealing with a project and think about all the cool features you’d love to implement. But programmers tend to overestimate how many features their project needs. Many features go unfinished or unused makes the application complicated. You should know what is essential for your project to avoid making this mistake.
“Understanding the purpose of your software and Never expand your software’s purpose.”
A programmer should have a clear picture of the purpose of the software. You should be conscious whenever you evaluate code requests. You will exactly know your requirements to write code. Which feature should be implemented? Which code is worth writing? You will question everything because unnecessary code can kill your project.
“Keep small codebase.”
There are only two or three source files when you start your project. All looks so simple. It takes just a few seconds to compile and run the code. You know where to find exactly what you’re looking for.
As the project grows, source files fill your directory. Each code file contains hundreds of code lines. To sort out them all, you will require numerous catalogs. Managing your project becomes difficult, and you need more resources to help.
Last, the project becomes huge and complicated. Adding new features is painful. Even making tiny changes takes a long. Fixing pending bugs always introduces new bugs. You start missing deadlines of the project.
“One of my most productive days was throwing away 1000 lines of code.” – Ken Thompson
Knowing when not to code is so difficult. Even for senior programmers. Never ignore the important facts. You will make mistakes, and you will learn from them as well. But at least you can be more conscious if you can learn from your experience.