4 ms·
I was at a conference once where they ran a contest that had people who'd never worked together pair-programming a solution to a problem neither of them was an
by eric_the_read 13y ago
I was at a conference once where they ran a contest that had people who'd never worked together pair-programming a solution to a problem neither of them was an expert in. After a period of time, the various pairs presented their solutions to a jury.
One of the pairs started off with a member saying, "Okay, this code is kind of shit, but it's the best we could do," or words to that effect. (It was 5 or 6 years ago; I can't recall precisely what was said.)
The reply from one of the jurors has stuck with me ever since. Paraphrasing, it was something like, "Don't ever say that about your own code. Remember, at some point, you will always work with someone more junior than you. If they hear you commenting like that about your own code, they're going to be much more reluctant to approach you about problems they're having with their own."
It's partly about having a certain level of professionalism, but it's also about trying to create an environment where people feel comfortable asking questions about code they're unsure about, without feeling like they're going to be attacked. Even if you don't mean it that way!
- m1117 13y agototally agree on that, was trying to criticize correlation with sexism
- moron4hire 13y agoSexism isn't "man belittles woman". It's assigning traits to sex in such a way to make people feel uncomfortable. A man telling another man to "man up" is just as sexist, as it implies a questioning of the second man's sexuality.
- orclev 13y agoIf I write shit code (and I do, because at some point we all do) and for whatever reason I can't fix it (usually time crunch) I call it out even if it's just a comment in the code to say "this is a terrible hack, don't do this". It's important to recognize when code is less than ideal or when you write something that you know you could do better if you had more time to research and think about the solution. Part of becoming a good developer is learning to accept criticism of code not as an attack on the developer but as recognition that there's always room to improve on things and that no one is perfect. It's also about recognizing that sometimes you just have to accept "good enough" and move on even if you'd really like to go for "perfect". At the same time you don't want to throw away your standards and just settle for anything that gets the job done if you don't absolutely need to, which is why calling out kludges and shit code when you (or someone else) writes it is important. Now don't get me wrong, I'm more than happy to call my shit code shit, but I'd at least try to be more tactful of someone else's code.
- eric_the_read 13y agoOh, I am certain to write code that could be described as "shit" from time to time as well. But for myself, in that situation I try to say, "this is pretty suboptimal, we have better solutions, but not enough time for them right now." as opposed to "yeah, this is kinda shit." Definitely we don't want developers who are so precious about their code that they can't handle a little criticism, but there are, IMO, better ways and worse ways to deliver that criticism. Think of it like a judge on Iron Chef-- the worst kind of criticism you can give a dish is, "this is terrible". Only slightly less worse is, "this is wonderful!" Ideally, you need reviews like, "This has a bit too much cinnamon, and I think you way overdid the cumin, but overall this is the best shrimp I've had this week."