5 ms·

"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t belie

by V-2 5y ago

"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Code [...] Don’t be a clean code zealot" I agree with choosing pragmatism over purism. But the clickbaity title exercises a pattern I've seen hundreds of times, to which I have frankly become a bit allergic over the years: "X considered harmful! ...I mean, if you're overdoing X". Not being a healthy food zealot doesn't equal "goodbye, healthy food".

AnimalMuppet 5y ago
Well... you're right. But humans have a tendency to become zealots. They (we) take a good thing, and make it The One True Thing(TM). It happens with many people with many different things. It seems to just be human nature. So it may be good to remind ourselves "Hey, this is just a thing. Use it when it makes sense, and don't overdo it."
deleted 5y ago
[deleted]
sombremesa 5y ago
HN has a lot of people who seem to benefit from these types of “common sense” articles that bury the lede, judging by the fact they appear on the front page so frequently. (Putting common sense in scare quotes to acknowledge that this is new information to some, no matter how obvious to others)
- leoc 5y ago
  I'd suspect it's more a matter of people enjoying the sense of validation they get from an article which tells them that the low standards they're accustomed to from work are good, actually.
- vletal 5y ago
  Is it really the case? Could it maybe be that these clickbeity titles are upvoted and comment on more, regardless of the questionable added value to the community "burried" deep inside?
  - FalconSensei 5y ago
    I feel that a lot of discussions on those clickbaity titles are based on the title alone
- MaxBarraclough 5y ago
  I'd put it differently: HackerNews has an immune system to defend against low-quality submissions, including articles with clickbait titles, but it's imperfect. (As dang puts it, we're trying for something different than internet default here. [0]) [0] https://news.ycombinator.com/item?id=29153668 https://news.ycombinator.com/item?id=29153668
thinkharderdev 5y ago
Yeah, "don't overdo X" is always true by definition. That is what "overdo" means. Likewise "don't be an X zealot" is always true by definition (based on how we use the term zealot in modern English). That said, despite the clickbait title, I think these sorts of posts make a valid point because people often do in fact take heuristics like DRY to mean "never repeat any code under any circumstances and any code repetition is per se bad."
PragmaticPulp 5y ago
> While undeniably true, this feels completely orthogonal to the question of clean code. I think this mentality and the Clean Code Movement (with capital Cs) actually have a lot in common. Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things. Anyone who does things differently is doing things the wrong way. There is a subset of programmers who are attracted to these movements because it can feel like a free license to feel superior to your peers. Once you understand all of the rules and intricacies of the Clean Code Movement, it can feel like a free pass to push the Clean Code rules on to others and the codebase. No need for code review or consultation, because you've already decided that the Clean Code Way is the right way and therefore there isn't anything to discuss.
- mdoms 5y ago
  > Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things Well if this is the case then they certainly didn't get it from the Clean Code book itself. The books very explicitly makes the point that there's no one right way and that the guidelines in the book won't apply to every situation.
  - Jtsummers 5y ago
    That's in the first chapter. I'll quote it here because it seems many of the objectors to the book haven't read it or haven't read this part: > Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don't make the mistake of thinking that we are somehow "right" in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well. [emphasis in original]
- drewfis 5y ago
  > No need for code review or consultation, because you've already decided that the Clean Code Way is the right way and therefore there isn't anything to discuss. I liken the CC movement to religion - it has good intentions, but when taken too far you end up with a holier-than-thou attitude.
theptip 5y ago
> this feels completely orthogonal to the question of clean code. For me, one of the interesting points of the article is not just that the replacement code was inferior, it's the recognition that the emotional compulsion to "clean up the dirty code" was a problem in itself. Sure, as you say, if you refactored it in the other direction in this would also be problematic -- but there aren't many people who feel a visceral emotional compulsion to refactor code to make it less "clean". (Maybe brainfuck aficionados? Anyway, a rare breed.) So I think there's something about the concept of "neat/clean code" that asymmetrically/directionally produces this error, and I took the "goodbye" to be giving up on this compulsive attachment to the concept of "all code must be cleaned", rather than saying that the concept of clean code shouldn't be used anywhere. The money quote being: > Am I saying that you should write “dirty” code? No. I suggest to think deeply about what you mean when you say “clean” or “dirty”. Do you get a feeling of revolt? Righteousness? Beauty? Elegance? How sure are you that you can name the concrete engineering outcomes corresponding to those qualities? How exactly do they affect the way the code is written and modified? It's really more about identifying the feelings that "dirty" code produces and realizing that they might lead you astray. > "X considered harmful! ...I mean, if you're overdoing X" I'm 100% on board with the general objection to this kind of thing, it's a pet peeve that I share. I just didn't get triggered by this one :)
- V-2 5y ago
  "For me, one of the interesting points of the article is not just that the replacement code was inferior, it's the recognition that the emotional compulsion to "clean up the dirty code" was a problem in itself." That's certainly a valid observation and a good point. I think the article would benefit if it the author analyzed this aspect more.
deeviant 5y ago
They author didn't focus on the rewriting without checking with their coworker part of the lesson, and I'm not sure why you are. It felt like they added it because it was part of the truth and mentioning is honest, but the bulk of the article was on the actual code changes he made, why they thought it was a good software engineering as a their younger self and why they no longer think it was good software engineering now. I really don't see your point about the article being linkbait-y at all.
_zachs 5y ago
Agreed! The article seems more geared towards a lesson teaching teamwork and not being a code cowboy than about clean code.
gspencley 5y ago
The thing that bothers me about conversations in opposition to "best practices" or "clean" code" is that it misses the pragmatic aspect of those concepts. WHY do we write clean code? Because the value of software is its ability to CHANGE. Otherwise we would stick with fixed circuits. Best practices and clean code don't exist in a vacuum and they are not floating abstractions that developers should throw around as if everyone is on the same page with respects to what they mean. They are a set of quality standards that allow for the rapid development, adaptability and ease of maintenance as a codebase evolves over time. Clean code does not exist to slow or hinder development, or to handicap junior developers. It exists to maintain a team's velocity as the scope and scale of the project increases. Clean code is one of the crucial tools in the toolbox for avoiding death march projects. It it is not the only tool: an efficient management process, feedback loop, QA cycle, deployment process etc. are all critical as well. It is a team effort and code quality is the part that rests directly on the shoulders of the developers. The one and only part of the blog/article that I agree with is the part about refactoring without making it a teaching moment for the dev who wrote it. That part implies they weren't doing code reviews, another crucial element in the quality control of the product being developed. It blows my mind that these conversations are so often misunderstood. Us old timey senior devs have a professional obligation to make sure that the younger generation understands these concepts. Why do we see so many trendy medium articles and blog posts that seem to want to throw decades of hard learned lessons out the window? I blame the older generation for failing the younger ones. This stuff is not self-evident and has to be taught.
- superjan 5y ago
  In the article the author said that his “cleaner” version had less duplicate code, but was harder to adapt to new usecases. His point is that clean looking code is sometimes harder to change, because while cleaning people introduce abstractions or assumptions that hinder new usecases rather than facilitating them. The right way to keep code maintainable is not always self evident, and not necessarily always clean (which I interpret as SOLID, deduplicated).
  - gspencley 5y ago
    I didn't miss that, I just chose not to address it for brevity. The problem that highlights is both a process and an experience problem. It indicates that he did not have a clear picture of the development road-map for the project, which suggests there are silos of information. There were a lot of hints about this actually. The lack of code reviews (that's where the original dev's opportunity for quality improvement should have been caught and addressed), the fact that a manager would chastise him for trying to improve code quality and the fact that he made poor design choices when trying to improve said quality really does point to a dysfunctional process. Pointing the finger at code quality here is failing to understand the difference between the trees and the forest.

by V-2 5y ago

AnimalMuppet 5y ago

Well... you're right. But humans have a tendency to become zealots. They (we) take a good thing, and make it The One True Thing(TM). It happens with many people with many different things. It seems to just be human nature. So it may be good to remind ourselves "Hey, this is just a thing. Use it when it makes sense, and don't overdo it."

deleted 5y ago

[deleted]

sombremesa 5y ago

HN has a lot of people who seem to benefit from these types of “common sense” articles that bury the lede, judging by the fact they appear on the front page so frequently. (Putting common sense in scare quotes to acknowledge that this is new information to some, no matter how obvious to others)

leoc 5y ago
I'd suspect it's more a matter of people enjoying the sense of validation they get from an article which tells them that the low standards they're accustomed to from work are good, actually.
vletal 5y ago
Is it really the case? Could it maybe be that these clickbeity titles are upvoted and comment on more, regardless of the questionable added value to the community "burried" deep inside?
- FalconSensei 5y ago
  I feel that a lot of discussions on those clickbaity titles are based on the title alone
MaxBarraclough 5y ago
I'd put it differently: HackerNews has an immune system to defend against low-quality submissions, including articles with clickbait titles, but it's imperfect. (As dang puts it, we're trying for something different than internet default here. [0]) [0] https://news.ycombinator.com/item?id=29153668 https://news.ycombinator.com/item?id=29153668

thinkharderdev 5y ago

Yeah, "don't overdo X" is always true by definition. That is what "overdo" means. Likewise "don't be an X zealot" is always true by definition (based on how we use the term zealot in modern English). That said, despite the clickbait title, I think these sorts of posts make a valid point because people often do in fact take heuristics like DRY to mean "never repeat any code under any circumstances and any code repetition is per se bad."

PragmaticPulp 5y ago

> While undeniably true, this feels completely orthogonal to the question of clean code. I think this mentality and the Clean Code Movement (with capital Cs) actually have a lot in common. Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things. Anyone who does things differently is doing things the wrong way. There is a subset of programmers who are attracted to these movements because it can feel like a free license to feel superior to your peers. Once you understand all of the rules and intricacies of the Clean Code Movement, it can feel like a free pass to push the Clean Code rules on to others and the codebase. No need for code review or consultation, because you've already decided that the Clean Code Way is the right way and therefore there isn't anything to discuss.

mdoms 5y ago
> Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things Well if this is the case then they certainly didn't get it from the Clean Code book itself. The books very explicitly makes the point that there's no one right way and that the guidelines in the book won't apply to every situation.
- Jtsummers 5y ago
  That's in the first chapter. I'll quote it here because it seems many of the objectors to the book haven't read it or haven't read this part: > Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don't make the mistake of thinking that we are somehow "right" in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well. [emphasis in original]
drewfis 5y ago
> No need for code review or consultation, because you've already decided that the Clean Code Way is the right way and therefore there isn't anything to discuss. I liken the CC movement to religion - it has good intentions, but when taken too far you end up with a holier-than-thou attitude.

theptip 5y ago

> this feels completely orthogonal to the question of clean code. For me, one of the interesting points of the article is not just that the replacement code was inferior, it's the recognition that the emotional compulsion to "clean up the dirty code" was a problem in itself. Sure, as you say, if you refactored it in the other direction in this would also be problematic -- but there aren't many people who feel a visceral emotional compulsion to refactor code to make it less "clean". (Maybe brainfuck aficionados? Anyway, a rare breed.) So I think there's something about the concept of "neat/clean code" that asymmetrically/directionally produces this error, and I took the "goodbye" to be giving up on this compulsive attachment to the concept of "all code must be cleaned", rather than saying that the concept of clean code shouldn't be used anywhere. The money quote being: > Am I saying that you should write “dirty” code? No. I suggest to think deeply about what you mean when you say “clean” or “dirty”. Do you get a feeling of revolt? Righteousness? Beauty? Elegance? How sure are you that you can name the concrete engineering outcomes corresponding to those qualities? How exactly do they affect the way the code is written and modified? It's really more about identifying the feelings that "dirty" code produces and realizing that they might lead you astray. > "X considered harmful! ...I mean, if you're overdoing X" I'm 100% on board with the general objection to this kind of thing, it's a pet peeve that I share. I just didn't get triggered by this one :)

V-2 5y ago
"For me, one of the interesting points of the article is not just that the replacement code was inferior, it's the recognition that the emotional compulsion to "clean up the dirty code" was a problem in itself." That's certainly a valid observation and a good point. I think the article would benefit if it the author analyzed this aspect more.

deeviant 5y ago

They author didn't focus on the rewriting without checking with their coworker part of the lesson, and I'm not sure why you are. It felt like they added it because it was part of the truth and mentioning is honest, but the bulk of the article was on the actual code changes he made, why they thought it was a good software engineering as a their younger self and why they no longer think it was good software engineering now. I really don't see your point about the article being linkbait-y at all.

_zachs 5y ago

Agreed! The article seems more geared towards a lesson teaching teamwork and not being a code cowboy than about clean code.

gspencley 5y ago

The thing that bothers me about conversations in opposition to "best practices" or "clean" code" is that it misses the pragmatic aspect of those concepts. WHY do we write clean code? Because the value of software is its ability to CHANGE. Otherwise we would stick with fixed circuits. Best practices and clean code don't exist in a vacuum and they are not floating abstractions that developers should throw around as if everyone is on the same page with respects to what they mean. They are a set of quality standards that allow for the rapid development, adaptability and ease of maintenance as a codebase evolves over time. Clean code does not exist to slow or hinder development, or to handicap junior developers. It exists to maintain a team's velocity as the scope and scale of the project increases. Clean code is one of the crucial tools in the toolbox for avoiding death march projects. It it is not the only tool: an efficient management process, feedback loop, QA cycle, deployment process etc. are all critical as well. It is a team effort and code quality is the part that rests directly on the shoulders of the developers. The one and only part of the blog/article that I agree with is the part about refactoring without making it a teaching moment for the dev who wrote it. That part implies they weren't doing code reviews, another crucial element in the quality control of the product being developed. It blows my mind that these conversations are so often misunderstood. Us old timey senior devs have a professional obligation to make sure that the younger generation understands these concepts. Why do we see so many trendy medium articles and blog posts that seem to want to throw decades of hard learned lessons out the window? I blame the older generation for failing the younger ones. This stuff is not self-evident and has to be taught.

superjan 5y ago
In the article the author said that his “cleaner” version had less duplicate code, but was harder to adapt to new usecases. His point is that clean looking code is sometimes harder to change, because while cleaning people introduce abstractions or assumptions that hinder new usecases rather than facilitating them. The right way to keep code maintainable is not always self evident, and not necessarily always clean (which I interpret as SOLID, deduplicated).
- gspencley 5y ago
  I didn't miss that, I just chose not to address it for brevity. The problem that highlights is both a process and an experience problem. It indicates that he did not have a clear picture of the development road-map for the project, which suggests there are silos of information. There were a lot of hints about this actually. The lack of code reviews (that's where the original dev's opportunity for quality improvement should have been caught and addressed), the fact that a manager would chastise him for trying to improve code quality and the fact that he made poor design choices when trying to improve said quality really does point to a dysfunctional process. Pointing the finger at code quality here is failing to understand the difference between the trees and the forest.