There is a saying that “one great programmer equals 10 mediocre programmers”.

No one wants to be labeled a bad programmer, but the sad truth is that many developers don’t realize they belong to this group. No one wants to ask themselves: Am I a bad developer?

Bad developers

If you’re new to programming and you’re worried that you’re writing bad code, chances are you’re not a master yet.

But don’t let that discourage you, because as long as you’re not hopeless, there’s always room for improvement.

First, let’s look at the two main types of bad developers:

  • Cowboys/coders (I’ll refer to this category collectively as cowboys for the sake of reading)

  • Mediocre developers

Essentially, the two are the same, but they often exhibit different behaviors.

Cowboy programmer

Cowboy programmers can ruin a team. They tend to work single-handedly on projects that are often short-lived.

Self-taught programmers who have never received any instruction on how to write usable code are often in danger of becoming cowboy programmers, and many good, experienced programmers can become cowboy programmers early in their coding careers.

So, what are the key attributes of a cowboy programmer?

1. Very fast coding speed

In general, this type of bad developer builds new features much faster than the average, but unfortunately, people who don’t know the code will think that these “fast shooters” are awesome (which only further increases the ego of these cowboy programmers).

This type of developer works best when he or she is working alone, and is best when the customer is particularly time-constrained and needs to implement functionality as quickly as possible.

Cowboy programmers code very fast — which means their code has no plan for maintainability. So this leads to…

2. Messy, unreadable code

Fast code designs often create projects that are messy (or, more accurately, they don’t code at all). This messy code is often referred to as “spaghetti code,” which refers to its shape, not its taste.

Spaghetti code is often a maintenance nightmare because it is difficult to understand and often unnecessarily large and complex, making it difficult for others to understand what the programmer is doing. This means that if someone is unlucky enough to work with a cowboy programmer, overall productivity will drop dramatically.

Messy code can lead to… Ali’s “Java development manual” suggests studying well below. You can also download the manual directly in the Java core technology background.

3. Bugs

If a company’s software becomes bigger and more complex and their code remains a pile of spaghetti, it becomes a time bomb waiting to explode. In the worst case, the consequences could even be as severe as unintended acceleration in Toyota vehicles. It’s no secret that Toyota recalls are a disaster.

More importantly, spaghetti code is not extensible. This means that if new features are added, the code is walking in a minefield — it will explode at any moment. This is usually because cowboy programmers mix every feature together, so any change can break the software. Better code design and/or unit testing might have prevented this, but cowboy programmers don’t care if their code is usable and don’t want to write tests (because it takes time).

What’s more, code is structured in a way that is derived from bad design decisions and is often untestable or even undebuggable. It’s also common for cowboy programmers to create more bugs as they quickly “fix” a few. So they always feel busy, like heroic firemen, tired of putting out fires everywhere.

In short, every bug and bug created by a bad developer is a productivity drain. Even when they start out looking great, they always finish coding tasks on time that other developers are afraid to promise, but this comes at the cost of all kinds of unexpected errors that could have been killed in the first place by the careful design and clean coding of a good developer.

If you spend more than 80% of your development time debugging your code and debugging is a nightmare (one bug is solved here and another comes out there), then your code base is bad and you need to improve your code.

arrogance

Some cowboy programmers are not bad because they produce spaghetti code based on impossible deadlines from management/customers (however, developers who value their code will leave such companies or turn down such customers).

Many beginners and junior developers produce a bunch of buggy code because they don’t have a coding plan, but sometimes they make bad decisions because they lack experience with the problem.

These beginners can be corrected by receiving guidance from a good, experienced developer. However, if they are surrounded by other developers who are just like them or mediocre, they can fall into the feel-good delusion.

As long as you’re willing to take responsibility for your mistakes, and as long as you’re willing to learn from them, then you’re not a bad developer.

The most important attribute that makes these programmers bad is arrogance.

Bad programmers think their code is perfect and blame the customer’s stupidity for the crash, rather than reflecting on why their software crashed. Cowboy programmers are often selfish developers because they have no sympathy for the other developers who have to “clean up” for them.

More importantly, these arrogant programmers always think their intelligence is superior to others, always think that people can’t do without comments, always think that people who don’t understand their code are stupid, but never wonder why people don’t understand their code. The result of this constant belief that they are right, that they are better than everyone else, is that they build features that can cause a lot of problems and problems for the team without proper communication. Others will sometimes even shy away from “best practices” or “standards” because they believe (without good reason) that their code is better.

Worst of all, bad programmers don’t want to be lectured and learn from their mistakes because they don’t admit they made a mistake and, as mentioned earlier, they often pass the buck.

Note that this doesn’t mean that cowboy programmers are difficult or low-iq people in real life — they might just be the most amiable people you’ll ever meet — but they do have a deep-seated arrogance and an unwillingness to accept responsibility for their mistakes when faced with criticism.

Mediocre developer

By mediocre, I mean “incompetent.”

In some ways, mediocre developers are worse than cowboy programmers because they know they can’t do it, but they don’t want to work hard and are content to stay at the bottom of the skill ladder.

Unlike cowboy programmers, mediocre developers usually have little interest in programming and therefore have difficulty understanding programming concepts. They take a long time to create something and the code they produce is poor and riddled with problems. They often have no passion/interest in coding, are slow to learn new technologies, or often have no hands-on experience.

Maybe mediocre developers not as destructive as cowboy programmer, this is because they are in a team, but they will not bring any benefit for the team, and they put forward the solution always inferior to excellent developers (because they often wrong decisions, leading to is full of bug/inefficient code).

I won’t say anything more about mediocre developers. At worst, they’ll be a drag on the team, and at best, they’ll barely meet the deadline.

The heart of the matter

At the heart of the “bad” throne is the lack of desire to be a better programmer. Bad programmers are happy and comfortable with their current behavior. To make matters worse, cowboy and mediocre programmers often think they know things they don’t.

More importantly, bad programmers are often not interested in learning new things and therefore don’t consciously improve themselves.

This is why a lot of copy-and-paste is often found in the code of bad programmers, because they rarely figure out why some parts of the code work and some parts don’t. Copy & paste is not a bad thing in and of itself, but only if:

  • You know what you’re doing (a lot of bad developers think they know what they’re doing)
  • Make sure the copy-and-paste code works
  • For testing/validation only

Bad developers often just copy and paste StackOverflow code instead of understanding it or tweaking the solution to match their own code.

In addition, programmers who consistently adhere to so-called “best practices” without understanding why those practices are considered “best” can also be classified as bad programmers.

In short, you probably don’t need to know every detail of how a large, complex framework works. However, you should at least figure out how the parts you use work.

Bad programmers never learn from their mistakes, either because they don’t admit they made them, or because they lack the desire to learn, or both.

Everyone makes mistakes. Every programmer makes bugs. It’s no big deal. However, if you keep making the same mistakes over and over again, that means you’re a bad developer who doesn’t learn.

Great developer

After rambling on about the characteristics associated with bad developers, you’ve probably got a vague idea of what makes a good developer. Good developers are the backbone of the development team, and they usually have the following characteristics.

Outside have some mountain man outside has a mountain of humility, is ready to assume responsibility for mistakes, learn from their mistakes, write the code is readable, structured and reliable through the design, can be easy to debug, trying to understand the working principle of things, and others in the team has a good communication/collaboration, accept criticism and open to different ways, Be willing to learn new skills, be willing to solve problems, etc.

True, it’s hard to measure what constitutes high-quality code (which is why I didn’t include it in the feature, but it’s an important aspect of what makes a developer “good”).

So how do we know if we’re writing good code? See the perfect explanation in the cartoon.

Really good developers

Here are two types of developers that really help your team:

  • MVP
  • Helpful developers

MVP

MVP developers don’t want to simply solve a problem, they want to find the best way to solve a problem. They rise to the challenge and therefore excel at difficult tasks — which is why MVPS are more productive than most developers. It is because of this adventurous attitude that employers may not be able to keep them if they are given a job that is too easy or too mediocre, because they may leave if they get bored.

Because MVP developers take pride in their work, they often quibble about quality and performance. In fact, they take a lot of edge situations into account and think about them before they happen. In some cases, they are their own QA engineers, checking their code before the user. They don’t blindly do TDD because of so-called “best practices,” but they do design programs that greatly reduce debugging time. Therefore, an MVP programmer is at least 10 times more productive than a bad programmer.

MVP developers are inquisitively curious and will stop at nothing to find out “why” things work or don’t work. They spend a lot of time reading about programming to keep up with new technology, but they don’t follow the crowd because they’re more interested in figuring out the root of the problem on their own. They love coding so much that they often do it in their spare time, tinkering with business projects, or trying out new technologies, tools, and languages.

Finally, MVPS are confident and humble because they always remember that in a company of three there is always a mentor, and they like to work with better people because they can learn from them.

conclusion

The most important factor in becoming a good, even great, developer is yourself.

Maybe it takes talent and a real innate passion to be a top programmer, but anyone can be a “good” programmer if they have an interest in programming.

If you don’t want to be a good programmer, then no one else will. You are your own worst enemy and adversary, and your goal should always be to become a better programmer than you are now.

By Yi-Jirr Chen jaxenter.com/everything-… Translation: www.codeceo.com/article/bad… Translation: Code farmer net – xiaofeng

Recent hot articles recommended:

1.1,000+ Java interview questions and answers (the latest version of 2021)

2. Finally got the IntelliJ IDEA activation code through the open source project, how sweet!

3. Ali Mock tool officially open source, kill all the Mock tools on the market!

4.Spring Cloud 2020.0.0 is officially released, a new and disruptive version!

5. “Java Development Manual (Songshan version)” the latest release, speed download!

Feel good, don’t forget to click “like” + forward oh!