thanks for this.

> the term originates from Michael Feathers Working Effectively with Legacy Code

I haven’t read the book but, taking the title and Amazon reviews at face value, I feel like this embodies Codex’s coding style as a whole. It treats all code like legacy code.

It's been a long time since I read it, but it was one of the better books I've read. It changed my approach to how to think about old code-bases.

I agree. I come back to it all the time when I need a little inspiration for how to deal with a gnarly codebase. Usually there is something in there I can apply directly to get me out of a pinch. When there is not the reminder of how malleable code is suffices.

It's not in the top 10, but it's of the more well-known and widely recommended book in the software industry. I'd put it in the same bucket as "Clean Code" and maybe even "Domain Driven Design"; they're kinda from the same "thought school" in the software industry. So it's definitely over-represented in training data (I'd guess primarily in the form of articles and blog posts and educational material reiterating or rephrasing ideas from the book).

FWIW, I found the concept of "seams" from that book useful back when working on some legacy C++ monolithic code few years back, as TDD is a little more tricky than usual due to peculiarities of the language (and in particular its build model), and there it actually makes sense to know of different kind of "seams" and what they should vs. shouldn't be used for.

No, it’s not an established term outside the mentioned books, beyond the generic meaning of the word.

I have frequently encountered the term in the context of unit testing and dependency injection.

Other references (and all predate chatgpt):

>Seams are places in your code where you can plug in different functionality

>Art of Unit Testing, 2nd edition page 54

(https://blog.sasworkshops.com/unit-testing-and-seams/)

>With the help of a technique called creating a seam, or subclass and override we can make almost every piece of code testable.

https://www.hodler.co/2015/12/07/testing-java-legacy-code-wi...

> seam; a point in the code where I can write tests or make a change to enable testing

https://danlimerick.wordpress.com/2012/06/11/breaking-hidden...

Maybe it all ultimately traces back to the book mentioned before, but I don't believe it's an obscure term in the circles of java-y enterprise code/DI. In fact the only reason I know the term is because that's how dependency injection was first defined to me (every place you inject introduces a "seam" between the class being injected and the class you're injecting into, which allows for easy testing). I can't remember where exactly I encountered that definition though.

For what it’s worth, there are many areas of programming where dependency injection is almost never used. Game dev, data science, and embedded systems, for example, rarely use dependency injection. It’s definitely most common in enterprise Java code and less common in Python, C, or C++. And even then, not everyone uses the term “seam”.

Isn't DI just most commonly used in (web) server code, and rarely outside of that? Now it happens that C and C++ have been a rare choice for such code for decades, whereas Java had the longest streak of holding the #1 spot. It almost certainly still is #1 in terms of "requests served/day" by a large margin, probably no longer is #1 for greenfield projects.

I can't say it isn't, but I have been writing code since about 2004 and this is the first time I've become aware that this is a thing.