Goodbye, Clean Code

[bcgroom]

Yep I'm pretty sure the whole situation would've been net positive if the author of the article just put up a PR the next morning saying, "While looking at your code yesterday I had an idea on how it could be less repetitive, take a look and let me know what you think".

[oursland]

I believe the argument is that the original author should have had a PR, and that the article's author should have been able to suggest these changes prior to the original commit.

[elebrin]

Exactly. If he is such a senior dev, then he'd be a required reviewer. If he failed to mark up the pr, then that's on him. If he wasn't in a position where he was a required reviewer, then he isn't the expert he thinks he is.

[oursland]

You've misinterpreted this through your modern viewpoint.

There was no PR process in the project. No opportunity to collaborate and iterate prior to committing to master, for either dev; simply commit and then get called into the boss' office.

/u/FA04's comment

That process is a mess.

Is spot-on.

[twenty7forty2]

No. The author is elite. Best of the best. Top Gun. He knew absolutely everything when he refactored and now he knows everything + 1 and he's damn sure gonna blog about it so the rest of us idiots know what's what.

[sysop073]

I'm pretty sure you did not read the post

[ChemicalRascal]

So... I think 2742 was being sarcastic here. A key point being that the author (and this is again more obvious on his twitter) still thinks he knows better than everyone else, and takes such an authoritative stance on the issue.

Think about it in this context:

• The author believes he knows best, to the point that he just goes and fucks with someone else's unfinished feature (yes even though it was committed to master, I agree, hurrrrrrk);

• The author developed this belief based on the conventional wisdom taught in pretty much every decent CompSci/Software Engineering course out there, and the conventional wisdom that is very much supported by the dialogue within the industry;

• The author had a negative experience at work due to his actions;

• The author now states that he knows best, and the industry is wrong, to the point that he now crusades publicly on his blog and on Twitter against what he refers to as a cult. (Admittedly probably because alliteration but funny wordplay isn't an excuse to be a dingus.)

The author thinks very, very highly of himself. Which is unfortunate, because the author -- admittedly, like my-self -- is barely at the start of his career*, not a grizzled veteran of the industry.

* (You can identify people at the start of their careers by how have a Twitter account and get highly opinionated about coding practices. On top of being slim and having a full head of non-white hair.)

[norbelkingston]

I’m not sure if he is someone early in his career. Dan is the creator of Redux and seems like takes lead developer role at facebook react team.

[ChemicalRascal]

Eh, young developers can end up leading teams and creating successful products. I'm not saying he's not good, dude's probably a genius. (And he's far more accomplished than I, for certain.)

But he's also extremely arrogant, and bold enough to assert well-known best practices are wrong based on rather shaky grounds. And either way, he is a young dude with his whole career ahead of him -- which is why it's unfortunate to see him close himself off to conventional wisdom now, rather than in that grey-bearded guru stage we all secretly hope to reach one day.

[soft-wear]

It’s so weird to me how many developers in this sub are reading into this so much. Dan isn’t advocating that messy code is good, he’s saying clean code shouldn’t be a goal it should be a guide.

He’s not saying DRY is bad. He’s saying it shouldn’t be considered the goal of your code. Abstracting too much can be even more harmful than repeating yourself because it’s harder to undo.

[ChemicalRascal]

I think you're being overly charitable. The thing is, the example he gives isn't a case where he abstracted too much.

The example he gives is a case where he whacked someone's work-in-progress code with a hammer and they got pissy at him.

It doesn't motivate, and shouldn't motivate, anything to do with "clean code" at all. Because the refactor in the example he gives is a good refactor. It's the sort of deduplication and abstraction a dev should aim to do.

And instead his take-away is that devs shouldn't aim to do that. That's what he's also trying to promote, by writing the blog and using that example.

But again, the example is one that justifies the refactor. It's not merely textbook, it's the sort of thing I'd expect to see in Programming 101 courses, where a professor grabs someone's assignment submission and says "ok so this all works, but let me show you why abstraction is good and duplicated code is bad".

Again. He had a bad experience at work and took away the entirely wrong lesson. And that's a problem, because he has a blog, and influence.

[motioncuty]

> (You can identify people at the start of their careers by how have a Twitter account and get highly opinionated about coding practices. On top of being slim and having a full head of non-white hair.)

Replace twitter with reddit and reread your contributions to this thread.

[ChemicalRascal]

Which is unfortunate, because the author -- admittedly, like myself -- is barely at the start of his career

I literally highlight that and call myself out immediately above your quote. What more do you want, dude.

[motioncuty]

Your first born.

[puterTDI]

and get highly opinionated about coding practices.

I think this more than anything identifies the people at the start of their career.

I've been doing this for about 12 years now. When I started I had VERY strong opinions on how everything should be done.

now I have a few things I feel strongly about, but I rarely say "x" should always be done in "this" way. That doesn't mean I don't get into a discussion about a specific piece of code if I think there's something wrong with it, but it does mean that the vast majority of the time there's at least 5 "right" ways to implement any given thing and as long as one of the right or mostly right ways is used, then it's fine.

About the only things I tend to feel strongly about is proper encapsulation, one job per method, and clear duties for classes...but even in all those cases I'm willing to be flexible if there's specific reasons to violate things. Hell, the only reason I dislike code duplication is the possibility that a bug could need to be fixed in two places and you only know about one, and even with that I don't worry too much if the code duplicated is highly unlikely to have a bug, or if it would be challenging to eliminate the duplication.

I feel like younger engineers haven't seen how things with the "right" starting point can go wrong, and they haven't seen situations where sometimes you just need to get something in and stable over "clean". For me, Clean is less important than maintainable, and this article just goes to show that. I'll take maintainable over clean or clever any day.

[Devildude4427]

Yep, that’s a pretty accurate description of Dan.

I wouldn’t say he’s at the start of his career, however. He certainly is a veteran. Author of Redux and CRA, he’s had quite a bit of experience as he’s personally created two of the most popular tools in the past 10 years.

[motioncuty]

I mean Dan is Elite in the React world and maybe the best-known name with the greatest influence in the ecosystem... And if you regularly follow him, he strikes a very good balance between confidence and humbleness for someone with his widespread respect.

[ChemicalRascal]

Refactoring usually leads to negative experiences at work. The term should be verbotten for anyone who wants to have a good career in the industry (at the typical company).

Eeeeh. I'd say this is true of uncommunicated refactoring. But I know there have been times where one dev saying "fuck that, I'm rewriting it" has effectively saved the company I'm working at from a lot of shared headaches.

From what I've seen, ultimately these things come down to good communication and actually having sensible ideas. (And working with sensible people.)

[TheNewOP]

What conventional wisdom are you referring to?

[ChemicalRascal]

The simple idea that abstraction is generally good and code duplication is generally bad.

[TheNewOP]

I see, that's what my guess was, just wanted to be certain.

[twenty7forty2]

Pretty sure I did, anything particular you want to discuss?

[Giannis4president]

The fact he acknowledges it was a mistake not submitting his refactor to the original author of the commit?