Thread by @GeePawHill

Refactoring Pro-Tip: Terrible code is not a good excuse to be mean, because terrible code is not well-correlated with having been written by terrible people.

Look, y'all, it's me, here. I love a good rant as much as the next Old Testament prophet, surely you know this.

But . . . but . . .

When I work with a new team, a key element of what I do is figure out how to integrate my line of advice, which necessarily lives in theory-land, to their line of code, which necessarily lives in bits. So we do a lot of mobbed code review.

We start every session by remembering the first rule of code review club: "You are not the code you wrote."

The reason we call this out every time is because it's so easy to forget, and it's so hard to get better at *anything* when you're afraid. And is anything scarier than thinking your ugly code is just a reflection of your ugly soul? If so, I can't think what it would be.

But describing it this way makes it seem like I'm just being nice: I don't want you to feel bad so I won't tell you to your face that you're a bad person because you wrote some bad code. That's not really it.

"You are not the code you wrote" isn't just me being soft on you, it's me pointing out that all of us are guaranteed to write bad code sometimes because of forces that are almost entirely beyond our ready control.

What forces am I talking about, these forces that aren't under our simple direct control, that can't be fixed by some simple act of will? Let's list a few.

1) Extraordinary demand creates extraordinary shipping pressure. Paid geeks are not paid to have perfect expressions of ideas, but to have running expressions of them. As soon as its "good enough" we've no choice but to move on.

2) The trade is constantly changing its idea of what is "good" and "bad" in expression, and it should be, because it's a very young trade, and we're getting better as we go.

3) The ideal vantage point for evaluating the expression of intent in the code is decidedly unavailable when one is in the thick of creating it. A coder simply does not have the necessary distance when she's in the thick of the fray.

4) Even if the trade were holding still in its idea of "good", if we as individuals are holding still it's because we're done learning. Half of all developers have <5 years in the trade. They couldn't possibly be done learning yet.

(I only have 40 years in the trade, myself, so I'm not done learning yet, either. When they asked Pablo Casals why he still practiced every day at age 80, he said, "Because I think I'm getting better.")

There are many more reasons than these 4. You can see us starting to shade out, though, along a gradient: the human-ness of the makers. There are good days and bad days. There is realizing what you should have done during your morning shower. There is -- it goes on and on.

And let's make sure we understand that I'm not just telling this to you, I'm telling it to me, too. If you're new to the game, maybe it hasn't happened quite yet, but I can assure you it will: you will encounter awful code that you just wrote a few days ago.

You'll borrow and morph a nasty line from the great Hepburn in _Lion In Winter_: "What kind of spindly, ricket-ridden, milky, wizened, dim-eyed, gammy-handed, limpy line of things begot this code?"

Then, "Oh. Yeah. I did."

Worse than that, I've run 50-step refactorings a time or two only to discover at the end that I had made the code *worse* not better. That's not common, but it does happen.

So. Bad code can be written by good people -- & vice-versa, & every permutation in between. Make the code as expressive as you can and keep moving. Terrible code is just not well-correlated enough with terrible people to get all stressed.

Have a weird lazy Sunday!