5 ms·

The surest way to reduce the amount of such derision is by making people responsible for fixing the things they criticize, at the team culture level. It's fun t

by m0zg 7y ago

The surest way to reduce the amount of such derision is by making people responsible for fixing the things they criticize, at the team culture level. It's fun to have a laugh at the expense of someone who's no longer on the team, it's much less fun if you then have to spend weeks or months of your own time to fix it, with the possibility of still producing shit for the same reasons why the original code wasn't too hot.

jolmg 7y ago
That's nice, but it wouldn't work all the time. Sometimes the reasons for bad code no longer apply, and the code in question doesn't get updated because there are higher priorities.
- m0zg 7y ago
  >> and the code in question doesn't get updated because there are higher priorities Well, don't criticize then unless you want to own it. There's a variation of this advice wrt communicating with your boss, which is blindingly obvious to anyone who's ever been a manager, but rarely obvious to the subordinate: don't come to me with problems. Any idiot can do that, and many do. Come to me with solutions, or at the very least a proposal on how to solve problems that you're prepared to follow through on. This is basically the surest way to advance your career on any team, yet people just don't do it. Nobody likes the complainer, everyone, especially managers, likes the problem solver.
  - jolmg 7y ago
    You lost me. The question was how to deal with newcomers' arrogance, and your suggestion is to have them try and fix things to find out why it needed a bad solution. What I tried to reply to you is that they may have no problems fixing the bad code because the reason for it to be bad may be gone. Now, if I understand correctly, your reply to that is to "threaten" them with having to fix it? The point of my comment was that they'll have no problem in fixing it and they'll keep being arrogant because they'll "prove" that there was no reason for it to be bad. EDIT: s/shitty/bad/. I meant no offense to anyone.
    - m0zg 7y ago
      No, to "threaten" anyone in a professional context is a noob move, it doesn't work. You (or your boss if you're not a manager) just say something to the effect of: "on this team, if you don't like something, you don't just criticize, you go ahead and fix it". Basically, make empty bitching, moaning, and derision, socially unacceptable, and cultivate the sense of ownership. If nobody owns problems, they don't get fixed.
- brianaluv 7y ago
  That's exactly what it is. Does the fact that I have succeeded in doing a task better than another person (knowing above all that the context is not the same) give me the right to ridicule or criticize him/her beyond necessary? That's why I think the strategy suggested by m0zg may have limits... But again, this is the first time I'm confronted with this situation, so I don't really know.
- Gibbon1 7y ago
  Well and the old ugly code is known to work properly.
svaigs 7y ago
It will get old very quickly - they will soon realize that there are much better vacancies with better offers and move on. And author of this question will stay... bound by his insecurity of his unprofessionalism.
- brianaluv 7y ago
  >>And author of this question will stay... bound by his insecurity of his unprofessionalism. Could you elaborate?
  - svaigs 7y ago
    I can't really understand what is the problem and why this has to be discussed. Coders suddenly don't write bad code because they are out of time - they write bad code because they can't write good code and they are out of time to learn how to write a good code. I would hire someone who would boast how he or she wrote excellent code in tight schedule. Because I've done that. And I have seen plenty of bad code and people who were making that code and could not improve even after a considerable time, because they were morons. Laughing about them is best thing you can do - worse if you have to cry, because they are still there. There are no good ways to deal with this type of bad coding if your company do not have laid foundation of good coding practices and don't follow them. Professionalism IMO means not only knowing how to code but also work experience on different working environments to understand the difference between good and bad workplaces and predict where things will go south(or great). The things you have described doesn't sound appealing to me - that would not motivate me to code or do anything. And it seems that your coworkers who moved on made a professionally better choice compared to you that is hurt by someone laughing at how things were done before. Just think about this in different light: new people are looking at you amicable - because criticism that they are making is friendly gesture. Your intentions on crushing this behavior is based in your insecurity. So, are you going to change them all... Again, question from dino - Why do you think that they have to change and not you?
    - m0zg 7y ago
      Why do you read "insecurity" in this situation? I don't read that at all. If anything it's the newcomers that are insecure - that's why they're putting down the people who wrote the code in the first place. In all likelihood they don't fully understand it (just because code is harder to read than it is to write), so the inclination is to excuse their own lack of progress by shitting on people who aren't there anymore and chalking it up to "bad codebase".

by m0zg 7y ago

jolmg 7y ago

That's nice, but it wouldn't work all the time. Sometimes the reasons for bad code no longer apply, and the code in question doesn't get updated because there are higher priorities.

m0zg 7y ago
>> and the code in question doesn't get updated because there are higher priorities Well, don't criticize then unless you want to own it. There's a variation of this advice wrt communicating with your boss, which is blindingly obvious to anyone who's ever been a manager, but rarely obvious to the subordinate: don't come to me with problems. Any idiot can do that, and many do. Come to me with solutions, or at the very least a proposal on how to solve problems that you're prepared to follow through on. This is basically the surest way to advance your career on any team, yet people just don't do it. Nobody likes the complainer, everyone, especially managers, likes the problem solver.
- jolmg 7y ago
  You lost me. The question was how to deal with newcomers' arrogance, and your suggestion is to have them try and fix things to find out why it needed a bad solution. What I tried to reply to you is that they may have no problems fixing the bad code because the reason for it to be bad may be gone. Now, if I understand correctly, your reply to that is to "threaten" them with having to fix it? The point of my comment was that they'll have no problem in fixing it and they'll keep being arrogant because they'll "prove" that there was no reason for it to be bad. EDIT: s/shitty/bad/. I meant no offense to anyone.
  - m0zg 7y ago
    No, to "threaten" anyone in a professional context is a noob move, it doesn't work. You (or your boss if you're not a manager) just say something to the effect of: "on this team, if you don't like something, you don't just criticize, you go ahead and fix it". Basically, make empty bitching, moaning, and derision, socially unacceptable, and cultivate the sense of ownership. If nobody owns problems, they don't get fixed.
brianaluv 7y ago
That's exactly what it is. Does the fact that I have succeeded in doing a task better than another person (knowing above all that the context is not the same) give me the right to ridicule or criticize him/her beyond necessary? That's why I think the strategy suggested by m0zg may have limits... But again, this is the first time I'm confronted with this situation, so I don't really know.
Gibbon1 7y ago
Well and the old ugly code is known to work properly.

svaigs 7y ago

It will get old very quickly - they will soon realize that there are much better vacancies with better offers and move on. And author of this question will stay... bound by his insecurity of his unprofessionalism.

brianaluv 7y ago
>>And author of this question will stay... bound by his insecurity of his unprofessionalism. Could you elaborate?
- svaigs 7y ago
  I can't really understand what is the problem and why this has to be discussed. Coders suddenly don't write bad code because they are out of time - they write bad code because they can't write good code and they are out of time to learn how to write a good code. I would hire someone who would boast how he or she wrote excellent code in tight schedule. Because I've done that. And I have seen plenty of bad code and people who were making that code and could not improve even after a considerable time, because they were morons. Laughing about them is best thing you can do - worse if you have to cry, because they are still there. There are no good ways to deal with this type of bad coding if your company do not have laid foundation of good coding practices and don't follow them. Professionalism IMO means not only knowing how to code but also work experience on different working environments to understand the difference between good and bad workplaces and predict where things will go south(or great). The things you have described doesn't sound appealing to me - that would not motivate me to code or do anything. And it seems that your coworkers who moved on made a professionally better choice compared to you that is hurt by someone laughing at how things were done before. Just think about this in different light: new people are looking at you amicable - because criticism that they are making is friendly gesture. Your intentions on crushing this behavior is based in your insecurity. So, are you going to change them all... Again, question from dino - Why do you think that they have to change and not you?
  - m0zg 7y ago
    Why do you read "insecurity" in this situation? I don't read that at all. If anything it's the newcomers that are insecure - that's why they're putting down the people who wrote the code in the first place. In all likelihood they don't fully understand it (just because code is harder to read than it is to write), so the inclination is to excuse their own lack of progress by shitting on people who aren't there anymore and chalking it up to "bad codebase".