Six criteria to determine whether you are a professional programmer or not. If you can't do it, leave.

1. Before you blame others, check your own code

Think about your own assumptions and the assumptions of others first. Tools from different vendors may have different assumptions built into them, and even different tools from the same vendor may have different assumptions.

When someone else is reporting a problem you can't replicate, look at what they are doing. They might be doing something you haven't thought of, or they might be doing things in a very different order than you are.

My personal rule is that if I have a bug I'm not sure about, I'll first consider the compiler, then check for stack corruption. This is especially true if adding tracing code will make the problem move. Multithreading issues are another source of bugs that can be so frustrating that you want to pull your hair out or just throw your computer. When the system is multithreaded, it's best to prefer simple code. We can't rely on debugging and unit testing to find any consistent bugs, so simplicity of design is the most important thing.

So, before you blindly blame the compiler, consider this advice from Sherlock Holmes: "Once you have eliminated the impossible, whatever remains, no matter how implausible, must be the truth."

2. Keep learning

We live in interesting times. As software development spreads around the world, you will find that there are many people who can do your job. So you need to keep learning to stay competitive. Otherwise, you will fall behind and stagnate until one day, this job is no longer needed for you or outsourced to some cheaper labor.

So what can we do? Some employers are generous and will provide training to broaden your skills. Others will say I don’t have the time or funds to receive any training. So the key is to have the right mindset and learn as a responsibility to yourself.

Here are some ways to learn. And many resources are available for free on the Internet:

• Read books, magazines, blogs, Twitter feeds, and websites. If you want to learn more about the object, consider adding it to a mailing list or newsgroup.
• If you really want to learn a certain technology, then write code yourself.
• Try to work with a mentor. While you can learn something from anyone, you can learn more from someone who is smarter or more experienced than you. If you can't find such a mentor, then read on.
• Use virtual mentors. Find authors and developers on the web that you really like and read what they write. Subscribe to their blogs.
• Understand the frameworks and libraries you use. Knowing how things work helps you apply them better. If you are using open source, you are really lucky. Use a debugger to step through the code to see what is going on inside. You can also go and see how people who are indeed smarter than you write and review the code.
• When you make a mistake, fix a bug, or run into a problem, try to really understand what happened. Chances are someone else has already run into the same problem and posted about it online. Googling can be really helpful.
• Another great way to learn is through teaching. When others listen to you and ask you questions, you will also learn. Create user groups or local conferences.
• Join or start a research group (pattern community) for the language and technology you are interested in, or create a local user group.
• Attend a conference. If you can't go, you can watch it online, and many conferences post their talks online for free.
• Listen to podcasts.
• Ever run a static analysis tool on your codebase, or looked at your IDE warnings? Understand what they report, and why.

Of course, if you have superpowers like Neo in "The Matrix", all of this would be a piece of cake for you. But unfortunately, we are all ordinary people. We need time, energy, and constant efforts to motivate ourselves to keep learning. However, you don't have to study all day long. As long as you can consciously spend some time to study, even if it's just one hour a day, it's better than nothing. People don't live to work, you should also have your own life.

3. Don’t be afraid to break things

Every programmer with industry experience has worked on a project where the code base is in tatters. The system is terrible, and changing one side always breaks unrelated functionality on the other side. Every time a module is added, the programmer can only think about changing the code as little as possible, and every release is daunting. This skyscraper of software could collapse at any time. The reason why changing the code is so painful is that the system is so terrible. But even if you know that the system is broken, you have to let it go because you are afraid to do it. Any surgeon knows that if a wound is to heal, it must be cut away. Although surgery is painful, it is definitely better than letting the wound become inflamed and fester.

Don't be afraid of your code. No one cares if you temporarily break something while you're fiddling with it. As long as the changes you make don't put the project back to square one, it won't break anyone. Investing time in refactoring will benefit you throughout the life of the project. As an added benefit, you'll have a pretty good idea of ​​how it should work because you've had experience with a dying system. Apply that knowledge, don't be disgusted by it. Redefine internal interfaces, refactor modules, refactor copy-paste code, and simplify your design by reducing dependencies. You can significantly reduce the complexity of your code by eliminating special cases, which are often caused by the wrong coupling characteristics. Slowly transition from the old structure to the new one, testing along the way. If you try to do a big refactor all at once, you'll often consider giving up halfway because of the frequent problems.

4. Professional Programmer

One of the most important characteristics of a professional programmer is responsibility. A professional programmer takes responsibility for their career, budget, schedule commitments, mistakes, and skills. A professional programmer does not pass the buck to others.

If you are a professional, you need to take responsibility for your own career. You have a responsibility to read and learn. You have a responsibility to keep up with the latest industries and technologies. But many programmers think that this should be their employer's job. No, it's wrong. Think about doctors? Think about lawyers? They all train and educate themselves. They spend most of their off-get off work time reading magazines and newspapers. They keep an eye on the latest news. So should we. The relationship between you and your employer has been detailed in the employment contract. In short, your employer promises to pay you, and you promise to do a good job.

Professional programmers take responsibility for the code they write. They won't release code unless they know it works. Now, think about this: If it were you, would you release code without a thorough understanding of it? Professional programmers don't want QA to find any bugs, because the code is released only after he has tested it. Of course, QA will still find some problems, because no one is perfect. But as professional programmers, our attitude should be to make sure that QA can't find any defects.

Professional programmers are also good team players. They take responsibility for the output of the entire team, not just their own work. They are helpful, good at learning from each other, and will even help out when needed, and continue to work hard for the project.

5. Make full use of code analysis tools

The value of testing is instilled in software developers from the early stages of programming. In recent years, the rise of unit testing, test-driven development, and agile methodologies have proven that we are beginning to focus on testing at all stages of the development cycle. However, testing is just one of many tools you can use to improve the quality of your code.

Back when C was new, CPU time and storage of any kind were at a premium. The first C compilers noticed this and chose to reduce the number of passes through the code by removing some semantic analysis. This meant that at compile time, the compiler would only detect a small fraction of the bugs that could be detected. To remedy this, Stephen Johnson wrote a tool called lint - which would remove the crap out of your code - and thus implement some of the static analysis features that had been removed by its fellow C compilers. However, static analysis tools are now known for giving a wide range of false positive warnings and warnings about unnecessary static stylistic conventions.

Languages, compilers, and static analysis tools are designed very differently now than they were in the past. As memory and CPU time have become relatively cheap, compilers can afford to check for more errors. Almost every language has at least one tool that checks for style guide violations, common problems, and sneaky, sometimes hard-to-catch errors like potential dereferences of null pointers. More advanced tools, like Splint for C and pylint for Python, are configurable, meaning you can tell the tool which errors and warnings to ignore, either via command-line switches or in your IDE using a configuration file. Splint even lets you annotate your code in comments to give you better hints about how your program works.

6. Care about the code

Good programmers write good code, that's for sure. Bad programmers... don't (they can write good code, so they're not bad programmers, haha). They always create monsters that others have to destroy. Your goal is to write good code, right? Then you should be a good programmer.

Good code doesn't just happen, or by chance. To get good code, you have to work on it. It's hard. But if you really care about your code, you'll get good code.

Technology alone does not make good programming. I have met some very smart programmers who can produce impressive algorithms and memorize language standards, but write the most terrible code. This kind of code is painful to read, painful to use, and even more painful to modify. I have also met some very humble programmers who stick to simple code, so the programs they write are more elegant and easier to express their meaning. They are a pleasure to work with.

Based on my years of experience producing software, I have come to the conclusion that the real difference between a bad programmer and a great programmer is: attitude. Good programming is about a professional approach and a desire to do your best to write the best software.

To be a good programmer, you must take responsibility for your code and really care about it - develop a positive attitude. Great code is crafted by masters, not written by sloppy programmers.

Translation link: http://www.codeceo.com/article/6-ways-professional-programmer.html
Original English text: 6 Ways to Become a Professional Programmer
Translated by: Coder.net – Xiaofeng