5 programming myths you need to know before starting a business

I am a programmer. I started coding on an ancient Commodore 64 when I was still knee high. To this day, nothing fascinates me more than putting on headphones and hacking something. So when I started my first business, I already knew a lot about programming. Is it a fallacy? Let me explain it one by one:

Jiro scoffs at your code. It's a common phenomenon that early code looks like it was written by a bunch of drunk programmers. This may seem counterintuitive, but that's because you have to do your best to grow your business, so you don't have time to pursue software perfection. On the other hand, failed companies spend many, many hours fixing their code base.

For example: if you are a sushi chef. As part of your job, you collect a set of out-of-print knives. You spend time and effort completing collections, and they enhance your competitiveness as a chef.

But no matter how much time you spend every day polishing your props, you are not a blacksmith. Your job is still to make sushi. You may have the best knives in the world, but if you can't make sushi, your customer service will be bad. Your restaurant business will never be successful.

The same is true for software. When you run a company, your business purpose is to satisfy your customers. Code is just a tool to achieve a goal, it is not an end in itself. You can and should take care of your code because it helps improve customer service. However, if you mistake the tool for the goal, you are doomed to failure.

Lesson learned: Your customers don’t care about test coverage, technology stack, version control system, or what algorithms you use. Your job is to solve your customers' problems, and the more convenient it is, the better.

2.

…focus on implementation, not ideas.

This may sound like it goes against the traditional startup instructions: launch fast! implement! Iterate! Execution, no creativity required! Fail fast!

The above is all great advice. But just because “no creativity is required” doesn’t mean we can correct a bad idea through superior execution. Success is finding a good problem and then solving it properly. Therefore, it is not possible to have a good idea but not implement it well or to implement a bad idea perfectly. Of course, the former can still be saved.

Many programmers are trapped in the death spiral of implementation and spend a lot of time creating various functions or fixing

bugs

, believing that adding one more function will succeed. I tell you, this is an illusion. You only need to solve an important problem, otherwise it makes no sense to keep adding features to the product, unless the features you add can really solve the need.

It is better to have a good idea but not implement it well than to have a bad idea that is perfectly implemented.

Lesson learned: If you’re adding functionality to fix a failing product, it’s best to ask yourself if it actually solves the problem.

3.

...The code is written for the computer

I always can't figure out why this error is so persistent. No matter how many times a programmer gets into trouble because of a coworker's poor documentation and communication habits, the conclusion they often draw is that programmers are inherently bad at these kinds of things and shouldn't do them.

What a big mistake.

If you are part of a team, then one of the biggest obstacles to improving team efficiency is communication - this is not an exaggeration, the team faces an

O(n2)

problem. If code is your primary output, then you need to change the way you think about programming: code is written for people to read, and then happens to run on a computer.

Many times, I see programmers spending hours writing code tirelessly, but omit the ten minutes spent updating code documentation. This is because they think: "There is no need to kill a chicken with a butcher's knife. This kind of thing can be left to future generations. My time is precious." In a sense, their ideas are extremely absurd.

Lesson learned: Code is written for people to read. Don't write code without documentation.

4.

…This is the last step of coding.

Do you think that once you write this feature and put it into production, you are done? wrong. Every function has a life cycle. The code you write today, if successful, will be used by generations of programmers after you. Maybe, just to take care of the code you wrote today, you have to form a team.

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

The key to solving problems is to have a sense of crisis: writing the first version does not mean the end of the code. Be sure to do a good job in documentation, annotation, organization, etc.

Lessons learned: Don’t do to others what you don’t want others to do to you.

5. …A programmer’s job is to write code

Most programmers think that the best way to use their time is to sit in front of the computer, put on headphones and type code. But if every line of code you write must be maintained and supported throughout the product's lifecycle, the algorithm is different again.

The only believable moment in this film.

When you write code because of your hobby, then you can do whatever you want and do whatever you like. But if you're working on a team to build a product, your first obligation becomes maintaining the existing code. Other important tasks are: coordination, communication, planning and guidance.

Lesson Learned: A programmer’s job is to solve problems. It doesn’t always mean writing code.

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

Sometimes, you may think: This sounds like a product manager’s job, not a programmer’s. But if you’re getting paid to write code—especially in a startup—then think of yourself as a product manager. If you also want your product to be successful, it's crucial to think about the big picture. This is not only good for your startup, but also for your future career development.

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

Get freeLAMPBrothersOriginalPHPVideoVideo TutorialCD/《 DetailsPHP》 Essential version, please contact the official website customer service for details:

http://www.lampbrother.net

PHPCMSSecondary developmenthttp://yun.itxdl.cn/online/phpcms/index. php?u=5

WeChat development                                                                                  .itxdl.cn/online/server/index.php?u=5

JavascriptCourse

http://yun.itxdl.cn/online/js/index.php?u=5

CTOTraining Camp

           http://yun.itxdl.cn/online/cto/index.php?u=5

The above introduces 5 programming fallacies that you need to know before starting a business, including the relevant content. I hope it will be helpful to friends who are interested in PHP tutorials.