4 ms·

> The obvious criticism here is that now any developer who wants to defend their code will simply claim a given spaghetti incident easily fit in their head. Th

> The obvious criticism here is that now any developer who wants to defend their code will simply claim a given spaghetti incident easily fit in their head. The thing is: that's just a bad defense. If the people who are going to be to maintaining it and working with it are saying it's bad code, it's bad. Even if this is the only developer who is going to maintain it for now (which itself is always a terrible idea), eventually someone else will take over, and the closest thing you have to that "someone else" is the rest of the current team. I'm having a hard time imaging someone seriously making this argument, who is not also: * Trying to establish themselves as the sole possible maintainer, so either the company can't fire them or is completely screwed if they ever leave, or: * Is a saying the rest of their team is just too stupid to work with In either case, this person is a massive liability, and the longer they are employed the more damage they'll do.

Dylan16807 6y ago
You're making a huge assumption that the discussion is one person disagreeing with the rest of the team. What if everyone but one says it fits in their head? What if you're just talking one on one, and have no idea how many team members it fits in the head of? What if the person who is criticizing the code will begrudgingly admit that it fits in their head, but still thinks it's too messy?
- gregmac 6y ago
  > What if everyone but one says it fits in their head? "It depends". If the one person is a junior it's maybe not a code issue (unless junior-level people are expected to maintain it). On the other hand if it's a skilled, experienced, senior person saying they can't follow it, there's likely an issue with the code. > What if you're just talking one on one, and have no idea how many team members it fits in the head of? > What if the person who is criticizing the code will begrudgingly admit that it fits in their head, but still thinks it's too messy? The greater point here is is that it's about code maintainability. "Fits in your head" is merely one proxy for that, not the actual goal. There are also hundreds of other things that lower code maintainability -- including being "messy", having bad names, poor or no inline documentation, no unit tests, and being "clever" -- and all of those are things that should be discussed and fixed. Presumably everyone involved are professionals and working in good faith. If they really can't come to consensus: sleep on it. Involve more people. Suggest alternatives. Pair up. Someone consistently on the losing side of these discussions -- whether they feel they're constantly dumbing down their code, or that the rest of the team is writing unmaintainable spaghetti nonsense -- should probably reflect on if this is the right team for them.

Dylan16807 6y ago

You're making a huge assumption that the discussion is one person disagreeing with the rest of the team. What if everyone but one says it fits in their head? What if you're just talking one on one, and have no idea how many team members it fits in the head of? What if the person who is criticizing the code will begrudgingly admit that it fits in their head, but still thinks it's too messy?

gregmac 6y ago
> What if everyone but one says it fits in their head? "It depends". If the one person is a junior it's maybe not a code issue (unless junior-level people are expected to maintain it). On the other hand if it's a skilled, experienced, senior person saying they can't follow it, there's likely an issue with the code. > What if you're just talking one on one, and have no idea how many team members it fits in the head of? > What if the person who is criticizing the code will begrudgingly admit that it fits in their head, but still thinks it's too messy? The greater point here is is that it's about code maintainability. "Fits in your head" is merely one proxy for that, not the actual goal. There are also hundreds of other things that lower code maintainability -- including being "messy", having bad names, poor or no inline documentation, no unit tests, and being "clever" -- and all of those are things that should be discussed and fixed. Presumably everyone involved are professionals and working in good faith. If they really can't come to consensus: sleep on it. Involve more people. Suggest alternatives. Pair up. Someone consistently on the losing side of these discussions -- whether they feel they're constantly dumbing down their code, or that the rest of the team is writing unmaintainable spaghetti nonsense -- should probably reflect on if this is the right team for them.