Ten things that a real programmer knows, even if they are not taught in universities
This topic has angered: habrahabr.ru/blogs/htranslations/95063 , and therefore I list these ten things
We are right whenever we think we know exactly how to build a system. Because often ready-made solutions do not fit perfectly in any situation. And those solutions that exist, for example, patterns, of which a huge amount, were written by us. Programmers. Therefore, yes! We are right. As for the need to listen to each other, this is more of a communication problem.
')
Theoretically everything can break. Even the fact that it is sufficiently atomic, and the possibility of a breakdown is simply excluded. But why doesn't it break? Because appropriate conditions are necessary that may or may not occur. There are cases when the redesign of systems revealed errors that were able to crash the system. But for many years of the system, the corresponding conditions have not come.
Sorry for such a headline. Sometimes a code where the same set of statements is repeated three times is more stable than a similar code, where a set of statements is enclosed in a loop. This is not a call to write in this way, but only an attempt to draw the reader’s attention to the palette of options in which the task is solved, and the system works long and fail-safe.
In general, “shitty” code is a purely subjective concept. After all, every programmer from the height of his experience is able to assess how versatile / more efficient / faster / more beautiful he can write. Therefore, there are sites like "govnokod" and other stupid resources on the network.
There are no bugs in the program that has not yet been written :-).
But I remember the case in the second year of university. In the hex editor wrote a com-program that did nothing. It was necessary to write 2 opcodes: nop and ret. They were mixed up in places. Not terrible, but a bug.
These things I will not trade for any ambitions of any client. I will interrupt on trifles, at first earning not as much as we would like. I will look for options. But the main thing is not to stop developing and remember that it is really important for you as a growing programmer.
It is a habit after passing the laboratory work on the first courses of the university. Particularly diligent students can even sketch their program on paper a couple of times before they want to transfer it to an electronic source. Some very diligent teachers scold students who are not very diligent, for throwing a program in the editor and typing it into a report after debugging and not rewriting with their hands. What I want to say: that the presentation of the program on paper is complete nonsense.
The question is rather philosophical. It depends on what is more and what is less. The ideal option in my opinion is when there are many small things, and this small things interact with each other. But do not forget that the ready recipes still do not solve the ideal problem. Therefore, the question retains a philosophical status.
If we distinguish between the concepts of "coding" and "programming", then vice versa - coding takes 80% of the time, and real programming - only 20%.
If you do not distinguish between these concepts, experience shows that the Pareto law does not always work perfectly. And it depends on the size of the system. Often the system can be simple, but voluminous in terms of implementation. Then planning, etc. etc. occupy a small part of the time. Conversely, the system may be small, but difficult to implement. At the same time, you can plan and model it for a week. And then overnight to write two hundred lines of code and successfully debug in a couple of hours.
He knows what he wants:
- some solution
- automation
- representative site
- control system
- savings
How it will be implemented, what tools and means, what details will be in the project, how many people will write it, in python or php, this is not needed by the customer. He is entirely in business, he knows what he needs in a business context.
While the routine task requires full return to overcome the routine barrier.
If someone already did, of course worth a look. But from the above points, it is clear that sometimes it is better to write your own “bydlokod” than to pull up a heavy, piled-up framework, especially when this is not actually required.
1. We are right
We are right whenever we think we know exactly how to build a system. Because often ready-made solutions do not fit perfectly in any situation. And those solutions that exist, for example, patterns, of which a huge amount, were written by us. Programmers. Therefore, yes! We are right. As for the need to listen to each other, this is more of a communication problem.
')
2. Not everything that can break - breaks
Theoretically everything can break. Even the fact that it is sufficiently atomic, and the possibility of a breakdown is simply excluded. But why doesn't it break? Because appropriate conditions are necessary that may or may not occur. There are cases when the redesign of systems revealed errors that were able to crash the system. But for many years of the system, the corresponding conditions have not come.
3. Not all code is “crap”
Sorry for such a headline. Sometimes a code where the same set of statements is repeated three times is more stable than a similar code, where a set of statements is enclosed in a loop. This is not a call to write in this way, but only an attempt to draw the reader’s attention to the palette of options in which the task is solved, and the system works long and fail-safe.
In general, “shitty” code is a purely subjective concept. After all, every programmer from the height of his experience is able to assess how versatile / more efficient / faster / more beautiful he can write. Therefore, there are sites like "govnokod" and other stupid resources on the network.
4. The program does not always have a bug
There are no bugs in the program that has not yet been written :-).
But I remember the case in the second year of university. In the hex editor wrote a com-program that did nothing. It was necessary to write 2 opcodes: nop and ret. They were mixed up in places. Not terrible, but a bug.
5. The most important thing is well-being and the pursuit of excellence.
These things I will not trade for any ambitions of any client. I will interrupt on trifles, at first earning not as much as we would like. I will look for options. But the main thing is not to stop developing and remember that it is really important for you as a growing programmer.
6. The program outlined on paper ...
It is a habit after passing the laboratory work on the first courses of the university. Particularly diligent students can even sketch their program on paper a couple of times before they want to transfer it to an electronic source. Some very diligent teachers scold students who are not very diligent, for throwing a program in the editor and typing it into a report after debugging and not rewriting with their hands. What I want to say: that the presentation of the program on paper is complete nonsense.
7. Less is better; more is better.
The question is rather philosophical. It depends on what is more and what is less. The ideal option in my opinion is when there are many small things, and this small things interact with each other. But do not forget that the ready recipes still do not solve the ideal problem. Therefore, the question retains a philosophical status.
8. Coding takes 20% of the time.
If we distinguish between the concepts of "coding" and "programming", then vice versa - coding takes 80% of the time, and real programming - only 20%.
If you do not distinguish between these concepts, experience shows that the Pareto law does not always work perfectly. And it depends on the size of the system. Often the system can be simple, but voluminous in terms of implementation. Then planning, etc. etc. occupy a small part of the time. Conversely, the system may be small, but difficult to implement. At the same time, you can plan and model it for a week. And then overnight to write two hundred lines of code and successfully debug in a couple of hours.
9. The customer knows what he wants
He knows what he wants:
- some solution
- automation
- representative site
- control system
- savings
How it will be implemented, what tools and means, what details will be in the project, how many people will write it, in python or php, this is not needed by the customer. He is entirely in business, he knows what he needs in a business context.
10. An interesting task - half the success in solving it.
While the routine task requires full return to overcome the routine barrier.
If someone already did, of course worth a look. But from the above points, it is clear that sometimes it is better to write your own “bydlokod” than to pull up a heavy, piled-up framework, especially when this is not actually required.
Source: https://habr.com/ru/post/95245/
All Articles