What every developer should know from the start
As a developer, you will hear many crazy, incredible theories about the meaning of “lines of code”. Do not believe a single one. Lines of code are ridiculous metrics. In very rare cases, she says something, usually nothing. Using lines of code to make decisions is like evaluating the quality of a book by the number of pages.
Some may say that the fewer lines of code in an application, the easier it is to read. This is only partially true. Here are my metrics for readable code:
If reducing the number of lines of code contradicts any of these metrics, this becomes a problem. In practice, it will almost always interfere and, therefore, is almost always a problem. But here's the thing, if you strive to meet the above criteria, then your code will have an ideal number of lines - and you do not need to count them .
Languages ​​are not necessarily “good” or “bad”
Except php, of course (a joke). A source
I see people say such things all the time:
The idea that language comparisons can be reduced to one sentence is almost offensive. These are languages, not Pokémon.
Do not get me wrong, there are definitely differences between languages. There are simply practically no “useless” languages ​​(although there are many outdated / dead). Each language has its own unique set of compromises. In this regard, they look like a toolbox. A screwdriver can do what a hammer cannot do, but will someone say that a screwdriver is better than a hammer?
(Obviously, the hammer is better)
Before I talk about language assessment, I want to clarify something. Choosing a language very rarely matters . Of course, some things cannot be done in some languages. If you are writing for a frontend, then you have no choice. There are specific contexts where performance is important, and the X language is simply not suitable, but such situations are quite rare. In general, language selection is usually one of the least important issues for a project.
Here are the main aspects in order, which, in my opinion, should influence the choice of language (without specific metrics):
Some important factors are beyond your influence. If you work in the field of data science, then you really need to use Python, R or Scala (possibly Java). If this is a hobby project, use what you like. I have only one indisputable rule. I refuse to use languages ​​if most of the possible problems with this language are not resolved already on StackOverflow. It’s not that I can’t solve them, it’s just not worth the time.
Reading someone else's code is difficult. Robert C. Martin says this in Pure Code: “Actually, the ratio of time to read and write code is much more than 10 to 1. We constantly read the old code when we try to write a new one. ... [Therefore] that which simplifies its reading also simplifies its writing. "
For a long time, I thought I was just weak at reading someone else's code. Over time, I realized that almost every programmer faces this problem every day. Reading someone else's code is like reading a text in a foreign language. Even if you are comfortable with choosing the programming language of the author of the code, you still have to adapt to different styles and architecture options. It also suggests that the author wrote consistent and reliable code, which may be true or not. This is really hard. There are a few things that have helped me VERY.
A review of someone else's code will greatly improve your skills. Over the past two years, I have done quite a few reviews for the pool requests on Github. With each new one, I feel a little more confident in reading someone else's code. GitHub pool requests are especially useful for the following reasons:
The second technique, which will help to read someone else's code, is a bit more unique. This is a technique that I invented, and it really reduced the amount of time that I need to feel comfortable in someone else's code base. After looking at the style of code that I want to read, I first open vi and start writing code in the same style. When you write code in a new style, it also improves your reading skills. The style will become less alien when you yourself have experienced it. Even if I just watch a random project on Github, I quickly apply this technique. Try it yourself.
I had been programming alone for four years before starting to work in a team. For most of this time, I simply assumed that every programmer in the industry wrote perfect code. I decided that it was just a matter of time and effort before I also wrote the “perfect” code.
This is something that I was very worried about before. As soon as I joined the team, it quickly became clear that no one was writing the “perfect” code. But the code included in the system was almost always "perfect." How? Answer: code review.
I work with a team of really brilliant engineers. These are some of the most competent, confident programmers you can buy for money. Each member of our team (including me) will begin a real panic attack if someone ever offers to commit the code without a review. Even if you think you're the next Bill Gates, you will definitely make mistakes. I’m not even talking about logical errors, I’m talking about typos, missing characters. That your brain simply does not notice. What you need another pair of eyes for.
Try to work with other people who are attentive to details and willing to criticize your work. Hearing criticism is difficult at first, but it is the only consistent way to improve the situation. Do your best not to become defensive during the code review, and never take any comments personally. You are not your code.
In a code review, if the author made a choice that I am not familiar with, I will immediately google if his choice is different from the popular opinion. The point is not that popular opinion is always right, just popular opinion is the default choice. If someone decided not to accept the popular choice, that’s fine, I just want to know that it’s justified. When reviewing the code, it is very important that you understand the rationale for the decisions made. In addition, looking at the same problem from the perspective of a beginner , one can often notice things that a person would never have paid attention to.
This is a very common question, but people never give a clear answer. How much does an average developer or “excellent” developer spend writing code every day?
Very few code more than four hours a day
Those who disagree with this are either exceptions to the rule or work for companies that exploit them too much. Programming is a mentally exhausting, intense task. It is completely unreasonable to expect someone to write the code 8 hours a day, five days a week. There are times when you need to meet deadlines or do a little more per session, but there are few of them and they are rare. When I say "rarely," I mean almost never. Avoid workflows that abuse you and make you work overtime due to poor planning / staff shortages.
For the protocol, even the company itself is not profitable for you to actively program 8 hours a day. Your boss may think that this is so, but it is short-sighted and he ignores the long-term consequences, as it affects productivity and mental health.
Just for the sake of clarity, I do not suggest you work only four hours a day. The remaining four hours are usually best spent on:
I also strongly recommend taking regular breaks during the day and playing sports (at least not for long). The benefits of exercise to combat mental fatigue are well documented. I personally found that exercise is especially helpful if there are problems with concentration.
These are some things that I would like to learn at the university instead of a pure theory. In the process of writing, I thought about a ton of other nuances, but this is a topic for a separate article!
Some may say that the fewer lines of code in an application, the easier it is to read. This is only partially true. Here are my metrics for readable code:
- The code must be consistent
- The code should be informative.
- The code should be well documented.
- The code should use stable modern functions.
- Code doesn't have to be too complicated
- The code should not be inefficient (do not intentionally write slow code)
If reducing the number of lines of code contradicts any of these metrics, this becomes a problem. In practice, it will almost always interfere and, therefore, is almost always a problem. But here's the thing, if you strive to meet the above criteria, then your code will have an ideal number of lines - and you do not need to count them .
Languages ​​are not necessarily “good” or “bad”
Except php, of course (a joke). A source
I see people say such things all the time:
- C is better than X because of performance
- Python is better than X because of brevity
- Haskell is better than X because of aliens
The idea that language comparisons can be reduced to one sentence is almost offensive. These are languages, not Pokémon.
Do not get me wrong, there are definitely differences between languages. There are simply practically no “useless” languages ​​(although there are many outdated / dead). Each language has its own unique set of compromises. In this regard, they look like a toolbox. A screwdriver can do what a hammer cannot do, but will someone say that a screwdriver is better than a hammer?
(Obviously, the hammer is better)
Before I talk about language assessment, I want to clarify something. Choosing a language very rarely matters . Of course, some things cannot be done in some languages. If you are writing for a frontend, then you have no choice. There are specific contexts where performance is important, and the X language is simply not suitable, but such situations are quite rare. In general, language selection is usually one of the least important issues for a project.
Here are the main aspects in order, which, in my opinion, should influence the choice of language (without specific metrics):
- Density of available online resources (StackOverflow density)
- Development speed
- Error predisposition
- The quality and coverage of a package ecosystem (yes, npm, talking about quality)
- Performance (more points)
- Employment Opportunity (Sorry, COBOL)
Some important factors are beyond your influence. If you work in the field of data science, then you really need to use Python, R or Scala (possibly Java). If this is a hobby project, use what you like. I have only one indisputable rule. I refuse to use languages ​​if most of the possible problems with this language are not resolved already on StackOverflow. It’s not that I can’t solve them, it’s just not worth the time.
Reading someone else’s code is hard
Reading someone else's code is difficult. Robert C. Martin says this in Pure Code: “Actually, the ratio of time to read and write code is much more than 10 to 1. We constantly read the old code when we try to write a new one. ... [Therefore] that which simplifies its reading also simplifies its writing. "
For a long time, I thought I was just weak at reading someone else's code. Over time, I realized that almost every programmer faces this problem every day. Reading someone else's code is like reading a text in a foreign language. Even if you are comfortable with choosing the programming language of the author of the code, you still have to adapt to different styles and architecture options. It also suggests that the author wrote consistent and reliable code, which may be true or not. This is really hard. There are a few things that have helped me VERY.
A review of someone else's code will greatly improve your skills. Over the past two years, I have done quite a few reviews for the pool requests on Github. With each new one, I feel a little more confident in reading someone else's code. GitHub pool requests are especially useful for the following reasons:
- Here you can conduct a review at any time, just find an open source project in which you want to contribute.
- Reading in a limited context (single function or bug).
- It requires attention to detail, which will make you appreciate each line.
The second technique, which will help to read someone else's code, is a bit more unique. This is a technique that I invented, and it really reduced the amount of time that I need to feel comfortable in someone else's code base. After looking at the style of code that I want to read, I first open vi and start writing code in the same style. When you write code in a new style, it also improves your reading skills. The style will become less alien when you yourself have experienced it. Even if I just watch a random project on Github, I quickly apply this technique. Try it yourself.
You will never write “perfect” code
I had been programming alone for four years before starting to work in a team. For most of this time, I simply assumed that every programmer in the industry wrote perfect code. I decided that it was just a matter of time and effort before I also wrote the “perfect” code.
This is something that I was very worried about before. As soon as I joined the team, it quickly became clear that no one was writing the “perfect” code. But the code included in the system was almost always "perfect." How? Answer: code review.
I work with a team of really brilliant engineers. These are some of the most competent, confident programmers you can buy for money. Each member of our team (including me) will begin a real panic attack if someone ever offers to commit the code without a review. Even if you think you're the next Bill Gates, you will definitely make mistakes. I’m not even talking about logical errors, I’m talking about typos, missing characters. That your brain simply does not notice. What you need another pair of eyes for.
Try to work with other people who are attentive to details and willing to criticize your work. Hearing criticism is difficult at first, but it is the only consistent way to improve the situation. Do your best not to become defensive during the code review, and never take any comments personally. You are not your code.
In a code review, if the author made a choice that I am not familiar with, I will immediately google if his choice is different from the popular opinion. The point is not that popular opinion is always right, just popular opinion is the default choice. If someone decided not to accept the popular choice, that’s fine, I just want to know that it’s justified. When reviewing the code, it is very important that you understand the rationale for the decisions made. In addition, looking at the same problem from the perspective of a beginner , one can often notice things that a person would never have paid attention to.
The work of a programmer does not mean 8 hours of programming per day
This is a very common question, but people never give a clear answer. How much does an average developer or “excellent” developer spend writing code every day?
Very few code more than four hours a day
Those who disagree with this are either exceptions to the rule or work for companies that exploit them too much. Programming is a mentally exhausting, intense task. It is completely unreasonable to expect someone to write the code 8 hours a day, five days a week. There are times when you need to meet deadlines or do a little more per session, but there are few of them and they are rare. When I say "rarely," I mean almost never. Avoid workflows that abuse you and make you work overtime due to poor planning / staff shortages.
For the protocol, even the company itself is not profitable for you to actively program 8 hours a day. Your boss may think that this is so, but it is short-sighted and he ignores the long-term consequences, as it affects productivity and mental health.
Just for the sake of clarity, I do not suggest you work only four hours a day. The remaining four hours are usually best spent on:
- Research, both related to work and not related
- Discussion of your work with colleagues
- Assistance to colleagues who have problems with their own work
- Future work planning
- Code check
- Meetings
I also strongly recommend taking regular breaks during the day and playing sports (at least not for long). The benefits of exercise to combat mental fatigue are well documented. I personally found that exercise is especially helpful if there are problems with concentration.
These are some things that I would like to learn at the university instead of a pure theory. In the process of writing, I thought about a ton of other nuances, but this is a topic for a separate article!
All Articles