How do you tell if a programmer is a "veteran" or "novice"?

In addition to years of programming experience, what can distinguish a programmer as "veteran" or "novice"? Programming skills are, of course, part of it, but it's definitely not all.

Smart programmers may have better programming skills than their peers, but that doesn't mean they are "old hands." Similarly, just because you have 10 of programming experience does not mean they are a master. In the workplace, having many years of programming experience does not explain the problem. Even if you are not fired, it will not improve your value.

The following are the things that most senior programmers will do.

1. Mastering at least one programming language

I believe that some good programmers only know (and are proficient) in a programming language, but in a way it can actually limit one's mind. Like when you're holding a hammer, everything looks like a nail. I think that knowing and successfully using at least one programming language is an important step for programmers to move from novice to veteran. I would say that, like JavaScript and SQL, auxiliary programming languages are valuable only if you have actually developed a complete application and used those programming languages in it.

2. Programming often in addition to work

I complained about open source as a requirement for hiring, but that's just because many passionate programmers spend their time elsewhere. In addition to contributing to open source, you can also be a part-time consultant, start a part-time business, develop your own products or start your own micro-software company. Of course, you can also try to pick up some part-time projects from outside, you can refer to Bole online This "successful project to pay attention to several points."

Note: MISV is MICROISV, is a software company with only one employee, is a kind of micro-company.

3. Experience a complete software development process, from concept design to product realization to product maintenance

Some programmers want to get detailed design instructions without having to do their own, and then hand the defect code to the test/maintenance team, which is a microcosm of mediocre programmers. Any competent programmer will work closely with the client to develop the requirements analysis, and then encode the implementation and, of course, maintain it. If you are lazy in the coding implementation phase, you have to pay the price in the maintenance phase.

4. Continuous innovation

Innovation is doing something that people around you haven't done to improve your process or product. You don't have to be the first person in the world to do this, just find a problem, find a solution and then implement it.

5. Software written to solve real-world problems

There is a fictional scene: A hacker, just out of love for technology and what he does, is writing code all day. But it's hardly a good developer. In fact, I've seen some developers and customers arguing about better technologies that are less helpful to customers. This is counterproductive. You can use your time to improve. But when it comes to work, it's best to write code that actually improves and solves the problem, rather than using unusual algorithms or interfaces.

How do you tell if a programmer is a "veteran" or "novice"?