5 Programming myths to know before starting a business

I am a Programmer . When I was so high on my knees, I started using an old one. Commodore write the code. Until today, there is nothing more fascinating than putting on headphones and cracking things. So when I started my first business, I knew a lot about programming. is not a fallacy, and listen to my following one by one way:

Jiro scoffs at your code.

1. Code is important

I've worked in a lot of places and found that there's a common phenomenon in success: Early code looks like a bunch of program apes wrote after they got drunk. This may sound counterintuitive, because you have to do your best to grow your business, so there is no time to pursue the perfect software. On the other hand, failed businesses spend a lot of time correcting their code base.

For example: If you are a sushi chef. As part of your job, you've collected a set of out-of-print knives. You spend time and energy to complete your collection, and they enhance your competitiveness as a chef.

But no matter how much time you use every day to polish your props, you are not a blacksmith. Your job is still the sushi division. You have the best knives in the world, but if you do not make sushi, then your customer service is a bad comment. Your restaurant business will never be successful.

The same applies to software. When you run a company, your business is aimed at satisfying customers. Code is just a tool that can achieve its purpose, and it is not an end in itself. You can, and should, care about your code, because it can help improve customer service. However, if you mistake the tool as a goal, you will be doomed to a crushing defeat.

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

2 ... .. Focus on the implementation, not the idea.

This sounds like a violation of the traditional entrepreneurial notes: Quick release! Perform! Iterate! Execute, no need to be creative! Fast failure!

These are all great advice. However, "No need for creativity" does not mean that we can rectify a bad idea through excellent execution. Success is finding good problems and solving them well. So, the idea is good but not well achieved or the perfect realization of a bad idea, are not, of course, the former is also saved.

Many programmers are trapped in the death vortex that takes a lot of time to create various functions or fix Bug , I believe that adding a function will be successful. I tell you, it's an illusion. You just have to solve an important problem, otherwise it doesn't make sense for you to add functionality to the product at all, unless the functionality you add does solve the need.

It's better to have a good idea but not to do it well than to achieve a bad idea perfectly.

Lesson: If you add a feature to fix a failed product, it's a good idea to ask yourself if this really solves the problem.

3 ..... The code is written to the computer

I always wondered why this mistake would be so enduring. No matter how many times programmers get into trouble because of their coworkers ' bad documents and communication habits, they often come to the conclusion that programmers are inherently not good at such things, and should not do it.

It's a big mistake.

If you're part of a team, one of the biggest obstacles to improving the team's efficiency is communication-it's not exaggerating, the team is facing O (n2) problem. If the code is your primary output, then you need to change your view of programming: The code is written to people, and then it's just going to run on the computer.

Most of the time, I saw the programmer spend a few hours writing the code tirelessly, but omitted to update the code document for 10 minutes. This is because they think: "Kill chicken with slaughter sledgehammer, this kind of thing left to the future people on the line, my time is precious." "In a sense, their ideas are absurd.

Lesson: Code is written for people to read. Do not write code without documentation.

4 ... .. This is the last step in code writing.

Do you think that once you've finished this function and put in the product, you're done? Wrong. Each function has a life cycle. The code you write today, if successful, will be the next generation of your multi-generational programmer. Maybe, just to take care of the code you wrote today, and have to set up a team.

Think about it. If your job is to take care of code written by someone else, would you like to?

The key to solving the problem is to have a crisis meaning: writing the first version doesn't mean the end of the code. Be sure to do a good job of documenting, annotating, and collating.

Lessons learned: Do unto others, come back haunting.

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

Most programmers think that the best way to use time is to sit in front of a computer and put on a headset and hit code. However, if every line of code you write must maintain and support the entire product lifecycle, then the algorithm will be different.

The only believable moment in this film.

When you write code because you love it, you can do whatever you want and do whatever you like. But if you are producing products in a team, then your primary obligation becomes to maintain the existing code. Other important tasks are: coordination, communication, planning and mentoring.

Lessons learned: The programmer's job is to solve the problem. The code is not always written.

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

Sometimes, you might think: it sounds like a product manager's job, not a programmer's. But if you're getting paid for code--especially in startups--think of yourself as a product manager. If you want your product to be successful, it's important to start with the big picture. Not only does this help your startup, it's also good for your future career development.

Finally, if you have any different opinions, please do not hesitate to enlighten me.

Free pick up LAMP Brother Lian Original PHP Visual frequency Tutorial CD / the About PHP "Essentials Edition, details of the consultation website customer service:

Http://www.lampbrother.net

Phpcms Two-time development http://yun.itxdl.cn/online/phpcms/index.php?u=5

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

Mobile Internet server-side development http://yun.itxdl.cn/online/server/index.php?u=5

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

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

The above describes the pre-business need to know the 5 programming fallacies, including the aspects of the content, I hope that the PHP tutorial interested in a friend helpful.

