Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Clean Code (2020)

overreacted.io

Post reply on HN
Print view View original

211–220 of 224 posts

Re: Goodbye, Clean Code (2020)

#211

Post by redisman »

the_only_law wrote: post #192
gpderetta wrote: post #31

Earlier quoted context omitted.

Premature abstraction is the root of all evil.

I cost myself a position recently arguing about this. I had a first round interview that went well, and was given a take home and the problem was very simple, dead simple. In turn I tried to keep the code as simple as possible, with only necessary abstractions. The second interview was with an entirely different person who seemed displeased I didn’t bloat the solution with all sorts of enterprise patterns, dependenci…

That would be your everyday experience. No reason to not be picky right now. I would go crazy having to work with over-abstract code for OOP religions sake

Re: Goodbye, Clean Code (2020)

#213

Post by redisman »

marginalia_nu wrote: post #54

As a bit of a tangent. I've been a bit of an apologist. I thought maybe people just took clean code a bit too far, that people were being too dogmatic about what was basically sound advice. Then I found Uncle Bob's old website the other night and I can no longer deny he's had a finger in this. > _Anything not testable is useless._ > Here's the thing. If you can't test it, you don't know that it works. If you don't kn…

One of the best engineering (and life) tips I’ve learned is to beware anyone selling silver bullets

Re: Goodbye, Clean Code (2020)

#214

Post by jonno123 »

Why didn't he replace each one of: "// 10 repetitive lines of math" with: "doRepetitiveMath()" ?

Sounds like he did a lot more than eliminate duplication, and perhaps that's what his boss was unhappy about.

Re: Goodbye, Clean Code (2020)

#215

Post by DeathArrow »

gspencley wrote: post #178
V-2 wrote: post #13

"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 Co…

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…

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.

Re: Goodbye, Clean Code (2020)

#217

Post by V-2 »

theptip wrote: post #152
V-2 wrote: post #13

"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 Co…

> 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 visce…

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

Re: Goodbye, Clean Code (2020)

#218

Post by V-2 »

superjan wrote: post #197
gspencley wrote: post #178

Earlier quoted context omitted.

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…

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 (wh…

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.

Re: Goodbye, Clean Code (2020)

#219

Post by DeathArrow »

the_only_law wrote: post #192
gpderetta wrote: post #31

Earlier quoted context omitted.

Premature abstraction is the root of all evil.

I cost myself a position recently arguing about this. I had a first round interview that went well, and was given a take home and the problem was very simple, dead simple. In turn I tried to keep the code as simple as possible, with only necessary abstractions. The second interview was with an entirely different person who seemed displeased I didn’t bloat the solution with all sorts of enterprise patterns, dependenci…

>In turn I tried to keep the code as simple as possible, with only necessary abstractions.

I always talked the talk and walked the walk for the interviews. I know people love Solid, design patterns, Dry, OOP, Restful, Clean Code, complicated architectures. So I am always willing to talk about these and even sprinkle the discussion with the most obscure design patterns they may never heard of.

Yes, I do consider some of these being fads or even detrimental to good software but my goal was to be employed, not to convince people that there is not only one True Way.

Re: Goodbye, Clean Code (2020)

#220

Post by DeathArrow »

ncmncm wrote: post #196
the_only_law wrote: post #192

Earlier quoted context omitted.

I cost myself a position recently arguing about this. I had a first round interview that went well, and was given a take home and the problem was very simple, dead simple. In turn I tried to keep the code as simple as possible, with only necessary abstractions. The second interview was with an entirely different person who seemed displeased I didn’t bloat the solution with all sorts of enterprise patterns, dependenci…

Looks to me like you dodged a bullet.

Yes, but it is hard to find teams who are not into abstracting for abstracting sake.
Post reply on HN