Some might argue that the fewer lines of code in an application, the easier it is to read. This statement is only partially true, I think metrics for code readability include:
Code should be consistent
Code should be self-describing
Code should have good documentation
Code should use stable modern features
Code should not be overly complex
The performance of the code must not be a problem (don't write code that is intentionally slow)
If reducing lines of code affects any of the above, then something is wrong. In fact, basically reducing the number of lines of code will affect the above standard, so there will always be problems. However, if you can manage to meet the above conditions, then the number of lines of code is perfect, and there is no need to count numbers at all.
1 There is no good or bad language
Someone always says:
"C is better than X because C has better performance."
"Python is better than X because Python is more concise."
"Haskell is better than X because Haskell is an alien language."
In a nutshell, comparing programming languages is nonsense in and of itself. They are languages, not Pokemon.
Don't get me wrong, there are differences between languages, it's just that "good for nothing" languages are a minority after all (although there are many outdated languages). Each language has its unique advantages, and in this sense, languages are like tools in a toolbox. A screwdriver can do things a hammer can't, but would you say a screwdriver is better than a hammer? (Obviously a hammer is better).
Before talking about how to evaluate languages, I want to make a point. There are a few cases where the choice of language does matter, and some languages obviously can't handle certain cases. If you write front-end code, you don't even have the right to choose a language. There are certain situations where performance is important and language X is not an option, but these are rare. Often, the choice of language is one of the least important issues in a project.
Here are the core factors I think you should consider when choosing a language (highest to lowest priority):
Number of online resources (such as the number of questions on StackOverflow)
development speed
probability of error
The quality and breadth of the software package ecosystem
performance characteristics
Difficulty recruiting talent (sorry, COBOL)
There are also tight ties that can't be controlled. If you work in data science, you need to use Python, R, or Scala (and maybe Java). If it's a side project, then feel free to choose what you like. There is only one rule that I feel is non-negotiable: If most of the problems I encounter cannot be directly solved through StackOverflow, then I will refuse to use this language. It's not that I'm incapable of problem solving, but I don't think it's worth the time.
2 It is difficult to read other people's code
Reading other people's code is difficult. Robert C. Martin talks about this in "Clean Code":
"In fact, the ratio of time spent reading code to writing code is much greater than 10:1. We are constantly reading old code as we write new code. … [Therefore,] our code should be easy to read and easy to write .”
For a long time, I thought I was bad at reading other people's code. Over time, I realized that almost every programmer struggles with reading other people's code on a daily basis.
Reading other people's code is like learning a foreign language. Even if you are very familiar with a certain language, you still need to use other people's different styles and architectures. And we generally assume that the people who write the code implement consistency and reliability, but sometimes it is not the case, which is really a difficult problem to overcome. But I've found a lot of helpful tips.
Reading other people's code can greatly improve your ability to read code. Over the past two years, I've looked at a lot of PRs in Github. Every time I read a PR, I feel that my ability to read other people's code has improved a little bit. PRs in Github are especially helpful for the following reasons:
You can practice anytime, just find an open source project you want to contribute to.
Practice reading other people's code within a certain range (functional PR or bug fix PR).
Pay attention to the details required and try to read each line.
There is another helpful technique for reading other people's code, which is more unique. This trick comes to mind to drastically reduce the time it takes to read an unfamiliar code base. After seeing code in the style I want to read, I first open vi and start writing code in the style used in the project. This will reduce the strangeness of the code.
3 You can never write "perfect" code
Before joining the team, I was a "lone wolf" developer for 4 years. Most of the time, I assume that every programmer writes perfect code. I thought with a little effort and time, I would write "perfect" code too. "Java Development Manual (Songshan Edition)" I suggest you read it.
In the past, I used to get anxious about this a lot. After joining the team, I quickly discovered that no one can write "perfect" code. However, the code that goes into the system is almost always "perfect", why is that? The answer lies in code reviews.
We have very good engineers on our team. They are the most capable and confident programmers. If someone suggested committing unreviewed code, everyone on our team (including me) would jump at it. Even if you think you're the next Bill Gates, you'll make mistakes. It doesn't even need to rise to logical errors, and even typos and missing words are unavoidable. These are problems that your brain has no time to take care of, so you need someone else to check for you.
Strive to work with people who pay attention to detail and are happy to criticize your code. While it can be hard to hear criticism at first, it's the only way to keep improving. Do your best to avoid resistance during the code review process, and refrain from making personal comments. Try to be right about things and not about people.
When reviewing code, if the author of the code made a choice I'm not familiar with, I'll immediately Google to see if their choice doesn't match popular opinion. I'm not saying popular opinion is always right, just that popular opinion is the default choice. If someone decides not to follow the prevailing opinion, that's fine too, I just need to know if it makes sense. When reviewing code, it's crucial that you understand the rationale behind decisions. Also, looking at the same problem with a "beginner's head" can often reveal things that the person has left behind.
4 The job of a programmer does not mean that you have to stick to 8 hours of programming every day
How many hours a day does the average or "great" developer program? This is a very common question, but no one has ever given a definite answer.
Very few people write code for more than 4 hours a day.
People who disagree with this are either an exception or the company should cherish them. Programming is exhausting work that requires a lot of concentration. Asking programmers to write 5-8 hours of code every day is not humane. On rare occasions, someone will work extra hours in order to meet deadlines or for overtime pay, but this is rare. In fact, what I mean by "very few cases" here is almost none. If you are working overtime due to planning problems or under-recruitment, please don't tolerate it.
Frankly, writing 8 hours of code a day is not doing you or the company any good. If your boss makes such a request, it can only be said that he is short-sighted, because in the long run, this kind of high-intensity work has a bad impact on productivity and mental health.
Note that I am not suggesting that you only work 4 hours a day. Usually, we should spend the remaining 4 hours on the following tasks:
Research and development on work-related and non-work topics
Discuss work with colleagues
Help other hardworking colleagues
plan for future work
code review
the meeting
Beyond that, I highly recommend taking regular breaks and exercising (even if it's just a short workout) during your day at work. It turns out that exercise can be a big help in relieving mental fatigue. I've found that exercising is especially helpful when I'm having trouble concentrating.