Tag Info

Hot answers tagged

36

Just ignore it The trolls will always be there...


26

How do you tell your professor he's not on the right track? You don't. He's paid to be there and provide the knowledge and you're not. He probably wouldn't take too kindly to any presentation that you can offer on how he's wrong. So what do you do? Ask questions. If you think he's off base with a concept or idea then ask him to elaborate. Keep ...


18

It doesn't sound that bad to me. When I saw this post title, "How to handle coworker with 'obsessive refactoring disorder'", I was afraid it was going to be one of my coworkers posting about me! You have a consistent code base. You admit that many of the changes are improvements. I think your best course of action is to let it go. I feel this is ...


17

Assume it's true. Because recognizing it in hindsight doesn't help. Don't criticize without concrete examples of why the technique you're criticizing will cause problems. If your advice is ignored, just move on, accepting that you may not hold the only right answer... or a right answer at all. And above all, stay out of religious wars. If someone wants ...


14

if they're right, thank them and fix it, or at least explain it so you don't confuse people. if they're wrong, ignore it EDIT: to take the question literally - how to avoid... - the answer is: proofread!


14

Try to talk less than you listen.


14

IMO, I think it's great to receive critical feedback like this. I love finding out how others do things and your example showed this quite well. It is very unfortunate when people do down vote you for something like this but I think that's just the way they are. Also, remember not to antagonize the dispute. You pretty much just have to roll with it and what ...


11

No. I do not see any obvious co-relation between the two. Writing clean code comes from a passion of producing quality work. Reading messy code comes out of necessity. However, I can see a case where if someone has only been exposed to "unmaintainable code" that person will be more prone to writing bad code. If that happens to be the situation here then I ...


8

Whereas I fully subscribed to the idea of collective ownership of code, I find this extremely irritating, but attempts to have him stop seem to have no effect. That kind of behavior is unacceptable in team envirenments. Talk to your boss and ask him to stop your co-worker. If that does not work, look for another job.


7

Refactoring is generally a good thing; however there is a thin line to walk on if you're refactoring code someone else wrote. Remember: prioritize. What's better, clean code or working code? At the end of the day, your customer won't care if you have two convertFooToBar functions in your code as long as it works. You can refactor for version 2 when you have ...


5

Everybody wants to rule the world. If you answer questions on SO, chances are you were trying to be helpful. Keep in mind that examples that you provide should be aimed at someone who didn't know what you are trying to explain, hence some people will be very pedantic. 9/10 times, it is people who just care about the quality of your answer. 1/10 times you ...


5

Give people the benefit of doubt by assuming they know what they are doing. Then if you feel like something's wrong with what they're doing you'll be cautious (that is- polite about it) because since they know what they're doing it's probably you who misunderstood something. If you have no stake in the project then don't give advice unless you feel ...


5

Either I just have bad luck, I am wrong a lot, or there are an increasing number of pedants trolling on StackOverflow. Honestly I think you might have been over-sensitive to criticism in this case. This is the comment that tchrist wrote on your answer started out pretty tame and might have been useful to someone who knows less about regex than ...


5

It depends how/when/what you do. I always try to refactor code as I come across it (but not while I know someone is actively working on it!! :) What I try to avoid is pernickety/subjective types of refactorings, things that I may have done one way, but another would do differently, and that are EQUALLY valid. Going too far with those things will only ...


5

Kent Beck's mom said, of a baby: if it stinks, change it. I wouldn't call that obsessive parental hygiene disorder. Just the same, when you smell bad code, change it is a healthy attitude and a healthy practice. Keeping babies and code clean is better for us all.


5

This sounds pretty normal and usual and I'm going to use analogies (oooh, evil) to demonstrate that. For starters and to stick to the reading/writing theme: A good editor is not necessarily a good author! Good editors or reviewers will spot mistakes in your grammar and style, and identify the blind spots in your story plot or the quality of your research. ...


4

In addition, he has a almost child-like need to have the last word in any discussion and has never any word of praise for work done by coworkers I think this is the root cause. I have had coworkers like this before, they think they are way better everyone around and they having the last word actually helps the others and the discussion. There ...


4

Obsessive Refactoring is not a bad thing, but it is the wrong solution to the problem. Instead of taking on all the problems in the code (and possibly angering members of your team) you should be working towards educating the rest of the team as to why refactoring is important. But this too has to be done in a way that will not cause too much friction. ...


3

In most cases, it's safe to ignore it. As @Aaron says up, it is great to receive critical feedback. That's what these sites are all about, right? But, there is a difference in receiving critical feedback and what you call syntax pedants (cute :-). Critical feedback, in my opinion is expressed in two ways. One is writing down your answer with your version ...


3

When coming up against any kind of force, you have two ways to go, either push against it or go along with it. Your main issue seems to be a psychological one, his refactoring your code and know-it-all attitude is hurting your work pride and might make you feel a bit insecure. One way to go is to try and look at the style of refactoring he's doing, if it's ...


3

There is something to learn from everyone in this world. Although he may not be exactly correct in everything he says, or even sometimes just plain wrong, I would still listen but simply take what he says with a grain of salt. Don't get it in your head that you are superior to him in your knowledge. There's no such thing as absolute superiority. The ...


3

Talk more slowly. Pause now and again. But don't replace silence with Um, Err or Y'Know. There's a tendency amongst some knowledgeable technical people to talk fast and excitedly. This comes across as assuming that everyone around you can keep up, it also does not give much of a chance of having a conversation (things have moved on so fast). Stopping and ...


3

Some other thoughts I didn't see mentioned: Don't fix things like incorrect naming conventions. Make the person who did it fix it and learn how to do it right. Don't refactor someone else's code unless (a) it's your job or (b) the code is really bad. Premature refactoring is a prime time-waster and you risk being viewed as a pedantic time-waster.


2

It's tough in a technical field because, we're expected to have all the answers. If your app crashes, you don't respond with, "What do you think caused the connection to fail? I value you as a child-of-the-world, and want to encourage you to voice your opinion in a non-judgmental space." In technical circles, if I think I'm right, I say so. If you prove me ...


2

Try giving your advice/criticism only once and if it is not accepted move on. It is fine if you are asked to provide arguments for your point of view, but know that it is time to stop when you realize that the other side will not be convinced (perhaps because they do not understand certain thing that you do or vice versa) by any of them. Also, don't turn a ...



Only top voted, non community-wiki answers of a minimum length are eligible