June 2, 2010 at 12:39Ten things that a true programmer knows, even if they are not taught at universities
This topic outraged: habrahabr.ru/blogs/htranslations/95063 , and therefore I list these ten things
We are right whenever we think that we know exactly how to build a system. Because often ready-made solutions do not fit perfectly in any situation. And those solutions that are available, for example, patterns, of which there are a huge number, were written by us. By programmers. Therefore, yes! We are right. But as for the need to listen to each other, it is rather a communication problem.
Theoretically, everything can break. Even that which is atomic enough, and the option of failure is simply excluded. But why doesn't it break? Because appropriate conditions are needed that may or may not occur. There are cases when, when redesigning systems, errors were detected that were able to crash the system. But over many years of the system’s operation, the corresponding conditions have not come.
Sorry for that 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 a palette of options in which the task is solved, and the system works for a long time and is fault-tolerant.
In general, the “crap” code is a purely subjective concept. Indeed, each programmer from the height of his experience is able to evaluate how versatile / efficient / faster / more beautiful he can write. Therefore, there are sites like "govnokoda" and other stupid resources on the network.
There are no bugs in a program that has not yet been written :-).
But I recall a case in the second year of university. In a hex editor, he wrote a com program that did nothing. It was necessary to write 2 opcodes: nop and ret. They were mixed up. Not scary, but a bug.
I will not exchange these things for any ambitions of any client. I’ll interrupt the little things, at first I will not earn as much as we would like. I will look for options. But the main thing is not to stop in development and remember that it is really important for you as a growing programmer.
This is a habit after passing the laboratory work in 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 the electronic source. Some very diligent teachers scolded not very diligent students, because they sketch the program in the editor and after debugging print it in the report and not rewrite it by hand. What I want to say about: that writing a 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 is a lot of small things, and this small one interacts with each other. But do not forget that ready recipes still do not solve the perfect problem. Therefore, the question retains the status of philosophical.
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, then 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. take up a small part of the time. Conversely, a system can be small, but difficult to implement. At the same time, you can plan, model it for a whole week. And then overnight write two hundred lines of code and successfully debug in a couple of hours.
He knows what he wants:
- some solution
- automation
- a representative site
- control system
- saving
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 for the customer necessary. He is completely and completely in business, he knows what he needs in the context of business.
While a routine task requires full dedication to overcome the routine barrier.
If someone has already done, it is certainly worth a look. But from the points listed above it is clear that sometimes it’s better to write your “bydlokod" than to pull up a heavyweight piled up framework, especially when this is essentially not required.
1. We are right
We are right whenever we think that we know exactly how to build a system. Because often ready-made solutions do not fit perfectly in any situation. And those solutions that are available, for example, patterns, of which there are a huge number, were written by us. By programmers. Therefore, yes! We are right. But as for the need to listen to each other, it is rather a communication problem.
2. Not everything that can break is broken
Theoretically, everything can break. Even that which is atomic enough, and the option of failure is simply excluded. But why doesn't it break? Because appropriate conditions are needed that may or may not occur. There are cases when, when redesigning systems, errors were detected that were able to crash the system. But over many years of the system’s operation, the corresponding conditions have not come.
3. Not all code is “crap”
Sorry for that 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 a palette of options in which the task is solved, and the system works for a long time and is fault-tolerant.
In general, the “crap” code is a purely subjective concept. Indeed, each programmer from the height of his experience is able to evaluate how versatile / efficient / faster / more beautiful he can write. Therefore, there are sites like "govnokoda" and other stupid resources on the network.
4. The program does not always have a bug
There are no bugs in a program that has not yet been written :-).
But I recall a case in the second year of university. In a hex editor, he wrote a com program that did nothing. It was necessary to write 2 opcodes: nop and ret. They were mixed up. Not scary, but a bug.
5. The most important thing is well-being and the pursuit of excellence.
I will not exchange these things for any ambitions of any client. I’ll interrupt the little things, at first I will not earn as much as we would like. I will look for options. But the main thing is not to stop in development and remember that it is really important for you as a growing programmer.
6. Paper program ...
This is a habit after passing the laboratory work in 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 the electronic source. Some very diligent teachers scolded not very diligent students, because they sketch the program in the editor and after debugging print it in the report and not rewrite it by hand. What I want to say about: that writing a program on paper is complete nonsense.
7. Less is better, more is even 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 is a lot of small things, and this small one interacts with each other. But do not forget that ready recipes still do not solve the perfect problem. Therefore, the question retains the status of philosophical.
8. Encoding 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, then 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. take up a small part of the time. Conversely, a system can be small, but difficult to implement. At the same time, you can plan, model it for a whole week. And then overnight 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
- a representative site
- control system
- saving
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 for the customer necessary. He is completely and completely in business, he knows what he needs in the context of business.
10. An interesting task - half the success in its solution
While a routine task requires full dedication to overcome the routine barrier.
If someone has already done, it is certainly worth a look. But from the points listed above it is clear that sometimes it’s better to write your “bydlokod" than to pull up a heavyweight piled up framework, especially when this is essentially not required.