# "Excellence is never accidental. It is always brought about by strong intentions, sincere dedication and smart actions. Excellence represents wisdom Choice - choice, not chance, will determine your destiny. "- Aristotle
What makes a good JavaScript developer?We can make judgments based on many criteria. Code quality, on-time delivery, and timely resolution of tickets (note: tickets are similar to issues in github, refer to here) are several standards that can be referenced. Of course, it also includes helping other team members solve tickets. I think none of the above points provide accurate measurements. Delaying an entire project for two months in order to write beautiful code simply because you want to refactor something that doesn't help. We all know that closing a ticket doesn't mean anything. There are many changing factors to consider. If I asked 10 different programmers what they think makes a good developer, I'm sure I would get 10 different answers. I believe you are also thinking about its definition now. I was struggling with this definition for a while, so I decided to try and figure it out. Focus on work I want to find some things that all developers do, and then I can classify developer performance based on how they do it. It’s too simplistic to base an excellent evaluation of an industry on just one thing, but I’m going to give it a try anyway.
All developers write junk code from time to time.Let’s face it, you and I write code from time to time that is so trashy and shameful that we never want anyone to see it. We all have our reasons for occasionally writing crappy code. I'm not going to get into the discussion of what the valid reasons are, because each of us has our own valid reasons. Before showing some coding atrocities, let’s review why we write crappy code. Then we can avoid getting stuck and struggling with code smells. Common reasons for writing junk code 1. Rushing for time "Not enough time" is currently the most common reason for writing junk code. Commitments to customers, tight schedules, and pending new releases may all be to blame. 2. Stuck in pain The existing code base is so garbage that you don’t even want to work hard to write good code. You know that no matter what you do, there is no way you can save this garbage code base that will collapse at some point. 3. “I just finish the task and leave” As developers, we sometimes work on different project teams. If you have to move to a new project after writing the last few lines of code, this is not a big deal that affects others. Know that your time on this project is coming to an end and no one will review your code anymore. So you just commit, push, and then rely on unit tests to make sure there are no problems. Look at the truthWe all write garbage code occasionally. Does this mean we are all bad developers? Of course not. Just because everyone writes bad code from time to time, that alone doesn't mean anything. However, over the years, I have gradually discovered a surprising truth about developers.
How we behave after writing junk code is a fundamental test of our developer qualifications.It’s a bit unbelievable, but it’s true. The awareness that you are writing garbage code and the actions you take to prevent it from happening again in the future are a reflection of how you write code and how you approach writing code in general. How much does junk code have to do with evaluating the excellence of developers? It has a lot to do with it. Let’s take Ron as an example. Ron wrote bad code today and was unhappy about it. Because of a nasty five-level-deep Backbone model inheritance chain, Ron couldn't change a single line of code without breaking everything.
Ron wrote a piece of super rubbish code to bypass this problem. Everyone was happy because Ron delivered the code on time. Except Ron himself.
He told the team boss what happened. Together they ruminated on how to solve the problem. They made it clear that breaking the inheritance chain and dividing it into horizontal composable modules was the best solution.
Ron then asked his boss to give him time to implement the reconstruction plan he and his boss had just discussed.
Roger also wrote terrible code today. He told his fellow developers that he had used an incredible hack to bypass a strange five-level deep Backbone model inheritance chain. He was prepared to go around the entire structure and just deliver on time.
Roger himself was very satisfied and felt that there was no need for further improvement.
You can divide programmers into four categories, from poor to excellent, based on their attitude towards writing garbage code.
Tell me you haven’t met all four types of developers at the same time.
Barney doesn’t care that he is writing crappy code. All he cares about is getting the job done on time; nothing else matters. If the code runs normally, there will be no problem.
The garbage code written by Barney sometimes hinders the progress of the entire project. When working on code, it will always bring about many problems, which will set back the progress of the entire project. Barney, on the other hand, doesn't think he needs to learn anything new.
He already knows everything he needs to know about JavaScript to get the job done.
Bill doesn’t realize that he is writing garbage code. He followed the team's agreement and lint rules and thought there was nothing wrong with what he did. But he didn't take the time to understand the entire project structure and how the different components interacted with each other.
The final result is, unfortunately, chaos.
Bill didn’t consult anyone before making major design choices. He does whatever he thinks. He read three blog posts from a year ago that were guiding his decision.
I often say that walking into Bill's code feels like mine warfare. One wrong move and everything blows up in your face.
We mentioned the type of Roger before. Be fully aware that you are writing garbage code. He knows what the code would look like if he wanted to write it well. He patted himself on the back and continued writing this crap.
Roger’s main problem is that he didn’t try to make some changes. He did what he was asked to do and he did it well. But he would rather let things be the way they are than take the time and effort to make them change.
Ron is an excellent programmer, but occasionally he still has to write some garbage code.
What makes Ron different from others is that when he writes that garbage code, he will seriously think about how to prevent this situation from happening again, neither for himself nor for anyone else. Ron will figure out what type of refactoring is needed and which technical solutions can be changed or improved.
Then, based on these findings, Ron will take action to promote these changes.
I must confess. I'm Roger here. But I'm Ron too. I also believe that I have accidentally been Bill more than once without knowing it. I don’t think I’ve lived like Barney, but who knows? We all go back and forth on the road to lasting excellence. Sometimes we are ordinary, sometimes we are good or excellent. Always trying not to be bad.
The role we end up lasting the longest will determine what kind of developer we are.
To be honest, going from an ordinary developer to a good developer requires the accumulation of more knowledge and experience than other things. But to make the leap from good to great, you only need to change one thing—your attitude.
“Remember, before you can be great, you must be good. Before you can be good, you must be bad. But before you can be bad, you must try. - Art Williams
The above is the difference between JavaScript developers with different levels of excellence. For more related content, please pay attention to the PHP Chinese website (www.php.cn)
##!
#
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
