Programmers all have their pet peeves. Whether it’s scope creep, Hungarian notation, or smelly coworkers, we’ve come to accept that there are certain nuisances that come with our line of work. The following is a list of the top 10 things that annoy programmers, compiled from the results of my recent question on StackOverflow along with some of my own experiences:
10. Comments that explain the “how” but not the “why”
Introductory-level programming courses teach students to comment early and comment often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many programmers seem to take this as a personal challenge to comment every single line of code. This is why you will often see something like this code snippit taken from Jeff Atwood’s post on Coding Without Comments:
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. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it.
Now, consider the same code with a different commenting methodology:
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
Much better! We still might not understand exactly what’s going on here, but at least we have a starting point.
Comments are supposed to help the reader understand the code, not the syntax. It’s a fair assumption that the reader has a basic understanding of how a for loop works; there’s no need to add comments such as “// iterate over a list of customers”. What the reader is not going to be familiar with is why your code works and why you chose to write it the way you did.
9. 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.
8. 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.
7. Management that doesn’t understand programming
Ok, so maybe there are some perks.
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
Don’t sneeze, I think I see a bug.
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!
I’d agree with #1. I’ve written the same web app 3 times. Although I really didn’t know much the 1st time as I was new to it. But after reading some practice books, version 3 is great. Now just to see if I feel that same way in 6 months.
had to lol at #1. i dred those days when a 6 month old project (or older..) project comes back into the mix, I’d usually like to just write it from scratch! lol
What about having to finish someone else’s work, or work with someone else’s code? Even if it’s well commented/documented, you can always find something that you would have done differently.
Obviously not written by a corporate programmer. Its like the list was written by a student who doesn’t know big bussiness has had computers for more than 50 years. Medium business 500 million a year have had computers for 40 years. And your rewriting something thats six months old, you can’t communicate, don’t know how to stop scope creep.
@ Dan
Actually this feels like it was written by a corporate programmer since these are things that annoy corporate programmers.
@Dan
Jake’s right. I am a corporate programmer. I’m not sure whether I should take offense at your comment because I’m not entirely sure I understand it.
Would you care to elaborate on how big businesses and the length of time they’ve had access to computers relates to this article?
Wow, great list. I can wholeheartedly agree with everything on the list. I suppose order will differ for everyone. Feature creep and hard to get along with "other programmers" would be my number 1 and 2 things.
You seem to have omitted one of my pet peeves: "Off-topic and bizarrely ungrammatical comments made by people with nothing to say, who adopt a disgruntled pose in an attempt to appear experienced, but who merely succeed in making themselves look humorless and confused."
Fortunately, Dan obliged us with a perfect example, thus rectifying your omission.
Good List … @Kevin – start up developers don’t run into these type issues often as we govern over our code like it’s our child, and everytime something new is checked in it is usually examined by the whole team. So, even in six months we are all still horribly proud of our contributions (USUALLY)
Also, we’re a little more into Self-Documenting Code
Woahh, did enjoy this one…
Amen!!!! Great list, I think I will post it and carry it with me always.
I think Dan’s point is that companies have known about these issues for 40+ years and worked around them.
Becoming familiar with the hardware is important. Recently an annoying fact has been the capacitor meltdown of power supplies manufactured recently.
http://en.wikipedia.org/wiki/Capacitor_plague
SECDED for memory (ecc) is another hardware topic. Perhaps code should be written defensively to recover from some memory errors. I picked out a consumer (non-server) asus motherboard recently and it was difficult to find a model that had secded, which is an unfortunate sign.
http://cr.yp.to/hardware/ecc.html
Finally, for the other programmers category it sounds like they aren’t very good. Perhaps peoples abilities hover at some set range for a while, with each programmer working at different level of an exponential scale. If you’re too many levels away there could still be learning both ways but at some point there will be friction and less productivity.
The train example is ok except it doesn’t explain how someone can stop the momentum of a train in a split moment with their interruption, perhaps even reverses its direction and driving it off track into a funk. I like the house of cards example of keeping things loaded in your mind. Its easy for someone to topple that. Perhaps this suggests we need to do mental exercises to a far greater level, akin to the movie Pumping Iron for weight lifting, in order to weather the (corporate) storm.
Haha, nice one Mickey. I was kinda thinking the same thing but didn’t know how to put it into words. Great list!
outstanding!
Right on. I would have put #10 at #1 though. I see and do this so much. We get so heads down focusing on what we are doing that we often forget WHY we are doing it. Writing WHY comments also helps you keep on task…cause you know…sometimes your solving a problem that doesn’t absolutely need solving right now.
Hey Kevin,
I am not a corporate programmer, I’m still an undergrad, (hopefully graduating next Spring) but I’ve had Summer jobs where I had to work with other developers and yes, I can relate with most–if not all–of points you mentioned above! Thanks for the good read!
Woaaah, nice list
couldn’t agree more especially no #1
"who write that stupid code? hmm let me see the subversion, oopps it’s me"
Excellent list. #1 had me grinning from ear to ear as it’s oh so true.
Thanks for all the kind words everyone!
Glad you all enjoyed the article. I have to admit that it was quite cathartic to write it all out.
Agree with all. Some much more hilarious than others, but perhaps that is because I still feel the pain.
20 years of experience in the business negates absolutely *none* of this list. And 20 years from now – it will be just as relevantly funny.
A Little like someone taking your chest hairs and pulling them all out at once… (Sorry, not a woman, so can’t make a relevant analogy… although there is waxing I suppose…)
Kevin,
LOL, so this is the outcome of your question in stackoverflow?
Great article summarizing it though!
I think it’s a shame when somebody takes all the effort to name symbols and lay out the code properly and then does not document it, living instead under the arrogant assumption that, since the code is so well written, his collegues will instantly understand how the code works.
If you’re writing only for the compiler, please don’t bother with indentation, newlines and proper variable names… That way I won’t bother with reading your code either!
You know what? Fuck you.
I can’t take you seriously because .Net is a fucking joke and so are you.
LOL @chang
And that is why my answer in this stackoverflow question is that I am annoyed at zealots who just ruin everything.
I prefer no comments but a method in this case:
squareRootWithNewtonRaphson(int n)
and another abstracting the implementation away
squareRoot(int n) {
return squareRootWithNewtonRaphson(n)
}
Peace
-stephan
Great list, but in number 7 you forgot to give credit to the xkcd strip you showed:
http://xkcd.com/303/
cool.. so me!
hahaha
based on my recent talks on SEO and feedback at barcamp, id have thought that the #1 thing (web) programmers hate is SEO!
poor me
We have to accept that we will never know it all and that perfect code is a pipe dream.
What are you? Absolutely nuts?
Being apathetic to the code base and project is the most annoying thing according I find at work.
You should add to the list: working with any Office products, Excel, Word, or other stuff a "real" programmer shouldn’t touch … ever.
BTW, in Stackoverflow Podcast 19, the private beta will be finished on September 3rd, so the link will work after that (except it won’t have beta in the url?)
An IT director briefed us that you should look at your own code three years from now, and be embarrassed; if not, then you haven’t grown as a developer.
#9 is true and it also applies to me.
I think you missed a big one:
When other people take credit for your code and/or take credit for your ideas.
Well, I guess based on #5 I’m quite the anomaly. I’m a technical writer (with a tech writing degree from SFSU) who loves to pretend I’m a programmer. I plan to go back to school for a Master’s in Comp Sci, and my dream job title is "Programmer/Writer" or "Writer/Programmer." Oddly enough, you don’t see that title very often! LOL!
Shouldn’t a top-ten list from a programmer start at 9 and count down to 0?
I really enjoyed this list, and could relate to all of them. #6 is my downfall (especially when #1 happens!)
Great list, fully agree to all 10 things
Instead of reading your old code and saying "What the hell was I thinking?", what about those cases where you read someone elses old code and ask "What the hell was this idiot thinking!?" and an hour later into the code you remember you’re the one who wrote that file.
Brilliant list, thanks for spreading the word.
Ugh. What annoys me the most, to no end, is whining programmers complaining about everything there is to complain about.
Instead of writing meaningless lists that annoy you (but cleverly enough projected upon all programmers), you should be proactive and "fix" those things that annoy you.
You can’t understand what a piece of code does? doggone it, use your analytical skills and find out what it does.
Losing your mind you’re getting interrupted so often? What about asking and/or telling people you need to focus on what you’re doing? Oh but I guess that would require some social skills.
Scope creep? What about talking to stakeholders and explaining the HUGE difference wording can make? What about telling your manager than the ETA given initially was given under certain assumptions and these no longer hold true and thus you need to revise the estimate?
And so on and so forth. Too doggone easy to complain, complain, complain. Avoid VCs and start-ups. With that complaining, whining attitude you won’t have a good time.
I’m annoyed at having to work in front of an probably five-year-old 17" screen, while having a dual-screen setup (24" and 19") at home.
@JeezLuis
I think ironically the skills you are saying he should develop is the ability to complain. Just in this case, to managers.
It is also recommended that if you write comments that explain "how", they are also correct.
You write [quote]// square root of n with Newton-Raphson approximation[/quote], but it is not a Newton-Raphson method…
#9, that is the worst for me…I am very workflow oriented, and when im in the zone and on a roll, and someone comes over to bother me…it just kills my whole vibe..
#1 never happened to me; only the opposite. I go back months later and think "did I really write this? guess I really am a genius."
@JeezLuis
Hypocrisy intended?
Ahh yes, those days when you look at your code from a year or more ago and say, "wow was I really on the ball during that project!" I enjoy those moments and also think I may be slipping as I haven’t written anything so cool lately.
<b>Top 10 Things That Annoy CRAPPY Programmers</b>
That would be accurate. High bandwidth developers have no issue with any of the above for except when it is severe and inappropriate beyond normal expectation for extended periods.
Programmers with a clue know how to fix most of these issues with design, common sense, an understanding of organizational cultural and being able to view the world from other’s minds.
Autistic people cannot do the last item, and many believe there is a tie between autism and programming/techniacal types. I believe there is as I see a fundamental lack of ‘empathy’ in many cases.
It was burned into me after 2 decades of trying to make others fit my world. It never works and the ‘others’ involved will likely never change.
So true…. I 100% agree with all that!
they’re all things that make me cringe because I’ve been guilty of it all!
how about, not saving test files with the name "test.php" to see if it works? I must have a million different test1.php, testparse.php etc in my code folder and I have to open them up to see what they do (and mostly they don’t have a decent comment description either!)
@Damon Wilder Carr
I disagree. "Crappy" programmers are ones that don’t care or know enough to be phased by any of the items on this list.
You can make the argument that a good programming team won’t have as many of these problems surface, and I would agree. But the point still stands that these items are annoying, even if they occur less frequently. In the end though, you have to realize that not everyone is lucky enough to have an ideal working environment.
#6 is so true. Programmers should get to know one or two good tech writers.
Showing an XKCD cartoon and linking to Dilbert? Not cool.
@Jonathan Allen
Oops. You’re totally right. I completely missed the link to xkcd for that gem of a strip. Fixed now.
I am really surprised that so many of you responded to this list of "classical" issues so quickly…. I was reading through it (forwarded by my friend) thinking that it was an age old post !!!
#1!!! The truth!!
I liked the documentation comment, although I approach it from the opposite angle — I’m a freelance writer and light editor who sucks at programming.
It’s frustrating for me, as an end user, when I see poorly written or disorganized documentation. There are a lot of journeyman English majors out there who could use the work, or even just the resume padding. Technical writing is a nice, narrow field to have experience in. (Like, say, speech writing or comedy — my chosen fields. I’m not personally begging for work here.)
If there’s really a demand in the open source community for people who are willing and able to write clear, concise documentation, I could see a symbiotic relationship with all the fresh faces out there who have both communication and geek skills. Some are just learning that they’re not going to be writing million-dollar screenplays or bestselling novels, and would embrace a way of catching a break and adding a marketable skill to their options.
I have to totally agree with you in most of this ;D.
The interruptions cuz everytime i finally get completely into my program and coding i do so much work in an instance but if people interrupt me constantly i just waste my time o.O
Ugh and documenting… man! that´s hard job
i just procrastinate and procrastinate until i have no other choice but to write it and the worst of it is that i know it is important to do it.
Hahaha! yeah and the application without documantation are so irritating, it takes you hours to figure out how to do something XD
And the hardware… that´s so common is not funny, everytime some computer gets damaged at my house, they all say im the one who has to fix it :O
Wahahaha and yeah my own code some time later!!! I just almost fall off of my chair laughing, totally agreed is the #1 most annoying thing. You just look at the code and wonder, what the hell was this person doing!? just to realize it was yourself who wrote it XD XD XD
I’d like to know where Damon Wilder Carr works and see the perfect software it is that he works on.
Good post
It is extremely frustrating being interupted while being in a code mode, that can ruin the rest of the day for me 
Great article Kevin. Just love the comments from the "everyone is stupid but me" idiots. Hehe.
-Ryan
I can agree with every one of these. Different programmers/engineers may place them in a different order (depending on experience), but I’ve seen every one of these, many a time, in large companies and small alike.
Thanks for the dark laugh, Kevin.
Nice.
BTW, it’s spelled "hypocrite".
-r
@Ryan Farley
Haha. Indeed. When my wife read some of the more obnoxious comments her response was "god, programmers are such whiny bitches". Truer words have never been spoken.
@R
Thanks. Fixed now.
SicTim’s got a strangely awesome point. Over at the ZDoom Community we have a Wiki for documentation because a. Randy Heit doesn’t have time to maintain documentation and b. there are so many unofficial versions that it would be impossible to nail them all otherwise. Not only that, though- by allowing members of the community to keep the documentation up to date, scripters like myself have what’s in and what’s working available at our fingertips. It actually minimizes points 5 and 6 very well. I think it works great for the reasons SicTim said, too- we have a mix of geek writers and geek programmers.
Re: Dan’s comment on 8/28:
You are a PRIMARY example of #2 (both on this post and you-know-what). One of the worst types of programmers to deal with are the ones with HUGE egos. They also typically tend to be no where near as good as they think they are.
This is also epitomized in Damon Wilder Carr’s last line of his comment. I would never want to be in his "team".
Good post, Kevin…
Hi Kevin
I found this via muti – great post. I am not a programmer, but I think this applies to other industries as well … I constantly get similar/same issues when doing design work and/or websites.
Feed added
Classic!
"Unfortunately, it’s very hard to get into a programming zone when your train of thought is constantly being derailed by clients, managemers, and fellow programmers."
managemers?
@Jon Cage
The built-in spell checking that *most* applications offer nowadays has spoiled me rotten. Thanks for the catch.
I once saw a 50-page program, with 1 comment on page 25, which read: "they said I had to comment this program".
Loved the list! I think my personal number ONE would be Legacy code with counter-intuitive variable and method names. I’ve actually had to support apps I’d never seen before that were constructed in such a way that the methods were "cmd2, cmd1, cmd3" and variables with nonsense rpefixing like "sx_Process, IAB_Make" etc. I mean seriously – what the helllll…
And yes, we programmers ARE a bunch of whiny bitches
That made me smile most of all – your wife is a smart chick!
This list rules!! It should stay like that, And I would talk about less than 6 months, 2 weeks later are enough.. Even more, Don`t know guys, but there’s times when you write a code, you sleep, and when you see the code again, you don’t know what it does, or why you did it, or whatever..
But any way, nice list!!
Its just awesome…and when i look back……..eeeek i was like this….and still now
I used to work with another programmer who would explain the emotional reasons why he would do different things in the comments. It made for good reading. It would go something like:
//it’s now 4 in the morning and I am gradually slipping into insanity. I smoked 4 cigs in an attempt to figure out why my iterations are escaping prematurely.
//using this function to manipulate the global government. I know that I shouldn’t do it this way, but damn the man!
I used to love reading his comments because the crazier they got, the closer he was getting to quitting again. I then knew when I was about to be handed more work.
Howg.
[b] AGREE [/b] – [i]#7[/i] – [u][/u]- [quote][/quote]
under the MANAGEMENT that don’t understand programming is STUPID CLIENT REQUEST THAT DO NOT KNOW WHAT ARE THEY REQUESTING!!!!!
Stupid CLIENTS! They just like moving objects even it is not suitable for the website!
Make POWERPOINT INSTEAD!!!!
As a technical writer, I have to say that one of the things that makes me cranky is management that makes its programmers write the documentation. It winds up either not getting done or sucking and making the programmmers annoyed. I actually <i>like</i> writing documentation.
I guess the way to approach the problem to management is to tell them that the programmers don’t have time, good documentation will cut down on support contacts, and it’ll keep the dev team happier. Everybody wins.
I may have missed it, but did anyone add stupid salesmen to this list. You know the guy/gal who promises the customer A,B, and C when you have only built A. When you tell them you only have A then they run to senior management about how the IT group let them down.
I hate them.
so true all of them… especially the 10th one is the one i do to my self (apply the first one and you got me
)
I agree with the last one
I love lists like this because they are so reaffirming… While I agree with all of them, #9 is my cross to bear that I cannot get anyone to understand. When I get in the "zone" you can light fireworks in my hair and it won’t knock me off the pace. The trouble is getting [i]in[/i] the zone.
Nice list, thank you!
Great list. Number 1 deserves its spot as (a) all good programmers have been there and (b) it reminds us that a little humility is no bad thing!
<b>#11. The management always wants the new project written in a new/different language… </b>(And we all know those "Learn #$%@# in 7 days" books are worthless.)
=
@drewbeta, that made me laugh so hard!! I think I’m going to start doing that myself.
When I really get in the zone (#9), it’s hard to pull me out of it that quick. Especially if I’m at home. The husband will be trying to get my attention or have a conversation, and it’s tunnel vision for me – to the point that I don’t even realize he’s trying to communicate. By the time I do realize, he’s pissed off because I’m "ignoring" him.
I agree with pretty much everything said above, but I would add; your boss saying ‘Ok people, let’s think out of the box on this one’. I’ve had a bad experience. Can you tell?
re: Vagueness
My own bug bear here is where programmers expect the user to describe the problem in a manner that they can work from. For the love of Pete – you need to ask questions to get the information you need. If I [b]ever[/b] hear a programmer telling me that the user does not understand or they did not give enough information or that it was [i]their (the users)
[/i] fault then my first thought is "what questions did you ask?". This is hopelessly generalised and I know that but I find that very often, the programmer did not really bother to ask questions … it seems it is much easier to blame the user.
Apologies to all the coders out there who do take the time to question and help the people they write code for (and o all the others: you ain’t writing the code for yourself – you need them [i]users[/i] whether you like it or not).
All,
My simple points were meant to incite a reaction. If you were angry good! Now help be part of the solution.
1) These issues are not going away and in fact they can be said to define the conditions of what a software engineer experiences.
2) It is not the responsibility of others to change behavior it is our responsibility to help them understand what we need to be effective at our craft
3) I used ‘crappy’ to get people awake. It’s good to be mad as most need to be shaken out of a comfort zone of ‘complaining’ about these items and actually ‘acting’ to fix them
4) What most find is the best you can do is stop trying to ‘change others’ and instead change yourself (this is the bottom line here)
Once you accept (4) only then will you often see change come from others.
Believe me, I am not in any kind of perfect laboratory. I have the same issues as everyone, I’m just saying nothing from hard won experience little will change for you personally until you consider change from within.
There is nothing demanding others to meet us on our terms, so the alternatives are quite obvious.
Damon
Great list. All so true.
sweet.
Absolutely true!
I hate reading my own codes after several months
OMG, this is funny and sad at the same time.I agree with everything, but #1 blows me away.It’s totally true.And like someone said in another comment, working after someone else gives you headaches,and you start wondering if you save more time doing it again yourself.
http://www.library-book.co.cc << Free Download IT Programmer Java Linux ASP Flash PHP and much more Books
Oh sorry, Kevin. I just started blogging so I just dont know some basic blogging ethics. I’ll note this. Thanks.
for me the worst… scope creep!!!
when I see old code I get nostalgic…
and finding you own code not found on corporate code repository, lol
Yes, it’s pretty tough getting things started when you have life’s constant challenges on your mine. The good news is that programmers usually get things done best when they start slow and get in a zone at their own pace.
Need to add one more: People/Clients Who think they know programming…
fauxhawk is right, a lot of client think that they know programming and sometimes they want you to work with impossibles or no solutions.
Totally annoying and agreed
I agree with no. 9, sometimes interruption can make me start it all over again.
@Romzi_kamek
Out of the Ten points middle 3 points really annoy me a lot,Could we overcome these?
yup, this is great list, I will book marked this blog. thanks
i really liked it. a great list. every coders have to reconsider about those bad inhabits and facilities objectively on his/her mind…
Thanks for the post
Ya it is really frustrating when we try to learn some thing then in a second there are available new thing that we should learn.
Documenting is also the important thing but for people like me, it is really make me wired. Time is always kill me when i want to creating a documentation.
One question for you, why did you explain it with 10 to 1
. Creative
and the 11th are the top ten lists….
AGREE #4
I’ve encountered a lot programmer like that and it is really annoying specially if you will take over the project.
Nice post..I see and do this so much. We get so heads down focusing on what we are doing that we often forget WHY we are doing it. Writing WHY comments also helps you keep on task…cause you know…sometimes your solving a problem that doesn’t absolutely need solving right now.
<a href="http://www.ultimatetruck.com/departments/Tonneau_Covers.aspx">Tonneau Covers</a>