Us Programmers  we all have things we find extremely annoying it can be a thing such as scope creep, colleages that have a distinct smell.. or  a an awfull annotation of code .The world is dependent on programmers and their genius to get their business moving. Without the multitude of programs at our disposal we wouldn’t be able to enjoy the global citizen concept. There’s a lot of finesse they provide, and you’ll always find a programmer who can work diligently to create just what you want. Every time there’s a release, all software companies are totally focused on what the programming team is going to create. The following is a list of the top 10 things that annoy programmers.

Here’s a list of what annoys us proggers mostly.

16.  Client fixation with the legacy of C code

C code is of paramount importance, and we take great pride in being to use it aesthetically. However we are faced with a grave situation when it comes to preserving this legacy when an upgrade is required for multicore technology. Obviously clients also want their lines of C code to remain original, and we are hopeless faced such adjustments at our expense.

15.  Restrictive “business” Rules

Programmers are always required to create something new but there’ll always be imposed constraints. As if that’s not all, they have to create their programs within limitations that arise because of complicated business rules and of course those hateful fuzzy requirements, which are a clear representation of the clients limited understanding of what they really need leading to the only conclusion clients  don’t understand what they are requesting and fail to see implications.

14.  Official Politics

We aren’t really involved in office warfare trying to covet the next appraisal. We hate political or organizational matters that govern others in the organization. We hate being left in the lurch when people agree to their suggestions but later backtrack regarding the consent provided if something falls apart. For us , there’s a simple solution to this. Make sure you have a documented agreement whenever someone agrees to something.

13.  Interruptions

Very few programmers can go from 0 to code at the drop of a hat.  In general, we tend to be more akin to locomotives than ferraris; it may take us awhile to get started, but once we hit our stride we can get an impressive amount of work done.  Unfortunately, it’s very hard to get into a programming zone 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.

12.  So called Human factors..

In their quest for perfection client send requests that are in all technicality very prototypical but they believe it’s original. Even worse is the fact that the repeat requirements and many clients happily use vague terminology. As a result they may send over a requirement but may not know what they have asked for. Save your hard work for later, and shoot back a mail to your concerned team leader of what you have understood of the project so that they confirm. This will eliminate any possibilities of anyone in a position of power from backtracking later, or making you redo your program or rework on your hard spend efforts.

Dont’ sneeze I think its a bug! :-

11.  Scope creep

From Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

Scope creep turns relatively simple requests into horribly complex and time consuming monsters.  It only takes a few innocent keystrokes by the requirements guy for scope creep to happen:

• 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 user can fly through

Argh!  What used to be a 30 minute task just turned into a massively complex system that could take hundreds of man hours.  Even worse, most of the time scope creep happens during development, which requires rewriting, refactoring, and sometimes throwing out code that was developed just days prior.

10.  The i’ll fix it Later approach to error handling..

Programmers like things to happen in a systematic manner because that saves them from extra effort. Between the coding process, and actual implementation there’s a lot of hard work involved. As such, programmers expect any testing that needs to be conducted to be done in a timely manner, rather than be told to make changes when you’ve created almost the entire program. Honestly, error handling needs to be in pace with programming or else nothing will really make it to the release stage efficiently.

9.  Hey your a progger right? so uhmm can you fix my comp..plzzz

We are not hardware engineers so don’t ask us to fix ur so called computer crashes. We aren’t obligated to do other jobs just because that  fact that we are skilled with a comp. So, please don’t approach us for quick fixes on your computer just because we “seem” to be sitting around, There have been  cases being at a party or gig and some dude or a  grrl (nice looking girls are ok though :- ) aks you to fix their lap cause it isn’t working….supposedly

8.  Team chemistry or just plain stress?

Depending upon a programmer’s ability some tend to be more socially talented than others and some smell better…. Despite this they try their best to offer team work and get their coding to be translated to assembly. As such, don’t disrupt this natural team chemistry by trying to shift programmers to other teams because they’ll first have to work out  team chemistry, and then programming. Let things go on in their natural order instead of trying to juggle human resources. There’s a simple solution, get a new (good looking awesomely looking (grrl) programmer :-

7.  Management that doesn’t understand programming

Management is not an easy job.  People suck; we’re fickle and fragile and we’re all out for #1.  Keeping a large group of us content and cohesive is a mountain of a task.  However, that doesn’t mean that managers should be able to get away without having some basic understanding of what their subordinates are doing.  When management cannot grasp the basic concepts of our jobs, we end up with scope creep, unrealistic deadlines, and general frustration on both sides of the table.  This is a pretty common complaint amongst programmers and the source of a lot of angst (as well as one hilarious cartoon).

6.  Documenting our applications

Let me preface this by saying that yes, I know that there are a lot of documentation-generating applications out there, but in my experience those are usually only good for generating API documentation for other programmers to read.  If you are working with an application that normal everyday people are using, you’re going to have to write some documentation that the average layman can understand (e.g. how your application works, troubleshooting guides, etc.).

It’s not hard to see that this is something programmers dread doing.  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?  Documentation.

I think I can safely speak on behalf of all programmers everywhere when I say, “can’t someone else do it?“.

5.  Applications without documentation

I never said that we weren’t hypocrites.  :-)  Programmers are constantly asked to incorporate 3rd party libraries and applications into their work.  In order to do that, we need documentation.  Unfortunately, as mentioned in item 6, programmers hate writing documentation.  No, the irony is not lost on us.

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

4.  Hardware

Any programmer who has ever been called upon to debug a strange crash on the database server or why the RAID drives aren’t working properly knows that hardware problems are a pain.  There seems to be a common misconception that since programmers work with computers, we must know how to fix them.  Granted, this may be true for some programmers, but I reckon the vast majority of us don’t know or really care about what’s going on after the code gets translated into assembly.  We just want the stuff to work like it’s supposed to so we can focus on higher level tasks.

3.  Vagueness

“The website is broken”.  “Feature X isn’t working properly”.  Vague requests are a pain to deal with.  It’s always surprising to me how exasperated non-programmers tend to get when they are asked to reproduce a problem for a programmer.  They don’t seem to understand that “it’s broken, fix it!” is not enough information for us to work off of.

Software is (for the most part) deterministic. We like it that way.  Humor us by letting us figure out which step of the process is broken instead of asking us to simply “fix it”.

2.  Other programmers

Programmers don’t always get along with other programmers.  Shocking, but true.  This could easily be its own top 10 list, so I’m just going to list some of the common traits programmers have that annoy their fellow programmers and save going into detail for a separate post:

• Being grumpy to the point of being hostile.
• Failing to understand that there is a time to debate system architecture and a time to get things done.
• Inability to communicate effectively and confusing terminology.
• Failure to pull ones own weight.
• Being apathetic towards the code base and project

And last, but not least, the number 1 thing that annoys programmers…

1.  Their own code, 6 months later

Ever look back at some of your old code and grimace in pain?  How stupid you were!  How could you, who know so much now, have written that?  Burn it!  Burn it with fire!

Well, good news.  You’re not alone.

The truth is, the programming world is one that is constantly changing.  What we regard as a best practice today can be obsolete tomorrow.  It’s simply not possible to write perfect code because the standards upon which our code is judged is evolving every day.  It’s tough to cope with the fact that your work, as beautiful as it may be now, is probably going to be ridiculed later.  It’s frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, there’s always the sense that what we’re truly after is slightly out of reach.  For me, this is the most annoying thing about being a programmer.  The fragility of what we do is necessary to facilitate improvement, but I can’t help feeling like I’m one of those sand-painting monks.

Well, there you have it.  The top 10 things that annoy programmers.  Again, if you feel that I missed anything please be sure to let me know in the comments!