I think if it's so frequent that you're sick to your back teeth of listening to people complain about your code, it's probably a really sure sign that something is very wrong with the code.
I see the same thing even from my close colleagues. With one in particular, the first I'll even know he's using my code is when he bitches about it on Twitter. Forget about usable information in a bug report about what he did to trigger it (usually turns out to be utterly insane hacked configs), sometimes we've been talking on IRC and then I switch windows to find he's slagging the code on Twitter.
I think it's a cultural thing. Righteous anger is addictive. In this case it's anger at bad code, and the craving for another hit precedes any attempt to find out if the anger is even justified - let alone to work constructively toward a resolution. Some people (lots here BTW) are just rage junkies, and should simply be ignored.
I do as much as I try not to. I don't hold it against other people when their code has issues but I have never been able to not take that stuff personally when it is my code
One man's "readable code" is another person's trash. As the number of commiters in a codebase increases, the chances that you find at least one person's code to be an irritating annoyance increases exponentially.
The only way to avoid it is to have the political power to call out the team member that's annoying. Easy enough to do if you're the lead and nobody will question your decisions.
The worst and dumbest fights I've encountered is with people with 30 years of experience who have diametrically opposed opinions. I _especially_ despise having to call out very senior engineers when their own code misbehaves.
It's a common thing I see with programmers. I know I've been guilty of it before. I see some poorly coded module and I'm just disgusted of how bad it is and then proceed to say some of the nastiest things about the developer who wrote it, sometimes just aloud to myself, other times to my peers.
These days I do my best to try to remember we all make mistakes, and that instead of flaming whoever is responsible for a mistake when it rears its ugly head, it's probably best to take it as an opportunity to discuss what I saw as shortcomings in the code with them and turn it into a learning experience if possible. Sometimes of course this isn't possible when you inherit code from devs who are long gone. Either way, I'm not sure any good is done throwing all that negative energy into the air.
Yeah, I can agree with this. For me the scenario starts with reading somebody else's code and thinking it's horrendous. I'll then get this nagging feeling that the problem may instead be me not comprehending the code well enough, or not seeing the greater context in which the supposedly bad code is meant to sit. Frequently, after further investigation, the code turns out to be not as bad as I originally thought. It's almost like a judgement without all the facts / can't see the florist for the flowers kind of thing. I'm looking at that small piece of code through an aperture that blurs the bigger picture, if you widen it a little further you may see that the code was written in a certain way in order to coalesce with the rest of the code base. Or widen it further still and see that it was written poorly because it needed to be done quickly, but that poorly written code may have facilitated the first 1000 sales of the product. I won't listen to someone who trash talks another coder or a former employee for their work. It happened the other day at my job, the new guy trash talked some ops work belonging to the guy he replaced. That work has been keeping our site available for the past five years, still waiting for the new guy's road tested commits.
And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do know better than everyone else, but you ought to make damn sure of it before you open your mouth
I've met some people like this before, and I think this phenomenon has a lot to do with having one's identity closely bound to the code. Any criticism of the code is interpreted as a personal attack. Conversely, the attitude of "I'm so awesome therefore my code must be super important and really important to protect".
Do you not understand the emotional cruelty of trying to say all 6 things at once to someone who (in theory) is actually trying to contribute?
Maybe someone is not trying. Maybe you're wasting your breath then. Maybe someone is trying, but has an incomplete world view. Ok great, now you've pissed them off instead of saying what's wrong.
Just say what's wrong with the code! That's what actually matters. Not that you think it's garbage.
I think that another downside of badmouthing code is the effect on morale.
Who among is hasn't written code that, upon review, made us cringe? (Maybe a lot. Maybe just a bit.)
When you complain about code, instead of making constructive critiques, you aren't actually doing any one any good, least of all yourself. Instead, focus on what is good about the code and the opportunity to improve it that has just presented itself.
This blog makes an extremely good point. The industry we work in is very competitive and it's easy to get into the habit of making snarky comments about other people's code, even if you're actually not a jerk in real life. It's always good to remember that you should avoid doing this as often as possible.
Oh god, that sounds horrible. As a new dev, I already know that I don't know anything. I don't need hundreds of people pointing out every little flaw in my code.
It’s always awful. That means it’s never worth it to discuss how awful it is. You’re probably working with people who helped produce the awfulness, and it pays to be empathetic towards your coworkers.
Code isn’t produced in a vacuum and there are always external pressures for why this was hacked in rather than done correctly. It just kind of makes you come off as tone deaf and inexperienced. “My code is perfect and everyone else’s is garbage.” (It isn’t).
There are always concrete things that can be done to mitigate some of the awfulness and improve a codebase. A good developer will identify the root causes and fix them. Discuss and identify actual problems and solutions rather than your considerable (and understandable) angst.
If someone writes that kind of bug report for code that I write, the first thing I would do is take my shoe and beat myself to death. The man being frustrated is your fault. High chances there are million others who feel the same, at least he is conveying it to you. You're shooting the messenger here.
If your critics give up on you and stop telling you how much you suck and how much they hate you, that's a very bad place to be in.
It's certainly bad to get angry - I mentioned that there. I should clarify the anger happens when it's repeated more than on a one-off. E.g. if you have the same sloppy signs for 6 months (where I can tell by reading the code that you didn't even try to run your code locally), then I'm not learning anything and I'm getting frustrated because you're clearly not taking feedback to heart.
I try to avoid letting this show, but it's frustrating.
This is very scary human-like. I was a teaching assistant and asked students to fix issues in their code. They acknowledged these issues but submitted again the same erroneous code.
I recently had that experience as well... felt that the code was pretty terrible but didn't want to say anything as the new guy. Toiled at patching it for a month and a half before sitting down and having a talk with some of the more senior developers about my issues. Turns out that I kind of vocalized what a lot of people had been thinking and we rewrote it in less than half the number of lines in about 3 weeks. Not sure what the moral is here, other than that some code is bad.
reply