Hacker News Reader

Comment by V-2 | Hacker News Reader

"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".

View on HN

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.

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).

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.

His example makes perfect sense... when the "naive" implementation duplicates stuff over 100 or 200 LOC.

I've had joyful experience of working with duplicate code that spanned over multiple thousands of lines. I still fondly remember a PHP script generating multiple xml files, supporting different versions of format. (It was an e-commerce format for exporting and exchanging products data). And with multiple inconsistencies among this copy-pasta that have accumulated over time.

The problem here is the boiling frog syndrome. Duplication rarely starts with thousands of lines. It grows over time, and the longer you put up with it, the harder it becomes to roll it back. But as long as it grows slowly, the frog feels comfortable.

Clean code approach may get overzealous, the potential for fanaticism may even be sort of inherent to this approach (I agree), but it stems for acknowledging this simple, sad truth. The truth is that complexity of naive code is kind of like cancer. If you don't detect it before it actually begins to hurt, it's not great news.

I'm from the older generation. I don't agree with a lot of what's in clean code. Particularly the focus on micro unit tests. Nor do I like the moralising tone of the books author in general. Also flexibility comes at a cost. A codebase where everything is easy to change becomes complex in aggregate, such that nothing is easy to change.

Don't confuse Robert Martin's book "Clean Code" with the broader concept of clean code.

"A codebase where everything is easy to change becomes complex in aggregate"

What you're describing there is a code smell that is commonly referred to as "Speculative generality" and was written about in a book by Martin Fowler called "Refactoring, improving the design of existing code." Which, incidentally is a great companion book to Robert Martin's Clean Code.

Speaking of trendy medium articles, here is one that I wrote on the concept of clean code that might help better understand what I mean when I use the term:

https://medium.com/@gspencley/what-does-clean-code-mean-anyw...

Overly abstracted code can be difficult to read, comprehend, maintain and reason about.

Thousands of small methods spread through hundreds of FactoryFactoryFactories and Builders and Adapters and Visitors can become a maintenance nightmare.

Overly abstracted code, or code that is a maintenance nightmare, is not clean code.

It's almost like you didn't even ready my comment, or completely glossed over the "why do we write clean code" part. Clean code is code that is easy to understand and maintain. If you're describing the opposite then you're not describing clean code.

> 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.

> 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.

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]

> 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.

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."

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)

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?

I feel that a lot of discussions on those clickbaity titles are based on the title alone

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.

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

> 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 :)

"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.

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.

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

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."

Reply on news.ycombinator.com