What is a good programmer?

To judge whether a programmer is a good programmer, it mainly depends on the Code he writes, because the most important thing for a programmer is to write code.

Even if you don't understand the intention of the code, you just need to take a look at the code written by good programmers and the code written by poor programmers. The code written by good programmers is neat and standardized, and visually there is naturally a kind of aesthetic. The blank space is incorrect, the comment is correct, and the naming and layout are consistent. Code written by poor programmers is often prone to long functions, inconsistent naming and formatting, over-depth nested structures, very complex expressions, and ubiquitous numbers.

Read the program in a rough way, and be more confident in a good programmer or a poor programmer. The code written by good programmers has a well-crafted consistency. Good programmers always follow the same naming method, such as camelcase, while the variable naming of poor Programmers sometimes deviates from the Unified specification. Good programmers have almost no spelling mistakes in their code, while poor programmers have more spelling mistakes. A good programmer will not use this verb for the same kind of action, but will use that synonym, such as Add/insert. Good programmers adopt consistent shorthand rules, while poor programmers are sometimes not abbreviated. Good programmers will pay attention to the adjectives and nouns in their names, while poor programmers have no rules, sometimes before and after. Good programmers seldom write large sections of repetitive code, but poor programmers often do not have to repeat the code. It is difficult for them to extract duplicate code and reuse it with a unified concept. Good programmers pay attention to the consistency of comments and codes for external APIs, while poor programmers often comment on different parameter names and function definitions. Good programmers seldom leave spam Code that has been commented out or enclosed by # If 0. They are determined to use the code. If the code is useful, they will not use it. If the code is useless, the difference is true for poor programmers, they are often not sure whether a piece of code is really needed. They lack the habit of keeping the code clean, so they keep the junk code.

As mentioned above, even if you do not understand the language he uses, but do not care about the logic of the program, a good programmer or a poor programmer will be able to make a perfect decision. The quality of programs almost always depends on whether they are "beautiful", not "beautiful" and good programs. Except for the c ++ STL source code, I have never seen them again (if you take a closer look, although the source code of STL is not "beautiful", it still satisfies the consistency principle proposed here ). Good and beautiful code can be seen everywhere, such as Linux kernel, InnoDB, JDK, and JUnit.

If you read it carefully, it will be more accurate. The code written by good programmers is simple and straightforward. The function is usually short and small, and the function name accurately reflects the work to be done by the function. The logic is simple and natural. When you read it, you can say "ah, it should be like this". The Code of poor programmers often asks you to "why? What is this ?" . A good programmer will make eye-catching comments at a critical moment. A poor programmer either does not make comments, or the comments only repeat the code. They are pure nonsense. Even worse, the comments are wrong and misleading.

A good programmer may not be a "language lawyer", that is, the guy who understands every detail of the language very clearly and uses it everywhere during programming. Good programmers do not often use their own skills. They carefully construct some ingenious pieces in the Code. They will occasionally, but most of the time they are expressed in straightforward language.

The Code also shows a programmer's team spirit. Note that programmers who work with the team will write code strictly in accordance with the team specifications, while programmers whose style is inconsistent with the team specifications may lack team spirit. The team coworking programmers should pay attention to the important description of the module's external interface, such as the preconditions, post-conditions, and whether the parameter can be null, programmers who do not pay attention to teamwork are too lazy to deal with these details.

The productivity of good programmers is very different from that of poor programmers. The longer the project cycle, the more complex the project is. The higher the quality requirement of the project, the greater the value of good programmers. Good programmers and bad programmers have huge management costs. Good programmers only need to work with them to determine the design. The code can be ignored. The Code of poor programmers often needs to be reviewed multiple times, and there is still a way to achieve the desired quality.

To become a good programmer, we must first establish the ambition to become a good programmer, and then work diligently and practice. After a long time, we will get better and better. These people are not afraid of being old. No ambition can never be a good programmer. If these people become managers before they get old, they will become useless.

It is not enough to judge the programmer by taking a two-hour test and half-hour interview. Through a written test and interview, you can determine whether a programmer has basic knowledge such as algorithms and data structures, whether he has mastered the features of programming languages, and whether he is interested in technology, however, it is not enough to know whether he can complete the work well without writing code.

Those who seem enthusiastic about technology may not be good programmers. These people may be very happy to do new work, but subsequent coding, testing, debugging, and copywriting may make them bored. They may come up with good ideas, but they often cannot start or end with them. The company does not need many such people.

Therefore, recruitment methods need to be improved. Recruitment is the most important, because it is difficult to go out after coming in, even if it is a trial. It is clearly written in black and white. If you pass the qualification, you can turn positive. It is not difficult to pass the qualification. This year, many new people have been added to the Department. Not everyone is very good, but they are indeed qualified. Naturally, they should turn positive.

The way to improve recruitment is to allow him to write a program, produce two questions, let him write a program, and let him reconstruct an existing long program, which will be completed within one day. If you can test him for half a month, refactoring is not necessary, but the time of the day is too short. Through refactoring, you can examine the ability to read and understand the code, and refactor the capabilities of "corruption becomes magic. It is not ideal for people who do not want to write or accept others' code.

Two people used a similar method this year. One person with a very good resume was rejected after two programming questions. One person with a general resume and interview was hired through programming tests. I feel more accurate than a simple test and interview.