[Introspection] Top 10 technical troubles of programmers

Http://developer.51cto.com/art/201005/202715.htm

51cto has previously introduced ten essential skills for programmers as well as five major reasons that impede the growth of programmers. Let's take a look at this today.ProgramEmployee troubles. Every programmer has his own worries. Whether it refers to scope creep or Hungarian notation, this is a specific annoyance in our industry. Next we will talk about ten things that upset programmers.

10. Note-I only explained "how", but not "why"

Entry-level programming courses are usually designed to educate studentsCodeWrite comments first, and try to add as many comments as possible. The starting point of this education is "more comments must be better than less comments, and less comments must be better than less comments ". Unfortunately, many programmers regard this as a task and comment out each line of code.

  
  


   
   
R = n/2; // Let R be equal to n divided by 2

   
   
 

   
   
// Loop when r-(N/R) is greater than T

   
   
While (ABS (R-(N/R)> T ){

   
   
R = 0.5 * (R + (n/R); // set R to half of R + (n/R ).

   
   
}

  
  
 

After such a comment, do you understand what the code is? Indeed, I don't understand either. The problem is that although there are a lot of comments, they only describe what the code is, but do not explain why the code is written like this.

Now, let's take a look at the annotations for the same piece of code in another way:

  
  


   
   
// Use Newton-RaphsonAlgorithmReturns the approximate square root of N.

   
   
 

   
   
R = n/2;

   
   
While (ABS (R-(N/R)> T ){

   
   
R = 0.5 * (R + (n/R ));

   
   
}

  
  
 

This is much better! Maybe we still cannot fully understand the role of this code, but at least there is a certain direction.

Annotations are used to help readers understand the code, not to explain the syntax. I can boldly think that the reader understands the working principle of the for loop, so there is no need to write such a comment: "// perform the for loop operation on the customer list ". What readers do not understand is what your code is for and why you need to implement it in this way.

9. Interference

Few programmers switch from an activity to a programming state in the twinkling of an eye. In general, we are more like a train that needs to be started slowly, rather than a Ferrari that can be suddenly accelerated; we need a certain amount of time to enter the working state, once we enter a stable and effective working state, our work will be fruitful. Unfortunately, when your thinking is constantly interrupted by customers, managers, and your colleagues, it is hard for your brain to enter the programming state.

When we do one thing, there are too many things that need to be put in our hearts. We need to put this thing down first, deal with that person's things, and do it again later. There is no mistake yet. These disturbances will interrupt our thinking, and it will take a lot of time for you to reorganize the ideas. This is annoying, and there is no more frustrating and frustrating process than this.

8. Scope creep)

Scope creep (also known as Focus creep), requirecreep, feature creep, and other messy evolutionary words ), changes in project requirements are out of control in project management. This problem occurs when the scope of a project is not clearly defined, documented, or uncontrolled. This is generally considered a negative impact and should be avoided as much as possible.

Scope creep usually turns a simple requirement into a complicated, astonishing, time-consuming giant. Those who are in charge of demand research can make things like this by typing a few innocent keyboards:

◆ Version 1: display the map of this region

◆ Version 2: display the map of this region. It must be three-dimensional.

◆ Version 3: displays a map of this region in three dimensions and can be used as a flight navigation chart.

A task that can be completed in 30 minutes has become a super complex system that can be completed by several hundred people/day. What's worse, in most cases, demand changes occur in the development phase. In this way, you need to rewrite the code and re-return it. Sometimes you need to delete the code that was developed a few days ago.

7. Managers-do not understand programming at all

Management is not a simple task. People are a type of annoying animal. We think we are the best in the world because we are changeable and moody. To make such a group of people feel satisfied and united, you need to make the same effort as the mountains. However, this does not mean that managers can manage their subordinates without understanding their work. When a manager does not have any knowledge about our work, the consequence will only be frequent changes in demand, unrealistic schedules, and general frustration (managers and developers ). Programmers complain widely about this, which is also the root cause of disputes.

6. Write documents

Before talking about this entry, I admit that we do have many document generation tools, but in my experience, these tools are only suitable for generating API documents for reference by other programmers. If the software you develop is usually used by people every day, you must write document manuals that can be understood by outsiders (such as your implementation and customer service.

We can easily see that programmers are reluctant to do some things. You can briefly review all open source projects. What are the indomitable demands for these projects: documents.
I can say that at least half of programmers, no matter where they are, will say, "cannot let others write? ".

5. Program-missing documents

I have never said that our programmers mean one set of people. Programmers often use third-party class libraries and applications in their projects. Therefore, we need documents. Unfortunately, as I mentioned in Article 6th, programmers hate writing documents. This dramatic thing happened to ourselves.

When you need to use a third-party class library, you find that at least half of the APIS do not know what to do, and nothing is worse than this. What is the difference between the function poorlynamedfunctiona () and the function poorlybutsimilarlynamedfunctionb? Do I need to test whether the propertyx attribute is null before I use it? I guess it can be figured out only through my own tests and errors !.

4. Hardware

Any programmer who has been called to debug a strange downtime on a database server, or to solve the problem that raid drives cannot work properly, when a hardware problem is discovered, it will be painful. There is a common misunderstanding that programmers are computers and they must know how to repair them. It is undeniable that some programmers are indeed all talented, but I guess most programmers do not know, or do not care how the program works after being compiled into machine code. We only care about whether the work is in line with the requirement document, so that we can concentrate on solving this upper-layer task.

3. Ambiguity

"The website is down". "The XX function is not working properly ". Processing ambiguous tasks is a pain. Every time non-programmers are asked to reproduce their problems, I am amazed at the anger. They don't seem to understand. They just say, "It's down, fix it !" We cannot get started. We need more information.

Software running is (in most cases) traceable. We also like this. Please let us know at what stage and under what circumstances, rather than simply saying "fix it".

2. Other programmers

Programmers often cannot work with other programmers. Surprised, But this is true. In this regard, I can easily list the top ten articles, elaborate on the points, or even write a blog separately. So here I only list the features of common programmers who upset other colleagues:

◆ Grumpy and unfriendly attitude.

◆ I cannot understand when to discuss the system architecture and when to do it.

◆ Effective communication is not possible and easy to misunderstand professional terms are used.

◆ Your own affairs are not well handled.

◆ Lack of interest in programs and projects to be implemented.

So, this last, but not the worst, number 1 makes programmers worry...

1. Self-written code-6 Months Later

Don't sneeze, I think I see a bug.

Looking back at the code I have previously written, will it be sad? Why was it so stupid! How can I compile something like this! Burn it! Throw it to the fire!

The reality is that the software technology field is a changing world. Today is seen as the best way, and tomorrow may be outdated. We cannot write perfect code, because the criteria for judging the quality of our programs are changing with each passing day. This is unpleasant. Your work seems so perfect today, but it may soon become a target of ridicule. It is frustrating because no matter how hard we work to learn the latest and best development tools, designs, frameworks, and development methods, we are always slower than the latest technology development trend. For me, this is the most annoying thing to be a programmer. We constantly upgrade our technology to make the software better, but we can't help but feel like a sand-painting monk.

[Edit recommendations]

1. Every good architect is a good programmer.
2. Suggestions from successful web developers such as Facebook
3. What does HTML 5 bring to developers?
4. The future of Java programmers in the hybrid programming age
5. It's time for programmers to start learning Ruby.

This article is reposted from the IT comments of an external magazine. The original Article titled "Top Ten troubles for programmers"