Live data from Hacker News

Goodbye, Clean Code (2020)

overreacted.io

21–30 of 224 posts

Re: Goodbye, Clean Code (2020)

#21
post #14

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.

Two reasons, one technical, one social. Firstly, the original developer probably spent more hours thinking over and working on that bit of code than you have -- so maybe they had a good reason for doing it the way they did. You won't know unless you ask them. Secondly, I think it's a fairly natural and common human behaviour that when you spend a lot of time working on or making something that you feel some degree of satisfaction, pride and investment in the result. Even in a cooperative joint endeavour that is striving to avoid an idea of individual "ownership" of parts of the project, I think it can be helpful sometimes to acknowledge that feeling of investment by consulting the original author before walking in and radically changing something they did.

Re: Goodbye, Clean Code (2020)

#22
post #4

This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."

Totally agree!

I think this is a journey a lot of software engineers go through. I can say I was walking down this path in the past.

Re: Goodbye, Clean Code (2020)

#24
post #20
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.

Trust would also include to consider that there might be a reason for why the code is the way it is, even if it is not directly obvious. A brief chat can then help to clarify things.

Agreed, it's always worth remembering Chesterton's Fence. https://fs.blog/chestertons-fence/

Re: Goodbye, Clean Code (2020)

#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 other hand, you may have code that MUST be the same in a few places, and updating it in one place but not others would break stuff. Those dupes must be removed.

Re: Goodbye, Clean Code (2020)

#26
post #14

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.

The other developer usually has reasons why they designed it that way. If you just rewrite other people's code, it makes it seem like you think there is One True Way to writing code and that you're smarter than them.

I'd ask first if they agree with a certain improvement. It shows I value them as an engineer and they might bring up critical information that I'm missing, making my "improvement" actually worse. It doesn't hurt to talk to people.

Re: Goodbye, Clean Code (2020)

#30
As an amateur programmer I do feel the same about my LaTeX projects. I would try to DRY my code into reuseable chunks, but eventually every use case is slightly different, and LaTeX is a terrible language to work with if you want refactoring
Post reply on HN