Writing code is a large and significant part of the programmer’s work. In a developer’s life, you will have to deal with different kinds of demands to write code. Each request will make you make difficult decisions. And this is normal. There’s nothing wrong with that. This is what everyone expects from you as a programmer – to write code. However, here is the question: Should you write all the systems you are expected to write?
We have conducted a study among all the programmers in 8allocate to understand what the most important skill a programmer can learn is?
This question leads us to the most critical skill a programmer can learn:
Knowing when not to code is perhaps the most vital skill a programmer can learn – the art of reading code.
We couldn’t help but agree with that. And why is that?
Programming is the art of problem-solving. So, naturally, programmers are problem solvers. As programmers, when they have a new problem ready to be solved or any other reason that requires us to write code, they get into courage.
But the excessive passion for writing code makes us blind. It makes us ignore some important facts that may lead to considerable problems we will have to deal with in the future.
So, what are these crucial facts that we tend to ignore?
Every line of code that you write this:
- the code that must be read and understood by other programmers.
- the code that needs to be checked and debugged
- the code that will increase the number of defects in your application
- the code that is likely to cause new errors in the future
As Richard Scrantt wrote:
The code is terrible. It’s rotting. It requires periodic maintenance. It’s got errors to find. New features mean the old system has to be adapted. The more code you have, the more places you can hide mistakes. The more time it takes to check or compile. The more time it takes for a new employee to understand your system. Also, more code often means less flexibility and less functionality. This is counter-intuitive, but in many cases, a simple, elegant solution is faster and more general than the clumsy code confusion created by a programmer with less talent. Engineers create the code. It takes more engineers to write more code. Do engineers have n? communication costs, and all this code that they add to the system while expanding its capabilities, also increases the whole basket of prices.
It’s true. The programmers who inspire you with their performance are those who know when to say “no” and when not to code. Software that is easy to maintain that lasts a long time, and that continues to help its users, does not contain extra lines of code.
The best code is not code at all, but the most efficient programmer is the one who knows when not to code.
How do you know when not to code?
It’s normal when you’re working on a project and thinking about all the cool features you’d like to implement. But programmers tend to overestimate the number of features their project needs. Many functions remain unfinished or unused or make the application too complicated. You should know what your project needs to avoid this error.
Understanding the purpose of your application and its basic definition is the first step to know when not to code.
Let me give you an example. Let’s say that you have an application that has only one purpose: email management. And for this purpose, sending and receiving emails are the two main functions of your project. You cannot expect this application to manage your to-do list as well, can you?
So you have to say “no” to any functions that are not related to your project. At this point, you can be sure that you know when not to write code.
Never extend the primary purpose of your application.
Once you know what is important to your project, you will be conscious the next time you evaluate possible code requests. You will know precisely what your requirements for writing code are. Which function should be implemented? What kind of code should you write? You will doubt everything because you know precisely how an unnecessary code can kill your project.
Knowing when it is not worth coding keeps your base with a small code.
When you launch a project, there are only two or three source files. It looks so simple. It only takes a few seconds to compile and start the code. You know where to find exactly what you are looking for.
Then, as the project grows, more and more source files will appear in your directory. Each code file contains hundreds of lines of code. To organize them all, you will soon need several directories. Remembering which functions call other functions is more complicated, and bug tracking requires a bit more work. Managing your project is getting harder and you will need more programmers to help you. The overheads increase as the number of programmers increases. You become slower and slower.
Eventually, the project becomes enormous. Adding new features is painful. Even making small changes takes several hours. Fixing existing errors always leads to further mistakes. You start to skip deadlines.
Now, life for you is a struggle. Why is that?
Because you didn’t know when to code, you said “YES” to every function you wanted to implement. You were blind. Programming something new made you ignore the essential facts.
It’s like a horror movie.
That’s what happens if you keep saying “YES” to everything. Know exactly when not to code. Exclude all unnecessary code from your project. It will make your life easier and make your application more durable.
One of my most productive days was removing 1000 lines of code. – Ken Thompson.
I know that understanding when it’s not worth coding is complicated, even for senior programmers.
I know that many of you have just started your way in programming, and you want to write code. You are so excited about it. It’s a good thing. Never lose this excitement, but never ignore essential facts. You will make mistakes, but you will learn from them.
Keep coding, but know when to say no to programming as our programmers do!