Translator's Preface: After reading this article, you may be surprised or even angry. Yes, we were also surprised: the author seemed to have never heard about the hierarchy in the team, about setting tasks with the status “do it quickly and without reasoning.” Yes, that's right, it's a bit strange text. Indeed, the author offers the programmer to take on the role of a system architect - why then do you need an architect? But all these objections should not obscure the main thing from you - why we nevertheless took and translated this text. It's not about roles. This text is about a professional approach and awareness. The truth is that as long as you just “do what they say” without thinking about the meaning of your actions, you will never become a great programmer.
Say "no" to extra code. All you have to do is put three letters together and say the word. Let's try to do it together: "Noooo!"
But wait. Why are we doing this? After all, the main task of a programmer is to write code. But do you need to write any code that is required of you? No! “Knowing when not to write code is probably the most important skill for a programmer.” .
We remind you: for all readers of "Habr" - a discount of 10 rubles when enrolling in any Skillbox course using the "Habr" promotional code.
Skillbox recommends: Practical course .
Programming is the art of problem solving. And you are the masters of this art.
Sometimes, in an effort to get started as soon as possible, we do not think about anything other than completing the task. And this can cause even more serious problems.
What do programmers turn a blind eye to?
All code you write should be understandable to other developers, as well as tested and debugged.
But there is a problem: whatever you write will complicate your software and probably add bugs in the future.
According to Rich Skrent, . Here is what he writes:
“Code is bad because it starts to rot and requires constant maintenance. Adding new features often requires modifying old code. The larger it is, the higher the probability of an error and the more time it takes to compile. It takes more time for another developer to figure it out. And if refactoring is needed, then there will definitely be fragments that are worth changing. Large code often means reduced flexibility and functionality of the project. A simple and elegant solution is faster than complex code."
How do you know when not to write code?
The problem is that programmers often exaggerate the number of features their application needs. As a result, many sections of code remain incomplete or no one uses them, but they complicate the application.
You must be clear about what your project needs and what it doesn't.
An example is an application that solves only one task - manages e-mail. For this, two functions have been introduced - sending and receiving letters. Don't expect a mail manager to become a task manager at the same time.
You need to firmly say "no" to proposals to add features that are not related to the main task of the application. This is exactly the moment when it becomes clear that additional code is not needed.
Never lose the focus of your application.
Always ask yourself:
What function should be implemented now?
What code should be written?
Challenge the ideas that come to mind and evaluate suggestions from the outside. Otherwise, extra code can just kill the project.
Knowing when not to add too much will allow you to keep your codebase under firm control.
At the very beginning of the path, the programmer has only two or three source files. Everything is simple. Compiling and running the application requires a minimum of time; it is always clear where and what to look for.
As the application expands, more and more code files appear. They fill the catalog, each with hundreds of lines. In order to organize all this correctly, you will have to create additional directories. At the same time, it becomes more and more difficult to remember which functions are responsible for what and which actions they cause; catching bugs also takes more time. Project management is also becoming more complex, it takes not one, but several developers to keep track of everything. Accordingly, costs, both monetary and time, are growing, and the development process is being slowed down.
The project eventually becomes huge, adding each new feature is given with more and more difficulty. Even for something very small, you have to spend several hours. Correction of existing errors leads to the appearance of new ones, the deadlines for the release of the application are disrupted.
Now we have to fight for the life of the project. Why?
The fact is that you simply did not understand when it was not necessary to add extra code, and answered “yes” to every suggestion and idea. You were blind, the desire to create something new made you ignore important facts.
Sounds like a horror movie script, right?
This is exactly what will happen if you keep saying yes. Try to understand when code is not worth adding. Remove unnecessary things from the project - this will greatly facilitate your life and extend the life of the application.
“One of my most productive days is the one when I removed 1000 lines of code.”
— Ken Thompson.
Learning to know when not to write code is hard. But it is necessary.
Yes, I know that you have just entered the path of a developer and want to write code. That's good, don't lose that first impression, but don't lose sight of important factors out of enthusiasm either. We figured it out through trial and error. You too will make mistakes and learn from them. But if you can learn from the above, your work will become more conscious.
Keep creating, but know when to say no.
Skillbox recommends:
- Applied online course .
- Online course .
- Practical year course .
Source: habr.com