5 ms·

> he suggests we should make code as complex as possible I read no such thing. (Speaking of straw men...) instead, I read him saying that the alternative to SO

> he suggests we should make code as complex as possible I read no such thing. (Speaking of straw men...) instead, I read him saying that the alternative to SOLID was “Write simple code.” I think there’s room to criticize this essay, but that’s a bizarre one to lead with.

jancsika 6y ago
> instead, I read him saying that the alternative to SOLID was “Write simple code.” The part you missed is in the same sentence as the three words you quoted. "Instead I suggested to write simple code using the heuristic that it 'Fits In My Head'." 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 author even seems to acknowledge this line of attack in the next paragraph: > You might ask “Whose head?” For the purpose of the heuristic I assume the owner of the head can read and write idiomatic code in whichever languages are in play, and that they are familiar with the problem domain. If they need more esoteric knowledge than that, for instance knowing which of the many undocumented internal systems we need to integrate with to get any work done, then that should be made explicit in the code so that it will fit in their head. But that just protects against spaghetti made from esoteric know of internals. For example, in C a "big head" would still be able to justify using global variables (after all, that's idiomatic C), rolling their own buggy threading approach, and deeply nested side-effect based programming. I'd much prefer pointing big heads to the rule of "do one thing" than to ever read a response of the category, "Well, it fits in my head."
- lupire 6y ago
  Not defending the article at all, but "whose head" should be at least a code reviewer's head, ideally two.
  - alfonsodev 6y ago
    I believe that there are people that can handle more abstractions in their working memory, maybe up to 6 or 7 layers of abstraction, and there are people that can't go further than 3, before feeling lost. The "bigger heads" types will use SOLID or any other argument to justify a higher number of abstractions. While the other type will do the same to justify a lesser. At the end of the day, there is no right solution, but what is so called "cultures" that group people with similar taste and cognitive fingerprint, and provide best practices.
  - Pxtl 6y ago
    Yup. As a PR reviewer, my gold standard is "I understand 100% of what's going on in this change, and I'm confident it does what it says it does". All the rules and standards and stuff we put in place is basically in support of that goal. If I can't understand it, neither can the next guy.
- refactor_master 6y ago
  Fits in my head and works on my computer. slaps on hood
- gregmac 6y ago
  > 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.

jancsika 6y ago

> instead, I read him saying that the alternative to SOLID was “Write simple code.” The part you missed is in the same sentence as the three words you quoted. "Instead I suggested to write simple code using the heuristic that it 'Fits In My Head'." 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 author even seems to acknowledge this line of attack in the next paragraph: > You might ask “Whose head?” For the purpose of the heuristic I assume the owner of the head can read and write idiomatic code in whichever languages are in play, and that they are familiar with the problem domain. If they need more esoteric knowledge than that, for instance knowing which of the many undocumented internal systems we need to integrate with to get any work done, then that should be made explicit in the code so that it will fit in their head. But that just protects against spaghetti made from esoteric know of internals. For example, in C a "big head" would still be able to justify using global variables (after all, that's idiomatic C), rolling their own buggy threading approach, and deeply nested side-effect based programming. I'd much prefer pointing big heads to the rule of "do one thing" than to ever read a response of the category, "Well, it fits in my head."

lupire 6y ago
Not defending the article at all, but "whose head" should be at least a code reviewer's head, ideally two.
- alfonsodev 6y ago
  I believe that there are people that can handle more abstractions in their working memory, maybe up to 6 or 7 layers of abstraction, and there are people that can't go further than 3, before feeling lost. The "bigger heads" types will use SOLID or any other argument to justify a higher number of abstractions. While the other type will do the same to justify a lesser. At the end of the day, there is no right solution, but what is so called "cultures" that group people with similar taste and cognitive fingerprint, and provide best practices.
- Pxtl 6y ago
  Yup. As a PR reviewer, my gold standard is "I understand 100% of what's going on in this change, and I'm confident it does what it says it does". All the rules and standards and stuff we put in place is basically in support of that goal. If I can't understand it, neither can the next guy.
refactor_master 6y ago
Fits in my head and works on my computer. slaps on hood
gregmac 6y ago
> 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.