Refactoring Is Not Just Clickbait - Kevlin Henney - NDC London 2023 

Nice too see a speaker practice what they preach.

But the world has abandoned Aristotle for errors from the likes of Kant, Nietzsche, et al., and that's why our industry is now miserable while everyone pretends that everything is just fine. Our industry right now (among other aspects of society) is literally the This Is Fine meme personified. There's a reason why you can easily find hundreds of talks and conferences about "No, this is how you program!" and not, "No, this is how you do !", and there's a reason why there are hundreds of programming languages, most of the new ones trying to solve other languages, while the older ones fail to properly solve software engineering, so the cycle of new programming tools is perpetuated because no one wants to address CSE. They're all trying to fix C, and then simultaneously account for the technical debt that should have never been incurred with regard to programming _discipline_ in the first place, hence why things like "Clean Code" (among other things) take off because people are frantically grasping for something solid (pun not intended) to guide them and make their code good all the time since by no fault of their own, they don't understand how their code gets bad in the first place, especially when everything is reduced to subjectivism!

yap yap yap what's your body count

I just pull it out as a method and give it a very explicit name.

@@d7ffab979 If it's used in multiple places I do that too. Otherwise a local variable will be good enough.

I would change it "toward some stated goal" rather than remove it. That way you are codifying that refactoring is not just performing an operation and then its inverse, that you have some idea (even if loosely defined) of where you are going/why you are refactoring the code. With the trader example, that is "so I can better understand the logic at the point at which it is used, so I don't have to repeatedly add the same comment". It may also be something like "so I don' have unnecessary code" (like in the time regex example), or it may be "so I can lay the foundation to implement some new task/feature I'm working on".

@@msclrhd So what would you call someone making changes to internal structure without stating a goal?

@@barneylaurance1865 Maybe "toward some goal or outcome" is better. That is, you don't have to explicitly state the goal, just know the general direction to travel in. This is to in some way to codify the idea that refactoring isn't about repeatedly applying rename, extract, etc. refactorings, but applying them to achieve some goal (either implicitly or explicitly stated). Otherwise, your refactorings are aimless. Even though you are applying refactoring techniques (the noun), I wouldn't call that refactoring (the verb).

@@msclrhd what would you call it then? I'd just call it aimless refactoring. I might say "don't refactor aimlessly".

@@barneylaurance1865 That's a good name for that. I'd use that too.

Debt is something we have to pay back. In that context, it is more appropriate.

I think you missed his point and the point of debt, in general. Debt is _not_ bad if the utility gained from your expenditure is greater than the cost of the debt. If I get a car loan to enable me to goto school or a job, arguably that's good debt. If it's a choice between owning a house *now* or owning a house in 50 years after I saved up enough then the _loan repayments_ are arguably "not a good thing" but they are in service to me having a house now, instead of in 50 years. Put in moralistic terms, if you save my life and I say, "I am in your debt." I owe you my life, for me, I'd much rather owe you that huge debt of gratitude than be dead. In these ways, we find utility in debt. It's at the heart of ideas around reciprocity and I don't think it can be painted as always bad.

Debt is not bad, it is a liability. You take a debt to do something quickly (right now) instead of waiting. It will turn bad if you do not manage your debt. This is same with financial as well as tech debt.

I still had to keep watching because I'm a massive KH fan boy.... doesn't mean I didn't get very cross indeed about what he said about Pascal though.

It's funny... I was looking at some old Pascal this morning and was thinking "oh look, in that module, a closure, and some STRONG typing.... doesn't it look like TypeScript?" .... no lambdas or monads though.

Hardly a rant, more of an aside. Let's not get our keyboards in a jumble.