Your code does not interest anyone
My code does not interest anyone. I was shocked when I realized this while working as a programmer. I spent a lot of time sharpening my code until I realized that it was of no interest to anyone, because it’s not the code itself that counts, but the product. The acceptance of this fact by a programmer will lead to an increase in the productivity and value of his work.
Writing code is not a programmer’s job. And it is to create an application for solving certain tasks. Yes, the code is the main tool used for this, but still it is just a tool. Just as the work of a carpenter is not to use a hammer or saw - it is to produce something with these tools.
However, some actions can lead to an erroneous opinion that the code is a product. For example, refactoring: what do we improve with its help: code or product? If the answer code - no manager will not give time for this occupation. But it is worth explaining that this may correct existing errors or help introduce a new opportunity, and, suddenly, there will be time for it.
')
The application is primarily assessed entirely. This should be remembered when writing each line of code. If the product is unattractive, it makes no sense to discuss anything further. Even if all the tools are well used, the work fails if the product is bad.
This does not mean that the code is not something valuable and should not be checked in the context of product requirements. Ensuring security and resiliency requires skill and the use of the right libraries. This is where the code should do its work, the rest should not stand out. The faster the reviewer passes such a code, the more he will be satisfied.
The idea “Code is a tool” is the reason for the importance of knowledge of several languages ​​and frameworks; the reason for the benefits of knowledge of mathematics and theory of complexity, but the lack of need for such knowledge; the reason why the development environment can be both a great find and the worst trap. All this is a measure of flexibility for the programmer, which directly depends on the diversity of its tools.
Take, for example, a meeting with PM or customer. What will you tell him? How many lines of code are written, how many classes are created, how do scripts work, are exceptions handled, and how is the database arranged?
Unfortunately, the answer to all these questions is often "Yes, that is what I will tell him." And did you see his face at that time? He's bored. He would quickly move on to the following points. These details have no value for him. It’s not that he doesn’t understand what he is talking about, he just doesn’t care.
Imagine that the designer will begin to tell you about the layers he used in Photoshop, about how many objects he has there, what gradients are used on which brushes and what cool animation scripts he wrote. You are not interested. You are wondering if you can already take pictures.
It is necessary to communicate at the level of readiness states: import is ready, but there is not enough support for this and that; The application works on most phones, but it still slows down on this; The client application is already working, but the functionality is still poor. That's what's important for a manager or customer. This is what brings him information that is useful in the context of planning further actions.
I often encounter issues on the Internet related to source code protection. The programmer writes the code for the customer and uses his personal library for this. And so, the client requires the source code of the entire project, and the programmer thinks: I do not want to give the valuable code of my library.
First, let's think about why the client may need source code at all. Perhaps, for confidence in the possibility of continuing development, even if the programmer suddenly disappears. Perhaps to conduct a security audit or license compliance. By itself, the code is not needed, again, it just plays the role of a tool for performing some other task.
And although a personal library may be a worthwhile thing, it is not a value in itself. It will be important only for you, as it allows you to work faster. Actually, it may be the most important part of your business, but another programmer may discard it as unnecessary.
But what if the library is really valuable? If indeed there is confidence that she herself can be a product. Then you can share it, or even sell it, maybe that will come out. One need only take into account that very few such products have achieved at least some success.
Such an exercise is generally useful for any programmer. It leads to the realization of how few other programmers are interested in your work. Yes, take even your own project. What are you guided by when choosing a third-party library: what kind of cool code is in it, or what cool things can it do? Do you even look into its code after installation?
What does this mean, you can write a suck code? No, it does not mean. To create a quality product you need skill. Despite the fact that the code does not interest anyone, it is still the main tool for achieving the goal. And although perfectionism can be a curse, but if it is inefficient to use this tool, then we will not fulfill the task.
Returning to the analogy with a carpenter, a dirty hammer will score a nail no worse than polished, but a rusty one can easily break upon impact and even hurt.
The programmer’s goal is to improve the product, not the code. For maximum efficiency, you need to build on what the product should do and understand what the true value of the result is.
Code is a tool
Writing code is not a programmer’s job. And it is to create an application for solving certain tasks. Yes, the code is the main tool used for this, but still it is just a tool. Just as the work of a carpenter is not to use a hammer or saw - it is to produce something with these tools.
However, some actions can lead to an erroneous opinion that the code is a product. For example, refactoring: what do we improve with its help: code or product? If the answer code - no manager will not give time for this occupation. But it is worth explaining that this may correct existing errors or help introduce a new opportunity, and, suddenly, there will be time for it.
')
The application is primarily assessed entirely. This should be remembered when writing each line of code. If the product is unattractive, it makes no sense to discuss anything further. Even if all the tools are well used, the work fails if the product is bad.
This does not mean that the code is not something valuable and should not be checked in the context of product requirements. Ensuring security and resiliency requires skill and the use of the right libraries. This is where the code should do its work, the rest should not stand out. The faster the reviewer passes such a code, the more he will be satisfied.
The idea “Code is a tool” is the reason for the importance of knowledge of several languages ​​and frameworks; the reason for the benefits of knowledge of mathematics and theory of complexity, but the lack of need for such knowledge; the reason why the development environment can be both a great find and the worst trap. All this is a measure of flexibility for the programmer, which directly depends on the diversity of its tools.
Emphasis on characteristics
Take, for example, a meeting with PM or customer. What will you tell him? How many lines of code are written, how many classes are created, how do scripts work, are exceptions handled, and how is the database arranged?
Unfortunately, the answer to all these questions is often "Yes, that is what I will tell him." And did you see his face at that time? He's bored. He would quickly move on to the following points. These details have no value for him. It’s not that he doesn’t understand what he is talking about, he just doesn’t care.
Imagine that the designer will begin to tell you about the layers he used in Photoshop, about how many objects he has there, what gradients are used on which brushes and what cool animation scripts he wrote. You are not interested. You are wondering if you can already take pictures.
It is necessary to communicate at the level of readiness states: import is ready, but there is not enough support for this and that; The application works on most phones, but it still slows down on this; The client application is already working, but the functionality is still poor. That's what's important for a manager or customer. This is what brings him information that is useful in the context of planning further actions.
Your library is worth nothing
I often encounter issues on the Internet related to source code protection. The programmer writes the code for the customer and uses his personal library for this. And so, the client requires the source code of the entire project, and the programmer thinks: I do not want to give the valuable code of my library.
First, let's think about why the client may need source code at all. Perhaps, for confidence in the possibility of continuing development, even if the programmer suddenly disappears. Perhaps to conduct a security audit or license compliance. By itself, the code is not needed, again, it just plays the role of a tool for performing some other task.
And although a personal library may be a worthwhile thing, it is not a value in itself. It will be important only for you, as it allows you to work faster. Actually, it may be the most important part of your business, but another programmer may discard it as unnecessary.
But what if the library is really valuable? If indeed there is confidence that she herself can be a product. Then you can share it, or even sell it, maybe that will come out. One need only take into account that very few such products have achieved at least some success.
Such an exercise is generally useful for any programmer. It leads to the realization of how few other programmers are interested in your work. Yes, take even your own project. What are you guided by when choosing a third-party library: what kind of cool code is in it, or what cool things can it do? Do you even look into its code after installation?
Yes, but ...
What does this mean, you can write a suck code? No, it does not mean. To create a quality product you need skill. Despite the fact that the code does not interest anyone, it is still the main tool for achieving the goal. And although perfectionism can be a curse, but if it is inefficient to use this tool, then we will not fulfill the task.
Returning to the analogy with a carpenter, a dirty hammer will score a nail no worse than polished, but a rusty one can easily break upon impact and even hurt.
The programmer’s goal is to improve the product, not the code. For maximum efficiency, you need to build on what the product should do and understand what the true value of the result is.
Source: https://habr.com/ru/post/256175/
All Articles