Top 10 THings that annoy programmers

[argonauta]

I just saw this at the most popular bookmarks from delicious:
http://www.kevinwilliampang.com/post...ogrammers.aspx

agree 100% with it

10. Comments that explain the "how" but not the "why"
9. Interruptions
8. Scope creep
7. Management that doesn't understand programming
6. Documenting our applications
5. Applications without documentation
4. Hardware
3. Vagueness
2. Other programmers
1. Their own code, 6 months later

[gerbick]

That's tattoo worthy.

[yasunobu13]

0. Users

[PAlexC]

...and that is why we have product development specialists. If you don't have one, take off your programmer hat and become one. Enforce a process, gather requirements.

Read this book.

[FlashLackey]

Hah. Good one.

Though, I would put "Interruptions" higher on the list.

And I would add "Browser Bugs" and "Daily Build Reviews".

[Oaf]

Artists

[MagnusVS]

As I'm reading this, I'm just about to start to write documentation for a website and some software that I've made during the last 6 months I absolutely agree on #6 (even though it's important).

[jAQUAN]

LOL@ #10

My would be additions:
+ Constant Learning: I just want to use the stuff I know for once.
+ Fixing other peoples code: Why can't I be brought in on the ground floor if I'm so good at debugging?
+ Lack of really cool tools: I'd love to just drag a package onto an app that can create a visual flow of wtf it's doing.

[Saint Benedetta]

7. Management that doesn't understand programming

I completely disagree.

1. Their own code, 6 months later

Haha, LOL.

[gerbick]

I completely disagree.

You've never been asked to create something that, in the management's mind should take moments, but in all actuality it takes weeks.

I had to build a Flex CMS interface that fully pulled the taxonomy and interfaced a .NET CMS with the most horrific API's ever... and they complained that it took 4 months.

It would have been shorter if they didn't keep adding stuff that "it should only take a few moments, right?" and despite my clarifications, they insisted.

It made my project that much harder whenever they didn't get that their request(s) were pages of added code.

[Incrue]

7. Management that doesn't understand programming

I completely disagree.

[Saint Benedetta]

Hahaha.

I don't think a programmer should expect their managers, and their manager's managers, to have the same level and breadth of experience as the programmer. Don't expect management to understand programming specifically - expect good management instead.

[gerbick]

You can't properly manage without a cursory understanding of the technologies within. Let's be honest, a senior manager's ambition is to become a CTO in most cases.

And you can't be technically lacking to manager engineer/developer/programmer resources and not understand a damn thing. You'll lack the ability to project manage anything. You'd be clueless and have to depend on your workers. Which is the total opposite of what managing truly is, imho.

[Saint Benedetta]

"Cursory understanding of technologies" and "good management" (to take into account more general skills) would have been better to use than something specific like "programming" for #7.

[argonauta]

Hahaha.

I don't think a programmer should expect their managers, and their manager's managers, to have the same level and breadth of experience as the programmer. Don't expect management to understand programming specifically - expect good management instead.

I think you have to check the differences between knowing and understanding. To understand something, you don't need to know it.


But I agree, the phrase should have been "Management doesn't have cursory understanding of technologies"

but the article refers specifically about programmers and what they and only they hate, and the general name for the technology they work with, more or less, could be called 'programming'

so maybe "Management doesn't have cursory understanding of programming" could have been better. But well, some people may not understand 'cursory understanding' so I think it could have been better to use a more common term, like...I don't know, maybe "don't understand".

So, the best phrase they should have used there is "Management that doesn't understand programming"

Management doesn't need to know how to program, but they do need to know what it requires....if a boss of mine doesn't have any idea about programming, how could he know how long it'd take to make a program? He'd need to ask me, and I could say: well, for each button we need two years, as it's a very difficult code. He, not having an idea, would need to go with I tell him....unfortunately, most times goes the other way: they think everything is just a line of code, 5 minutes of work, no change can take longer than 1 hour....and they think that way because they don't understand programming

[Saint Benedetta]

I am still feeling uncomfortable about this and I'm not convinced.
I did have some questions but don't really want to drag out the thread unnecessarily.

It's a nice list. What about a "Top 10 Things that Annoy Designers" list...

[Loyal Rogue]

What about a "Top 10 Things that Annoy Designers" list...

1) Clients
2) Clients
3) Clients
4) Clients
5) Clients
6) Clients
7) Clients
8) Clients
9) Clients
10) Clients




Too easy...

[jAQUAN]

Is that your resume for wefail?

[Frets]

Loving the client doesn't make you richer.
Think of yourself as a child psychologist in a juvenille detention center.