Htranslations
Raiting:
2

Top 10 most annoying factors for the programmer


I just recently have come across a hit parade of the most annoying things for the programmer on the internet.

Here they are:

10. Comments that explain “how” but do not explain “why”


In the university where I was a student studying a course of programming, we were taught to make detailed comments to the code. It’s better to have too many comments than to have too few. Unfortunately, sometimes this advice grows into the paranoia, namely programmer comments every single line of code. For example:

$r = $n / 2; // Set $r to $n divided by 2

// Loop while $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)
}


Do you have any idea what this code does? Me neither. Even after a shot of whiskey. This code is demonstrating the problem when the comments are describing what the code is doing, but they are not describing why it is doing it.

Let us consider the same code with normal comments:

// square root of n with Newton-Raphson approximation
$r = $n / 2;

while ( abs( $r - ($n/$r) ) > $t ) {
$r = 0.5 * ( $r + ($n/$r) );
}

These comments are explaining why this code is needed for.

The code comments are supposed to help the programmer who will read it after you to understand the code, not the syntax. Anyway, the reader should understand how a loop, division, and other language structures work.

9. Distraction from work


A few programmers can write the code from scratch using the little finger of the right hand. In general, a programmer is more like a locomotive than Lamborghini, it may take a programmer some time to get started, but once a programmer started all work could be done quickly.
Unfortunately, it’s very hard to get into a working process when your train of thought is constantly being derailed by clients, managers, and fellow programmers.

There is simply too much information we need to keep in mind while we’re working on a task to be able to drop the task, handle another issue, then pick up the task without missing a beat. Interruptions kill our train of thought and getting it back is often a time-consuming, frustrating, and worst of all, error-prone process.

8. Changes in the project


Scope creep, in project management refers to uncontrolled changes in a project’s scope. It only takes a few innocent words that were added by the client into the project and the scope creep could happen:
For example:
Version 1: Show a map of the location
Version 2: Show a 3D map of the location
Version 3: Show a 3D map of the location that the users could virtually move

Awful! A 30 minute task just turned into a massively complex system that could take hundreds of working hours. But even worse, most of the time scope creep happens during development, which requires rewriting, refactoring, and sometimes throwing out code that developer spent a lot of time.

7. Managers that have no idea about programming


Management is not an easy job. Keeping a large group of people as a solid team is only a peak of iceberg. However, that doesn’t mean that managers should not know some basic understanding of what their subordinates are doing, especially in IT industry. When management cannot grasp the basic concepts of our jobs, we get additional changes in the project, unrealistic deadlines, and general frustration on both sides of the process of development. This is a pretty common complaint amongst programmers and the source of a lot of problems.

6. Documenting our applications
There are a lot of documentation-generating applications out there, but those are only good for generating API documentation for other programmers. If you are working with an application for regular people, you have to write some documentation that the average person can understand (for example, basic concepts of your application, troubleshooting guides, etc.).

It’s not hard to see that this is not the favorite task for the programmers. Take a quick look at all the open-source projects out there. What’s the one thing that all of them are constantly asking for help with? Right, documentation.

5. Applications without documentation


Programmers are constantly using 3rd party libraries and applications in their work. In order to do that, they need documentation. Unfortunately, as mentioned in a clause 6, the programmers hate to write the documentation.

There is nothing more annoying than trying to use the 3rd party library while having absolutely no idea what half the functions in the API do. What’s the difference between poorlyNamedFunctionA() and poorlyButSimilarlyNamedFunctionB()? Do I need to do a null check before accessing PropertyX? I guess I’ll just have to find out through trial and error!

4. Hardware


Any programmer who has ever debugged a strange crash of the database or why the RAID drives aren’t working properly knows that hardware problems are a pain. The biggest common misconception in IT field that since the programmer works with computers, he must know how to fix them. Of course, it may be okay for some programmers, but it disturbs to concentrate on more important tasks. In order to satisfy that need there are supposed to be other specialists who will fix the computers.

3. Uncertainty

“The website is under construction”. “Functional X do not work properly”. Uncertain bug requests are a pain in the ass.
Especially, when angry non-programmers are asked to give some information in terms of bug say: “You are not the programmer! Just fix it”, but they have no idea that there is not enough information in order to fix it.

2. Other programmers


Programmers don’t always get along with other programmers. Shocking, but it is true. Here are the most annoying factors:
• Expansiveness in terms of opponent programmers.
•Failing to understand the fact that there is a time to debate system architecture and a time to implement it.
•Inability to communicate adequately with coworkers and client, and use of confusing terminology.
•Inability to work timely.
•Indifference to the code and project.

1. Your own code, six months later


Have you ever look back at your old code? Did I write it??!!!How stupid you were! Now you understand that you look like an idiot in your own eyes.

Well, problem… But there is good news. You are not alone :).

The essence of this problem is that the programming world has been constantly changing. What we consider as new trends today could go out of date tomorrow. It is impossible to write a perfect code, because the standards and methods of programming are reviewed and evolved every day! Of carouse, it is bitter to understand that a nice code is written today could be funny and odd tomorrow. Therefore, this is the most annoying factor for most programmers in their work.

If you have some more to add, please don’t hesitate to do so!

Via Kevin William Pang
Skull 15 february 2012, 19:47
Vote for this post
Bring it to the Main Page
 

Comments

Leave a Reply

B
I
U
S
Help
Avaible tags
  • <b>...</b>highlighting important text on the page in bold
  • <i>..</i>highlighting important text on the page in italic
  • <u>...</u>allocated with tag <u> text shownas underlined
  • <s>...</s>allocated with tag <s> text shown as strikethrough
  • <sup>...</sup>, <sub>...</sub>text in the tag <sup> appears as a superscript, <sub> - subscript
  • <blockquote>...</blockquote>For  highlight citation, use the tag <blockquote>
  • <code lang="lang">...</code>highlighting the program code (supported by bash, cpp, cs, css, xml, html, java, javascript, lisp, lua, php, perl, python, ruby, sql, scala, text)
  • <a href="http://...">...</a>link, specify the desired Internet address in the href attribute
  • <img src="http://..." alt="text" />specify the full path of image in the src attribute