No, no, no, no, and no. And no.
A big NO. Clear as that.
All you have to do is to bring those two letters together and say the word.
Now, let’s say it together. NOOOOOOO!
Good start.
But wait a minute. Say NO to what and when?
Well, this is the important point where most of the programmers (even seniors) get easily confused.
As a programmer, writing code is the biggest part of your job. In your programming lifetime, you will have to deal with different kinds of code requests. 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: Writing code. However, here is a question: Should you write all the code that is requested from you?
This question brings us to the most important skill a programmer can learn:
Knowing when not to code is possibly the most important skill a programmer can learn. — The Art Of Readable Code
I couldn’t agree more. Why is that?
Programming is the art of solving a problem. So naturally, programmers are problem solvers. As programmers, when we have a new problem in front of us ready to be solved or any other reason that needs from us to write code lines, we get excited.
And that is okay because we are programmers. We love writing code.
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?
Every line of code you write is:
- code that has to be read and understood by other programmers
- code that has to be tested and debugged
- code that will increase defects in your software
- code that probably will introduce new bugs in the future
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.
The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.
Furthermore, more code often means less flexibility and functionality. This is counter-intuitive, but a lot of times a simple, elegant solution is faster and more general than the plodding mess of code produced by a programmer of lesser talent.
Code is produced by engineers. To make more code requires more engineers. Engineers have n² communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.
It’s so true, isn’t it? The programmers who inspire you with their productivity and coding mentality are those who know when to say no and when not to code. The software that is easy to maintain, that lasts long and keeps helping their users is the one that doesn’t contain any unnecessary code lines.
The best code is no code at all, and the most effective programmer is the one who knows when not to code.
How can you know when not to code?
It’s natural to get excited when you’re working on 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 or simply make the application overcomplicated. You should know what is essential for your project to avoid making this mistake.
Understanding the purpose of your software and its core definition is the first step to know when not to code.
Let me give you an example. Let’s say you have software that has only one purpose: managing emails. And for that purpose, sending and receiving emails are two essential features to your project. You can’t expect that software to manage your to-do list as well, can you?
So you should say NO to any possible feature requests that are irrelevant to this definition. This is the moment you can be exactly sure that you know when not to write code.
Never expand your software’s purpose.
Once you know what is essential for your project, you will be conscious next time when you evaluate possible code requests. You will exactly know your requirements to write code. Which feature should be implemented? Which code is worth to write? You will question everything because you will know exactly how unnecessary code can kill your project.
Knowing when not to code keeps your codebase small.
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.
Then, as the project grows, more and more source files fill your directory. Each code file contains hundreds of code lines. To organize them all, you will need multiple directories soon. Remembering which functions call other functions is more difficult, and tracking bugs requires a bit more work. Managing your project becomes difficult, and you need more programmers to help. Communication overheads increase as the number of programmers increases. You get slower and slower.
In the end, the project becomes huge. Adding new features is painful. Even making small changes takes hours. Fixing present bugs always introduces new bugs. You start missing deadlines.
Now, life is a struggle for you. Why?
Because you didn’t know when not to code, you said YES to every possible feature request. You were blind. Coding something new caused you to ignore essential facts.
It’s like a horror movie, right?
This is what will happen if you keep saying YES to everything. Know exactly when not to code. Eliminate all unnecessary code from your project. This will make your life easier and make your software last longer.
One of my most productive days was throwing away 1000 lines of code. — Ken Thompson
I know that knowing when not to code is so hard. Even for senior programmers. Perhaps what I wrote in this article is hard to understand for junior programmers, and that is okay and understandable.
I know you have just started your programming journey and you want to write code. You are so excited about that. This is good. Never lose this excitement but also never ignore the important facts. We learned them by making our own mistakes. You will make mistakes as well, and you will learn from them as well. But at least you can be more conscious if you can learn from our experience.
Keep coding but know when to say no to coding.
Top comments (17)
The key is, indeed, to know when to say no. That doesn't mean "always say no". It means to be judicious. You wrote this article as though your only options are scope explosion or iron-fisted scope control, but that's just not the case. If you know exactly and explicitly what you need to make, you can stick to this advice. But, in practice, even if yout think you know, you don't. You always have to make changes and update what you thought you knew.
You are right. But if we are aware of what we are doing and the costs of our choices, we will get better. My aim with this article was to increase awareness of developers.
Fair enough! My only concern is that a junior developer will read this and take from it the bad idea of refusing all scope increases. I agree that scope creep is a bad thing in general, but there are times when it makes perfect sense.
For example, let's continue on the example of the email client. Sure, it can send and receive emails, and that's the barebones requirements. But now, every email you get is all in the same list, whether they're racist forwards from your "I'm not racist, but..." uncle or from that big new client you just netted. So clearly, some sort of filtering is useful. Even though that's an increase in scope, it's still worth it to add, because that's a vital feature.
That's what I meant by "that's just not the case" -- sure, you might think you know exactly what you're making, but even the most detailed specs can't account for everything.
Then again....if you're getting paid by the hour.... :)
Hehe!
Sounds cool in the beginning but can be a bullet in your own feet when the project gets bigger. You will get more and more expensive with less capability in the eye's of the management.
More often than not writing less code require more time, because writing good, bug-free feature takes thought, refactoring, writing tests.
Spoken like a true consultant. lol
This is great. Even for things you say yes to, it's worth the time to do non-coding activities to keep your project clean and easy to change:
Meh. This is good advice for engineering useless products. There are a million products out there that send and receive emails. Write the code that improves the user's experience with your email app and distinguishes it from the others. Write expressive, self documenting code and supplement it with actual documentation that explains the context of the code. Saying yes is important, too, obviously.
This is just an example. I think you already got the point:)
I could not agree more with what you've said Hüseyin, it's cool to accept challenges from time to time because by doing that we can expand our comfort zone, but also is important to acknoledge our own skill limitations so we don't fall in the mistake of compromising with a client that we cannot satisfy in the time the project is expected. :)
This is incredibly good advice
Great article and great advice !
It's so true !
+1000
It's a good thing to be able to work at a company where asking why is allowed.
Nice tip.
It is hardest to evaluate when you are the only developer in the project.