Some places in the work of the programmer that are not under your control in the ceiling work

In my opinion, programmers do pioneering work. The development of the Internet not only promoted the development of technology, but also brought the popularization of technology. Therefore, the programmer is not more than before, now to find a certain aspect of the information is very easy thing. Read a lot of information, a variety of novel technical solutions and solutions, not the heart that is impossible. OK, want to use a certain frame, want to use a certain technology, but, because of various reasons, no way to apply to their own development projects. This is a ceiling.

In the work often have a variety of ceilings, such as performance appraisal, project progress, interrupted thinking, technical framework. Because you are not the one to make the decision, so you have the ceiling.

Performance assessment

A lot of companies have performance appraisals, which in my opinion is a good starting point for performance appraisal, but it's a very nonsense thing to do. From the perspective of the company, it is necessary to ensure that every employee is working hard. Performance appraisal in writing is an incentive system, I feel more like a punitive measure. The first issue of performance appraisal is who will assess, in a team can not everyone to assess a person, and will not be assessed by ordinary staff, but the Director of the General Staff assessment. That could breed bureaucracy, inhibit initiative and innovation, and increase the chance of making mistakes. If, the staff's assessment is carried out by the supervisor, the employee does not have the voice right, the supervisor's character decides the team's operation Way. Who dares to comment if the supervisor is not very receptive? A team. Someone made a mistake, which supervisor dared to carry his responsibility? Because there is also a higher supervisor to the small supervisor assessment. There is absolutely no human touch between the teams, purely the way the machines operate.

In this case, everyone is working overtime, do you dare not work overtime? In this case, the supervisor can not hear, do you dare to point out the problem? In this case, do you dare to use new technology to innovate? In this case, do you dare to refactor the existing code? If you dare, you will have to bear the problem. All is not as good as the ground, with the existing things, out of the problem, is the problem, no problem is to goof. Therefore, the performance evaluation of the programmer's ceiling, suppressing the imagination and creative passion. Even if the development plan is certainly the easiest to aim at, and not to challenge anything.

In my opinion, performance appraisal is more appropriate in the case of no innovation, in software development, we face how to divide the workload, how to objectively assess the workload, there are some of the above mentioned problems. As we all know, this workload is difficult to determine, because of changes in requirements, and so on, even if the demand is not changed, the initial estimate of the amount of work can be completed on time in a few? It seems that many of the books say that many of the completed cycles are about 1.5 times times the estimated time.

I think there's only one situation where a programmer can be managed using a performance review, which means that you don't need a programmer to think about it and avoid all the risks in the software design phase. For example, waterfall model development, all things are determined, and then the programmer is only responsible for developing a method, no need to consider algorithmic problems, architectural problems. The programmer became a code worker. It is estimated that the programmer is not far from leaving the office.

Project Progress

Project progress should be emphasized. Although the project schedule also has some inhibition to the programmer's development, but it is not too obvious. Because the progress of the project itself is determined by himself. The progress of the project, while inhibiting innovation, strengthens the overall sense of the team. If a development of things, is B-dependent, that A and B will certainly maintain communication, and, a will have a certain responsibility for the progress of B. If a is a sense of responsibility, it will only give a sense of belonging to the team.

But if it was a one-month development task that would have to be compressed into a week, the team would breed new problems. One is shifting, one is team instability (job hopping).

The idea of being interrupted

The idea of being interrupted is a very annoying thing, if this happens frequently, it is a problem in the company's process. Only from the system, the process to avoid such things as far as possible.

Technology architecture

Many small companies do not actually have such a situation, because the technical framework is determined by the size of the engineer. In a larger company, architects architect the rules that programmers must follow. For example, you can't use MongoDB if you use MySQL. Some architects have designed a technical architecture that leaves room for developers to think about, and some architects have designed a technology architecture that completely kills developers. While the technical architecture guarantees business stability, procedural standardization, reusability, maintainability, extensibility ..... But for developers, that kind of architect is naturally self-evident.

In team management, pay attention to everyone, consider the development of each person, rather than erase their thinking. Generally speaking, the people in the team are the most important.

http://www.nowamagic.net/librarys/veda/detail/1737

Some places in the work of the programmer that are not under your control in the ceiling work (turn)