5 programming fallacies to know before starting a business (GO)

1. Code is important(The relationship between functionality and code quality.) Should be functional to meet the case, the code quality also needs to be improved if recommended 3, 4)

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 realization, not the idea (long time, it does not matter the overall situation of the product, to do their own job is good, do the non-responsibility of things, will bring a lot of invisible contradictions).

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, spending a lot of time to create a variety of functions or fix bugs, I believe that a single function can 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 is better to have a good idea but not to do it well than to achieve a bad idea perfectly.  
Lessons: If you add a feature that fixes 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 wonder why this error is 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 hurdles to improving the team's efficiency is communication-it's not exaggerating, and the team is dealing with O (N2) issues. 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.  

Many times, I've seen programmers spend hours working tirelessly writing code, but omitting 10 minutes to update the code document. 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.  

Lessons Learned: 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 hard. 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: When you finish writing the first version, it 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   (likes)

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

 

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 views, please feel free to enlighten me.  

English from: Five Things I knew about programming before I did a startup 

http://www.iteye.com/news/30294

5 programming fallacies to know before starting a business (go)