Goodbye, Clean Code (2020)

>> If the reason for the duplicated code is just coincidence,

Totally agree! However, if code is duplicated because there is some is some assumption of functionality that is represented in multiple places then it gets more iffy. I took this article to imply that in each function implementation there were something like similar calls to a library or particular orders of redrawing based on the way the code base worked. That's where it can get dangerous.

It's not as dangerous if there are four very similar functions sitting right next to each other. But if there is a block of code that implements a way of working and another block of code has the same implementation in a place that isn't as easy to find that seems dangerous to me. If you want to make one change to a code base ideally you make the change in one place.

Here the author tries something then gives up. That does not mean clean code is not something to aspire or pursue.

What is described as building trust can be also interpreted as groupthink and colleagues forming pacts of mutual non-criticism (which breeds mediocrity). Which is also the way to build dogmatic cults of personality, and becoming superficial developers that care more about talking about their weekend than their craft.

You do not trust code. Memory and attention are fragile. Everyone makes mistakes. Everyone can have a bad day, be distracted, tired, etc. Building trust sucks. Trust nothing and be able to verify everything.

Your job is to edit code: add, delete, modify code. Each time you check in code it becomes company property. It is not "your" code. Modifying other people's code is completely OK, and expected.

In the end, this article is just wrong. "Give up, tech debt is your friend. Your job is to be best friends forever with your colleagues". All wrong conclusions.

I don't think this is necessarily true. If I have one place in my code where I sign unsubscribe tokens for emails and another place where I sign cookies for auth I don't want to implement a HMAC twice. Even if the verification paths are different so the algorithm doesn't actually need to be the same it is still better to use the same code for both so that any bugs, inefficiencies or other problems can be fixed once rather than up to twice.

I think the true decision function lies somewhere in the middle. For relatively simple code that doesn't need to be in sync then yes, duplication is likely the best option. For complex code or code that should stay in sync then extracting the common code is likely best. But there is a huge range of code in the middle where it is a judgement call with no obviously correct answer.

The real story here is not about the code.

When it's your own personal project and you can be your own little tyrant, do whatever you want. Be as "clean" as you need to be. But this was at work, and Dan was being a bad coworker.

He snuck in a change in the middle of the night over a coworker's code. This code wasn't his responsibility. He didn't leave his thoughts on a PR where others could discuss it. He overwrote someone else's code without asking. There was no opportunity for discussion or collaboration. Dan's actions said he's right and his coworker is wrong. They said he doesn't trust his coworkers. They said he knows best. They said if you want something done right around here you have to do it yourself. Dan was not being a team player. This story is less about code and more about team dynamics.

I hope Dan knows this and he was just trying to sneak the message past people who don't take social cues as easily as others. I hope his boss didn't just tell him to revert his change. I hope his boss told him why.

EDIT: I just reread the article and I think Dan missed the point. This wasn't about the code, as I said. But Dan really does seem to think it's about the code.

> Please no, this is how you end up with 20 different experiments and zero consistency in everything.

This comes from a lack of discipline in the org, not from the parent's (IMO) correct guidance that an org should undertake architectural changes with pilots in isolated parts of the code base.