7. Management that doesn’t understand programming could be rewritten as 7. Management
Things That Annoy Programmers
21–30 of 39 posts
Re: Things That Annoy Programmers
#22Re: Things That Annoy Programmers
#23Meetings. stabs self
Meeting quality is mostly a function of the thinking quality of the person controlling the meeting. If the purpose of the meeting is to impress the exec in the room that Joe is "doing something" the rest of the attendees of the meeting will probably find Joe's meeting a waste of time.
Re: Things That Annoy Programmers
#24- Justifying why we need to upgrade to the latest OS/tools.
Re: Things That Annoy Programmers
#25Top 10 lists.
Well top 10 lists are just an organized form of article. It's bad only if the content is shitty, which it is not, in the present case.
Re: Things That Annoy Programmers
#26When I first started interning at this company, I always wondered why people were doing stupid things in code and I would fix it to be cleaner and the program would break. Then I would realize there's a reason it was done in this stupid roundabout way. People that don't comment their reasons for doing stuff out of the ordinary annoy me.
Re: Things That Annoy Programmers
#27Earlier quoted context omitted.
Do you not have an editor/IDE that can automatically format code for you? Both Visual Studio and Eclipse can do this, and editors like Vim or Emacs can too.
I have someone on my team who uses SlickEdit, and it messes up all the indentations when I look at the same code in Eclipse. I have to spend a few minutes reformatting it every time he makes changes to the code, and it's a real pain.
Have you tried ctrl+shift+f in Eclipse?
Re: Things That Annoy Programmers
#28I found number 1 to be slightly inaccurate. I think it would be better as "What moron wrote this garbage?! That's it! I'm gonna go find out who wrote this and give th... Oh. That was me. Crap."
Re: Things That Annoy Programmers
#29IMHO #11 could be added as "unindented code". I was going to a guy's code yesterday and I felt very _irritated_ to read it, that i ended up spending 15min indenting it myself. I'm sure a lot of people don't like unindented code. and I totally agree with #1, it's very true for me. And especially when I've used some framework and the framework has been updated to a newer version with lots of goodies, i feel lazy to mai…
I'll do you one better. Something I found in a legacy codebase: reverse camel case code. Imagine rEADING tHIS aLLdAY. I felt like I was being partially yelled at all day while debugging.
Re: Things That Annoy Programmers
#30Funny that #10, 'Comments that explain the “how” but not the “why”', quotes from an article by Jeff Atwood to show how the comment should have been written. But in the original article, Jeff actually says that that commenting style is also not as good as refactoring the code: "That must be what I was getting at, right? Some sort of pleasant, middle-of-the-road compromise between the two polar extremes of no comments…
I'd consider that new code a step backwards since it removes the vital words "Newton-Raphson". If I didn't recognize the algorithm I might have a very hard time working out exactly how and why that lump of code approximates a square root. With the words Newton-Raphson included somewhere I could easily look it up and find out everything I need to know about not only how and why it works but also its strength and weakn…
I agree that the algorithm name should appear somewhere.
I would probably refactor the code as Jeff says, but add a comment that describes the function, probably with details about why it's implemented the way it is.