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

Goodbye, Clean Code

overreacted.io

Post reply on HN
Print view View original

331–340 of 599 posts

Re: Goodbye, Clean Code

#331

Post by sinsterizme »

jrochkind1 wrote: post #176
Jasper_ wrote: post #110

Earlier quoted context omitted.

If someone spends a week or two writing a patch and you come in and rewrite it in an evening, that, in and of itself, is telling me something: You think your teammate is a worse coder than you, given you were able to solve it with "cleaner" code. You assumed that your solution was better, without talking to the person who authored it to see if they did things that way for a reason. This could have been solved with a…

> If someone spends a week or two writing a patch and you come in and rewrite it in an evening, that, in and of itself, is telling me... Or, what it might be telling you is the second person wouldn't have been able to clean it up in an evening without the first person having already spent a week or two on it. The second person was building on the first. Just because it was (hypothetically) less lines of code doesn't…

This blows my mind. If I had to discuss with my teammates every time I changed their code I would be way less productive. Everyone’s a little bit watched to the code they write, but iterative improvements and bumping the quality of the codebase is way more valuable than risking a fragile ego. It’s the teams code, we all benefit from improving it.

Re: Goodbye, Clean Code

#332

Post by watwut »

burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

Extracting common function was right move in your example.

The bad move was to add options to common functio instead of changing one caller to call new different method.

Even worst move was add more and more options to originally simple method. Just because something was rightfully extracted to common place 10 months ago dies not mean it have to remain in common place. And the need for split does not mean original extraction was wrong.

Re: Goodbye, Clean Code

#333

Post by kortilla »

jt2190 wrote: post #255
habitue wrote: post #160

Earlier quoted context omitted.

> Changing one developers _working code_ after they’ve invested a significant amount of time How much time they invested is irrelevant. There are lots of times where someone is wrestling with something for so long they just want to get it done and don't want to look at it anymore. Many times it's trivial for someone fresh to tidy it up > If removing repetitive code is a requirement then the team needs to be informed…

> There's no way to codify concrete requirements for handling every possible way code can be improved. If the change can’t be codified, then it calls into question why the change needs to happen at all. Assuming that there is some improvement that can be justified, then explain it to the team, and have the team start reviewing for it. By not going through the process of explaining the improvement to the team, it sign…

If you don’t trust someone to change your code to make small improvements, it sounds like you have a trust problem, not the other way around.

Working on a software project as a large team is like growing a garden, not building a house. Just because someone planted a hedge doesn’t mean it can’t be improved by pruning it.

Re: Goodbye, Clean Code

#334

Post by shaunw321 »

Lots of great examples and philosophies here.

I think, for me, I am often on two sides of the situation.

1. I'm moving fast and writing code to get things done for the customer and the product.

2. I have enough time to slow down and write or refactor "testable" code.

Often 1 results in untestable code. Often 2 results in a refactor or most likely a rewrite to create testable code.

This is an important difference. Optimizing to write code just because you think is clean (in the sense of shorter, reusable code) is often confusing to most. This also leads to pull requests that grow large and are hard or time consuming for others to review.

Re: Goodbye, Clean Code

#335

Post by kortilla »

cellularmitosis wrote: post #221
danabramov wrote: post #18

Earlier quoted context omitted.

I think there’s a balance. There’s a difference between gradually improving something, or improving it at some point later — and literally rewriting 100% of code someone has just landed over the night.

This actually happened to me, (and his rewrite didn’t even work!). Having witnessed this first-hand, I can say that the impact of the code change was absolutely dwarfed by the lost trust. Unsurprisingly, I would come to find out that this engineer had what I would call the opposite of soft skills, and the notion of a “this irks me so I rewrote your code” has become a giant red flag for me.

Did you lose trust because the code broke (a legit reason to lose trust) or because your code was changed without kissing your ring (a problem with you being too attached to your code emotionally).

Re: Goodbye, Clean Code

#336

Post by darkbatman »

Nevertheless, I used to work with someone in a startup, who was crazy about over cleaning the code. Every time there was something that has to be cleaned and when requirements changes or new feature is needed we had to do all the fancy stuff again because of the over cleaned code that wasn't flexible enough.

Re: Goodbye, Clean Code

#337

Post by kortilla »

vez- wrote: post #246
temac wrote: post #13

> A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I'm against the idea that people should be attached to "their" code (that is: the code they wrote). Now I also understand that humans that humans, but the priority should be to make them evolve toward more detachment from their…

I disagree that people should NOT be attached to their code. Having a sense of ownership for what you write can lead to higher quality systems where people are willing to stand up and fight for what they believe is higher quality. BUT this importantly depends on the ability to compromise, admit being wrong, and change based on new information from the people who have a sense of ownership over their parts of the codeb…

People that get really attached to their code tend to be the people not smart enough for you to want them fighting for their opinions.

Good engineers promote good ideas and general approaches to code base structure. They don’t give a shit if people go in and make changes as long as they don’t compromise the whole architecture.

Re: Goodbye, Clean Code

#338

Post by watwut »

temac wrote: post #13

> A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I'm against the idea that people should be attached to "their" code (that is: the code they wrote). Now I also understand that humans that humans, but the priority should be to make them evolve toward more detachment from their…

Honestly, no attachment to my code demotivates me.

It makes me less responsible for outcome and helpless. It makes it much harder to prove I know what I am doing. Since you modify things however you please despite me not agreeing, I am not the one at fault for maintenance issues. It also means that keeping conventions requires constant negotiation and frankly, if I would enjoy people trying to dominate me or me dominate them I would become manager.

And yes, it should not be about that, but it is about that with a lot of guys.

Re: Goodbye, Clean Code

#339

Post by he0001 »

hyperpallium wrote: post #283
Stratoscope wrote: post #281

Earlier quoted context omitted.

Yes, exactly, and it is such a good rule to go by so much of the time. But like many rules, you need judgment to know when to apply it.

Rules are a poor substitute for actual thought.

I thought rules were a way of organizing thought, like a language which is governed by rules.

Re: Goodbye, Clean Code

#340

Post by kortilla »

lonesword wrote: post #187
temac wrote: post #13

> A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I'm against the idea that people should be attached to "their" code (that is: the code they wrote). Now I also understand that humans that humans, but the priority should be to make them evolve toward more detachment from their…

> I'm against the idea that people should be attached to "their" code (that is: the code they wrote). Can people _reaaally_ detach themselves from the code they write? After all, programming is a somewhat creative profession. I can't imagine painters and writers detaching themselves from their work. I wonder how doctors and surgeons cope with this. Their work directly affects human lives and I can imagine a mistake w…

> I would be outright offended.

Get over it. It is not your code (assuming you are working for a company). If some other developer wants to waste time making changes that don’t do anything, that’s between them and their manager.

Would you be “outright offended” if your code got changed after you left?

Post reply on HN