2026-09-02 13:42:26 Yeah I've got a thing about turning relatively repetitive code into one function with a bunch of flags to control the edge-cases, sue me 2026-09-02 13:43:44 When is refactoring a bad idea? One time I can think of is falsely making an assumption to simplify the existing code 2026-09-02 13:44:09 The assumption is contradicted later and best case scenario your refactor was a waste of time, worst case other things have changed in the meantime and someone has to spend time undoing the damage 2026-09-02 19:43:33 well, sometimes refactoring introduces duplication; the refactoring "inline subroutine" is the inverse of the refactoring "extract subroutine", and it usually does introduce duplication, and duplication is very often a bad thing for reasons we all know 2026-09-02 19:45:27 but "extract subroutine" (and "extract variable", "extract class", "extract method", "introduce parameter object", etc.) introduces indirection, and indirection can also be a bad thing 2026-09-02 19:47:55 in part because there's no limit to how much indirection you can introduce, but also because in general it makes your code more flexible and therefore less statically analyzable 2026-09-02 19:56:24 As with any other engineering decision, there's no clear global optimum, just a Pareto-optimal frontier of tradeoffs, and a somewhat subjective judgment of which parts of that frontier are most desirable 2026-09-02 19:57:55 but it's a little more difficult than most other engineering decisions because the things you're trading off (in my analysis above, which omits performance) are essentially psychological rather than objectively measurable 2026-09-02 19:59:48 you're trying to predict what kinds of functionality changes people (possibly other people) will want to make to the code in the future, and how much mental effort it would take them with different candidate factorings of its current functionality 2026-09-02 20:01:03 or, in some cases, what kinds of questions they will want to know the answers to about it 2026-09-02 21:10:06 Yes this is the kind of thing I've been mulling over today, removing duplication by adding more indirection ... when is it not worth it 2026-09-02 21:10:40 I tend to prefer the extra indirection but I'll avoid it if I can. It's worth it if it reduces relevant code significantly, but not if it barely reduces it 2026-09-02 21:14:23 This kind of decision of trade-offs is the stuff that experience counts a lot for, throughout my career I continue to slowly make better decisions about this 2026-09-02 21:14:58 And it is subjective and also probably domain specific and even project specific, I've got a good feel for what works in the codebase I'm responsible for but might not be so confident in another codebase 2026-09-02 21:15:34 I do think there is a lot of value in refactoring though, even though it's not usually obvious what the value is to the business. 2026-09-02 21:52:18 you may be interested in this bookmark: 2026-09-02 21:52:20 https://cbarrete.com/carmack.html John #Carmack on a style of programming where you inline all your code and not using any subroutines. “As an additional confirmation of the point of the article, a couple years later when I was working on the Doom 3 BFG edition release, the exactly predicted off-by-one-frame-of-latency input sampling happened, and very nearly shipped. That was a cold-sweat moment for 2026-09-02 21:52:26 me: after all of my harping about latency and responsiveness, I almost shipped a title with a completely unnecessary frame of latency.” #latency #real-time #responsivity #games #video-games 2026-09-02 21:53:42 I think there's a lot of value in having a good factorization, but there isn't always a business 2026-09-02 21:55:03 The value of the best factorization is usually only slightly higher than the value of many pretty okay factorizations, so it's easy to do an arbitrarily large amount of work chasing minor gains 2026-09-02 21:55:57 and sometimes you get it wrong and make the design worse by refactoring in the wrong direction, like inlining subroutines when you ought to be extracting subroutines, or vice versa 2026-09-02 21:57:04 reduction of code is one metric that suggests that a particular factorization is good, but it's not the only one 2026-09-02 22:00:49 even refactoring that doesn't actually improve the factoring can be worthwhile sometimes, because it increases your familiarity with the code in a lower-risk way than adding functionality does. If programming is theory building, well, it may be useful to do some exercises 2026-09-02 22:23:30 Yeah what John Carmack talks about there, I partly agree and partly don't. 2026-09-02 22:24:09 Like I really don't like really long functions and while I think it's possible to do a bad job splitting it up, it's usually possible to do an okay job splitting it up 2026-09-02 22:25:50 The bugs he found... sound like the kinds of bugs you do find when playing with code whether it's splitting it up or unrolling it... especially if it's got a lot of global state etc 2026-09-02 22:25:58 In the armadillo code I mean 2026-09-02 22:26:40 Also John Carmack is probably better at spotting bugs than most of the people who reviewed the Armadillo code, that wouldn't surprise me anyway 2026-09-02 22:27:46 And these real-time concepts in video games... I think he was right when he said that nothing would get done if we applied those principles 2026-09-02 22:28:37 In many embedded situations there has been a definitive move away from real-time whenever possible because it is so expensive and *slower* than the quick and dirty "just use a Linux app" approach in practice for 99.9% of the time 2026-09-02 22:30:36 here he is literally telling us to write slower code so it can be more consistent... and this principle doesn't really begin to account for algorithmic complexity on a game with N entities... yes you can make your game run slower and deterministically on purpose and *still* get crucified by some bad algorithm you didn't profile in an edge case 2026-09-02 22:31:30 But yes sometimes looking at code differently helps; and refactoring for the sake of refactoring can cause issues 2026-09-02 22:33:16 yeah, the risk of refactoring is not zero 2026-09-02 22:33:35 I think "write slower code so it can be more consistent" is good advice in some cases and bad advice in other cases 2026-09-02 23:48:17 I wonder if he still advocates for that 2026-09-02 23:49:07 well, at the end of that page he writes in 02014 about how his perspective has changed