Comments on: Top 10 Things That Annoy Programmers http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/ ASP.NET Developer. ALT.NET Supporter. Pragmatic Programmer. Published Writer. Wed, 01 Dec 2010 20:34:08 +0000 hourly 1 By: Brett Widmann http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-4896 Brett Widmann Sun, 07 Nov 2010 01:25:03 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-4896 Great article. I always use comments in my code evens if they are simple. It helps to find different things quicker and reminds me what things do and where i want to edit. Great article. I always use comments in my code evens if they are simple. It helps to find different things quicker and reminds me what things do and where i want to edit.

]]> By: sue7024 http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-4838 sue7024 Thu, 04 Nov 2010 14:00:20 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-4838 I'm a project manager, but used to be a developer, so I understand the pains of the above. . .very good list. . .where I work there is a sign that hangs as a constant reminder and reads "Always code as if the person who will maintain it is a violent psychopath who knows where you live". I’m a project manager, but used to be a developer, so I understand the pains of the above. . .very good list. . .where I work there is a sign that hangs as a constant reminder and reads “Always code as if the person who will maintain it is a violent psychopath who knows where you live”.

]]> By: John http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-4067 John Wed, 22 Sep 2010 11:21:55 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-4067 Users - they are like the worst types of managers possible. Managers have to deal with you - that's what they're paid for. Users will just sit on your forums and whinge that you're dropping support for an OS that hasn't been updated since the Stone Age. Users – they are like the worst types of managers possible. Managers have to deal with you – that’s what they’re paid for. Users will just sit on your forums and whinge that you’re dropping support for an OS that hasn’t been updated since the Stone Age.

]]> By: Toby Franklin http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-4046 Toby Franklin Mon, 20 Sep 2010 17:15:36 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-4046 Good points, especially the first one about interruptions. I work as a BA and PM, and when I'm working on a document I definitely need some uninterrupted ramp-up time to get going. I recently started a position at a company that uses a SCRUM methodology, and the short morning meetings have cut down on interruptions considerably for the team. Good points, especially the first one about interruptions. I work as a BA and PM, and when I’m working on a document I definitely need some uninterrupted ramp-up time to get going.

I recently started a position at a company that uses a SCRUM methodology, and the short morning meetings have cut down on interruptions considerably for the team.

]]> By: Simon2 http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-3248 Simon2 Sat, 07 Aug 2010 23:33:33 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-3248 You should go read the top 10 list again. You're optimisation offers nothing and in fact makes it harder for a future developer to understand because if there were a bug here it less represents the original algorithm that the original coder copied (and the future coder will google it and find it), it is more obscure and harder to understand and most modern compilers are highly efficient at optimising code. Personally I would explain the algorithm in the comments if it were not obvious. Less lines does not make better code. You should go read the top 10 list again. You’re optimisation offers nothing and in fact makes it harder for a future developer to understand because if there were a bug here it less represents the original algorithm that the original coder copied (and the future coder will google it and find it), it is more obscure and harder to understand and most modern compilers are highly efficient at optimising code. Personally I would explain the algorithm in the comments if it were not obvious. Less lines does not make better code.

]]> By: Simon2 http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-3247 Simon2 Sat, 07 Aug 2010 22:40:56 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-3247 Once I was allowed to because of a performance problem. I reimplemented a tree data structure implementation written by the lead developer which had >10 classes as a hashlist of hashlists. It was very rewarding because the performance issue was solved and with 1 class with less than a page of code was required. Once I was allowed to because of a performance problem. I reimplemented a tree data structure implementation written by the lead developer which had >10 classes as a hashlist of hashlists. It was very rewarding because the performance issue was solved and with 1 class with less than a page of code was required.

]]> By: Simon2 http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-3246 Simon2 Sat, 07 Aug 2010 22:27:52 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-3246 Yes, I feel the same. Often you develop something under tight deadlines and with no real specifications or design and then the code creep; developers were never involved in the selling process of non-existent features so you can't go ask the customer what the specifications should be and the sales team has no idea. Lack of documentation means the developers then make best guess at interfaces and API's and make assumptions about business processes. So, when with hindsight, you can revisit something you did under those conditions you can rebuild it with better understanding. I so infrequently get that opportunity. Yes, I feel the same.

Often you develop something under tight deadlines and with no real specifications or design and then the code creep; developers were never involved in the selling process of non-existent features so you can’t go ask the customer what the specifications should be and the sales team has no idea. Lack of documentation means the developers then make best guess at interfaces and API’s and make assumptions about business processes. So, when with hindsight, you can revisit something you did under those conditions you can rebuild it with better understanding. I so infrequently get that opportunity.

]]> By: Elia http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-3124 Elia Sat, 31 Jul 2010 16:30:36 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-3124 Perfect, man! Congratulations! Do you know if there is already a brazilian portuguese translation for that post? Perfect, man! Congratulations! Do you know if there is already a brazilian portuguese translation for that post?

]]> By: tan4eg http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-2210 tan4eg Wed, 16 Jun 2010 06:28:08 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-2210 Hi Kevin! Russian version of your great list is here http://sly-and-fluffy.blogspot.com/2010/06/10.html Hi Kevin! Russian version of your great list is here http://sly-and-fluffy.blogspot.com/2010/06/10.html

]]> By: Johan Karlsson http://www.kevinwilliampang.com/2008/08/28/top-10-things-that-annoy-programmers/#comment-2126 Johan Karlsson Thu, 03 Jun 2010 06:39:35 +0000 /post/Top-10-Things-That-Annoy-Programmers.aspx#comment-2126 I really liked reading this article. I think that #10 is important. #7 is something that I have encountered a lot. I really liked reading this article. I think that #10 is important. #7 is something that I have encountered a lot.

]]>