Tag Info

Hot answers tagged

37

Professionals in every profession have a way of thinking that differs from the others. After all, 'tis natural - you went to school and studied exactly for that reason; so you could develop that way of thinking. So yes, to that first questions. What one should never do, however, is think he is better than others in any way. And that is something IT people ...


36

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


23

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


23

What you are experiencing is very real. Taking a holiday, switching tasks or as an extreme measure change jobs: these are potentially excellent ideas but they are long term fixes. In my experience one doesn't always has the luxury of doing the right thing. It may well be inefficient, but sometimes (often?) one has to work when he's burned out, tired, ...


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


17

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


16

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.


13

I think developers are the only people I know who use nested brackets in written communications (Because we use them all the time (unless your language doesn't support them)).


12

IMO most scientifically minded folk have a potential to be become addicted to thinking - the deep thought + analysis needed in our day jobs hammers only a part of our brain. Unfortunately, I've found that the analytical thinking then spills over out of my work into my home life - e.g. I start analyzing the greater world around us in the same way. So not only ...


11

It's been demonstrated that there are two kinds of thinking (logical and intuitive) and most people have a predisposition toward one or the other. I personally think that many programmers are balanced between the two (whole-brained is the term mentioned in the article), based on the fact that we understand things like elegance and "good-looking" code (as ...


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


8

I had the privilege to work with someone who was an excellent coder who was always bright-eyed, solution oriented, and didn't get overly upset about the day-to-day insanity of the job. Every 4-6 years he quits his job and sails around the world. I don't think it is too much of a stretch to say that this is probably why he's always so on his game. I worked ...


8

I save up 80% of my leave, flexi time and time owed as OT and take it in one block. Depending on finances I either head off traveling, work at music festivals (bar works) or completely renovate my house. Basically I get 4-5 weeks a year that is just mine. No computers, no on call, no thinking about programming. It has completely saved my sanity (for lack ...


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



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