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

61–70 of 224 posts

Re: Goodbye, Clean Code (2020)

#61

Post by lowercased »

shikoba wrote: post #14
breckenedge wrote: post #3

This article really buries the most important lesson about refactoring: > 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. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

Years ago (2005?) I worked at a call center. Most agents were on one coast - data center was in another coast. Agents in our call center complained about speed. When they'd pull up an account, it was taking seconds... sometimes 15-20 seconds... to pull up the account.

This was all a bespoke CRM system. I poked in the code (it was something I had access to) and noticed that ... the entirety of the whole screen was duped - the output of the client's history was embedded in an HTML comment tag. So... if the client had, say, 3 years of info/comments, it was rendered, then rendered again in HTML comments. It was a single line duplicating the entirety of the info. It was obviously a debug remnant. I removed it. I tried to talk to the original developer beforehand - he was on the phone, and kept waving me off. I emailed him. No answer. I committed it and got it to a testing server. The test guy immediately loved the speed improvement, and we got it out to the floor. There were about ... 50-70 agents live at any one time, and everyone's hold/wait times were cut by 20-30% overnight. Clients and agents were happier. I found out later that, over time, we cut bandwidth bills by a measurable amount.

I was raked over the coals and nearly fired for that. "unprofessional", "insulting", etc. It was primarily because I'd made someone else look bad. Other people on the team also made changes now and then to each others' code without asking permission, when it was needed/obvious (emergencies/etc). It was a simple oversight in removing some debug code, and it made a huge difference (it had been tested and had other eyes on it as well - this wasn't "change prod by hand without telling anyone").

Still bugs me to this day (as you can tell).

Re: Goodbye, Clean Code (2020)

#62

Post by Dudeman112 »

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…

And yet, at least for the quoted part, he is right.

It requires some massive balls to deploy code to production while not even seeing if it works for any case.

If the answer to "how do you know it works?" is "trust my judgement bro" then I will not, in fact, trust their judgement.

I do agree he has a finger in the zealotry and he should probably have modulated how he expressed himself.

Re: Goodbye, Clean Code (2020)

#63

Post by datavirtue »

UglyToad wrote: post #11

This seems close to illustrating a thought I've been toying with turning into a blog post but need some more examples of before I do: "Abstract over data, not behaviour" This seems to fall into the trap of abstracting over behaviour. The best other example I've thought of for this is the 'generic repository pattern' common in C# and I'd guess Java. Just because CRUD on types is all similar behaviour you can't really…

In this case the abstraction should be designed so as to invite/welcome custom functionality. The domain/entity repo should extend a generic crud repo--as they usually do in my experience.

Re: Goodbye, Clean Code (2020)

#64

Post by ThaJay »

regnull wrote: post #25

Having duplication does not mean your code is not clean. Sometimes, having duplication is actually cleaner, and easier to understand. Removing duplication may introduce complexities, and force developers to untangle the additional logic that was introduced to remove dupes. Good duplication means code just happened to be the same in a few places (but it can be potentially different). It's fine and easy to read. On the…

>just happened to be the same >MUST be the same

This difference is something important to stress.

Re: Goodbye, Clean Code (2020)

#65

Post by marginalia_nu »

Dudeman112 wrote: post #62
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…

And yet, at least for the quoted part, he is right. It requires some massive balls to deploy code to production while not even seeing if it works for any case. If the answer to "how do you know it works?" is "trust my judgement bro" then I will not, in fact, trust their judgement. I do agree he has a finger in the zealotry and he should probably have modulated how he expressed himself.

You know, they sent people to the moon using software written before the unit test paradigm.

Re: Goodbye, Clean Code (2020)

#66

Post by lowercased »

sigzero wrote: post #17
shikoba wrote: post #14

Earlier quoted context omitted.

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

If they were still there, why wouldn't you engage them about a modification you think was better than the original? Everyone learns in that situation.

they may not be 'on that project' any more, and if the burden of support is on you at that point, and you're the one dealing with the code, and they're not, them saying "meh, it was good enough" doesn't really help. I've hit that before, and mgrs have said "devX said it's good enough, they wrote it before, don't try to change stuff". Well.. they wrote it 2 years ago when there were 300 customer records, not the 14200 today, and they're not fielding support issues from people complaining about delays now.

There's plenty of reasons to not engage with someone. There's also plenty of reasons why it may make sense, and I think it's highly context dependent. For me, it's about 50/50. And... in the cases where I reach out, it's about 50/50 as to whether they have any time/inclination/memory/ability to help anyway.

Re: Goodbye, Clean Code (2020)

#67

Post by shikoba »

lowercased wrote: post #61
shikoba wrote: post #14

Earlier quoted context omitted.

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

Years ago (2005?) I worked at a call center. Most agents were on one coast - data center was in another coast. Agents in our call center complained about speed. When they'd pull up an account, it was taking seconds... sometimes 15-20 seconds... to pull up the account. This was all a bespoke CRM system. I poked in the code (it was something I had access to) and noticed that ... the entirety of the whole screen was dup…

You mailed the original developer, he didn't answer. And you were fired for doing your job right. What you must conclude is that they don't care about quality but about ego. They have a philosophy that don't favor quality. You should be glad they fired you.

Re: Goodbye, Clean Code (2020)

#68

Post by baq »

RbrtM wrote: post #36

Clean code vs dirty code is not a problem here. Rewriting someone else's code (no matter how dirty) without telling or consulting was the bigger mistake. This can poison professional relationships for life.

that relationship arguably deserves to be poisoned, it's a relationship between toddlers instead of engineers.

Re: Goodbye, Clean Code (2020)

#69

Post by shikoba »

RbrtM wrote: post #38
shikoba wrote: post #14

Earlier quoted context omitted.

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

If I ever see you again rewrite someone else's code without asking, I will fire you on the spot.

So deluded. :D

Re: Goodbye, Clean Code (2020)

#70

Post by baq »

RbrtM wrote: post #38
shikoba wrote: post #14

Earlier quoted context omitted.

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

If I ever see you again rewrite someone else's code without asking, I will fire you on the spot.

i'd fire you for micromanagement, mismanagement and encouraging bad practices.
Post reply on HN