Five essential programming misconceptions for developers

Five essential programming misconceptions for developers

I have read an article about developers' misunderstandings, and I think it is good, just like sharing it with you. I hope it will help you.

I am a hacker. I started to write code with an old Commodore 64 when I was so tall. Today, there is nothing more fascinating than wearing headphones to crack things. So when I created my first enterprise, I knew a lot about programming. Is it true? Let me hear one by one:

1. code is very important

I have worked in many places and found that success hides such a common phenomenon: Early code looks like a bunch of programmers written when they get drunk. This seems to be against common sense, because you have to do your best to make your business grow, so you don't have time to pursue software perfection. On the other hand, failed enterprises spend a lot of time revising their code libraries.

For example, if you are a sushi master. As part of your work, you have collected an out-of-print tool. You spend time completing favorites, improving your competitiveness as a chef.

However, no matter how much time you spend polishing your items every day, you are not a blacksmith. Your job is still making sushi. Although you have the best tool in the world, if you cannot make sushi, your customer service will be a negative comment. Your restaurant business will never succeed.

The same is true for software. When you operate a company, your business goals are to meet the customer's needs. Code is just a tool that can achieve the goal. It is not an aim. You can and should be concerned about your code, because it can help improve customer service. However, if the tool is regarded as the target by mistake, you are doomed to be defeated.

Lessons learned: Your customers do not care about test coverage, technology stacks, version control systems, or algorithms you use. Your job is to solve customer problems, the more convenient the better.

2. Focus on implementation, not on ideas.

This seems to be against the traditional entrepreneurial notice: Quick release! Run! Iteration! Execution. No idea is required! Quick failure!

These are all great suggestions. However, "no idea is required" does not mean that we can correct a bad idea through superior execution. Success is to find a good problem and solve it well. Therefore, it is impossible to achieve a good idea but not a good one or a perfect one. Of course, the former is still saved.

Many programmers have spent a lot of time creating various functions or fixing bugs in the dead vortex of implementation. I believe that a new function will be successful. I tell you, this is an illusion. You only need to solve an important problem. Otherwise, it is meaningless for you to constantly add features to the product, unless the features you add can solve the problem.

A good idea is better than a bad one.

Lessons learned: if you add a function to fix a failed product, you 'd better first ask yourself if the problem can be solved.

3. The code is written to the computer.

I always cannot figure out why this error is so persistent. No matter how many times programmers are in trouble because of their colleagues' bad documentation and Communication habits, the conclusions they come up with are often: programmers are naturally not good at such things, we should not do these things either.

A big mistake.

If you are a part of a team, the biggest obstacle to improving team efficiency is communication-this is not an exaggeration, and the team is facing the O (n2) issue. If the code is your main output, you need to change your views on programming: the code is written to people, and then runs on the computer.

Many times, I have seen Programmers spend a few hours writing code, but I have omitted 10 minutes to update the code documentation. This is because they think: "It's just a matter of time for people who will be able to kill the chicken and use a cow ." In a sense, their ideas are ridiculous.

Lessons: the code is written to people. Do not write code without documentation.

4. This is the last step in code writing.

Do you think that once you write this function and invest in products, it will be a success? Wrong. Each function has a lifecycle. If the code you wrote today succeeds, it will be awesome among your many-generation programmers. Maybe, you have to set up a team to take care of the code you wrote today.

Think about it. If your job is to take care of the code written by others, do you want?

The key to solving the problem is to have a crisis: writing the first version does not mean the completion of the Code. Make sure that documents, comments, and organization are well prepared.

Lessons learned: do not do what you want.

5. A programmer's job is to write code.

Most Programmers think that the best way to take advantage of time is to sit in front of a computer and put on headphones to knock on the code. However, if each line of code you write must maintain and support the entire product lifecycle, then the algorithm is different.

When you are writing code, you can do whatever you like. However, if you are producing products in a team, your primary obligation is to maintain the existing code. Other important tasks include coordination, communication, planning, and guidance.

Lessons learned: programmers work to solve problems. It does not always mean writing code.

You are not only a programmer, but also a product manager.

Sometimes, you may think: It sounds like the work of a product manager, not a programmer. However, if you get the code-writing salary, especially for start-ups, consider yourself a product manager. If you want the product to succeed, it is crucial to start from the overall situation. This will not only benefit your start-up, but also benefit your future career development.

Finally, if you have any different opinions, please feel free to give us some advice.

Recommended reading:

Are you a low-paying programmer?

Big Data tells you how programmers increase their salaries

Programmer: 8 development skills help you increase your salary to the next level

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.