No one believes in programmers

Http://www.cnblogs.com/okaimee/archive/2010/07/27/1785840.html

John Nance, a senior Flash/front-end engineer in the United States, published a article titled "Never trust a programmer", discussing one of the biggest challenges faced by many developers: how to negotiate project estimation with the customer or sales department in the company. The full text is as follows (the translation has been edited and revised by csdn ):

Programming is a bit mysterious to many people. This has led to many doubts and doubts about programming within the company. Generally, when you don't know how a thing is made, you can only say: Maybe so. If you have never met a construction site, you may think that a building can be built in a few weeks. In fact, this building can be completed in such a period of time, but I don't know if it can be used. If you have seen how a house is built and followed up on its construction process, you can see from physical objects how the foundation is watered, how the steel frame structure is built, and so on. However, writing a program for a computer or building a website is invisible.
Except programmers, program code is not accessible to others. The running of the program seems to be a magic trick behind the scenes. Only members of the development team can know what the program is, how it works, and what it cannot do. From the programmer's perspective, you can get the best development results, project evaluation data, and progress updates. Many a-type people disagree with this, but it is not that simple.
When the customer asks what they want and when to complete it, the problem begins. Sales personnel want to make the deal. Please tell the customer that their ideas are unrealistic and this business cannot be done. This can only lead to one disaster. I once saw the sales department cut the estimated construction period by half, and spent money everywhere to achieve their sales and complete their tasks. Until the last day, the development of things seems to be caused by the errors of programmers. They come to the conclusion that programmers are the easiest to blame.
Programmers have never studied office political science at school. They should learn. Of course this is another topic. As a programmer, he needs to concentrate and think calmly to develop clear and useful programs. This is a difficult task and you need to use all your energy. Programmers don't have time to figure out who gave themselves a knife. These tricks that can be played by the Sales Department have serious consequences.
My previous company, a one-million-dollar project, was very busy. Like fireworks, it was just a short time before it came to the ground. Why? Is this company instructing programmers to work more than 70 hours a week to complete the customer's arrogant schedule? Or is it because the sales department is listening to the customer?
I don't think developers have any responsibility. If you have watched the TV series seconds from disaster (csdn Editor note: a series of programs on the National Geographic Channel in the United States, which tells about various man-made and natural disasters), you will understand, disaster occurs because a group of people do not do what they should do. However, I can see that programmers are doing their jobs. What are other people doing?
So what does the company think? They fired or fired all programmers. However, the entire sales department is okay. No one wants to stay there after this fiasco's death.
The process of getting programmers into Hell is paved with "Obedience. In order to be able to live up to themselves and to live up to their careers, programmers should be vigilant against dangerous things. The evaluation analysis usually takes a lot of effort. As far as I know, this is more difficult than anything else. It requires you to consider the whole thing from multiple levels. Unfortunately, I have personally experienced rejection or modification of excellent assessment reports. The more practical the evaluation is, the more people will discuss it.
It is difficult to tell users the expected reports. This will make the transaction more difficult. Programmers are taking the risk of others. It is never easy for programmers to work. As a matter of fact, programmers are the people in the company who are most aware of this issue. They understand coding and need business. They may not be good at dealing with customers, but they actually know what the project should do.
Attach importance to your programmers. They are not only skilled workers, but also business-oriented. Based on their own experience, they can determine who is exaggerating to retain customers.

In fact, people who have been working in this industry for a period of time will feel similar. Compared with sales personnel, most programmers have less contact with the society and are far from practicing like sales personnel. They are often not strong enough and kind enough, they are not active enough to deal with some things. They put too much energy and time into their program world. But should they do this?

I have encountered similar problems more than once in my work. After each incident, I will feel that I was not doing well at the time. However, the next attempt to make the same mistake is inevitable. It may be caused by nature, but it may not be enough, but it must be a bad excuse. Competition is everywhere. Obviously, I have not been able to express myself well in the competition. I know that I have to change some of my ideas and practices, but this is indeed not an easy task.

One of the most important factors is that the boss does not really understand programming, and the sales staff does. Specifically, they do not have any basic concepts about how a project is developed, therefore, they do not know how difficult the implementation of this project is, and how many people and months are required. This cannot blame the boss and sales staff. After all, they have issues they need to consider. However, this directly leads to barriers to communication. How to let a programmer who does not fully understand programming understand the resources required for developing a project may be the capabilities required by every programmer.

Another important factor is that the positions of the boss, sales, and development are not so completely consistent, so conflicts are always inevitable, it is necessary not only to be responsible for the programmer, but also to the sales and boss. But how can we express and operate the original intention so that we can get the proved effect instead of making trouble for ourselves? This is a problem.

I cannot give a good answer to the above questions. Maybe I have little experience in practice and really want to listen to the teachings of my predecessors. I think the core of solving the problem should be trust. mutual trust among the three may be the only way to solve the problem. However, how can we establish trust? Especially as a female programmer, it is not easy to gain trust.

I know that it is not easy to do any kind of job, and I also hope that I can continue to do it in this industry. Therefore, we must make ourselves better. This is not just about technology, at the same time, it is also in the lives of people and the survival of competition.

No one wants to be eliminated.

It is hoped that all the brothers and sisters in the industry will be able to benefit smoothly on their own roads.