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 ...


22

In my experience, truly great programmers are humble and primarily interested in learning from others, not boosting their own self-esteem. Programmers with huge egos usually turns out to be mediocre developers at best. This helps put things into perspective. At least for me.


22

The updated questions. Are there any sure fire techniques for keeping yourself on a tight leash when maintaining code? No. Any tips for judging when you've done too much refactoring? Where do you draw the line between "if it ain't broke don't fix it", and allowing the code to rot? None. you can't just intuitively know when you are making too ...


19

Read through some old code you wrote more than 6 months ago. If you've been in programming long enough (and stay at one place long enough), you will have the experience of saying to yourself, "Who wrote this crap...Oh, I did."


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 ...


15

The problem is not that you did too much; you did it in parallel with other people that edited the same code. Usually, when a massive refactoring is needed, it needs to be announced, so that people had minimum merge conflicts and had time to understand the new layout. In the meantime, you can do the refactoring on your private branch and then apply the ...


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

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 ...


14

Try to talk less than you listen.


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 ...


9

The chaos level on my desk looks something like this graph, replace Amplitude with Chaos (image taken from Wikipedia): Every few weeks, I clean my desk, throw away all the useless things that keep accumulating, and vow to keep my desk clean forever. Few weeks later, I do the same.


8

If you really want to find humility, forget about competition. It's the essence of pride: "I want to be better than you." That's a part of human nature, and you've really gotta work on consciously recognizing it and eliminating it from your thought patterns and your actions. Instead, learn to recognize the strengths of others, especially those you might ...


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.


8

Always try to look at and understand the problems you are solving day by day more deeply, and to provide a proper long term solution to them. If you are out of ideas, google for similar problems and the best practices to resolve them. If you are out of challenges at your workplace, join SO ;-), or look at Project Euler. You can find more suggestions with ...


7

Arrogance isn't self-esteem; it's actually a subconscious cover for its opposite. My preferred cure is learning. You won't be arrogant if you realize that there's always more to learn and continue to seek out new things to learn. Doing that builds real self-esteem.


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 ...


6

Order or Chaos? Hmm... well, I'm usually Chaotic Good, though I have been known to play Paladins from time to time, just for a change of pace... ;)


6

I read, watch, listen, do a lot. My RSS reader has some 80-90 feeds that I skim through everyday. Everything from podcasts, videos, and text that cover topics from web to scalability to architecture. The other more important thing that I do to learn is to do. I keep coding and using the new stuff that interests me or what would benefit my career. For ...


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

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

Ego != Arrogance While I despise working with egotists, I can't deny that a certain amount of "practical arrogance" is necessary to being a great hacker (a great anything, really). Ego is about image -- trying to puff up how you'll look to others. It's usually a sign of a fragile sense of identity and/or a fear of failure. An ego-ridden coder brags, ...



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