Indeed.

I'm grateful for all the notes here. I seem to have been insufficiently clear on the subject of boiling water, so I've written a follow-up post:

https://www.natemeyvis.com/on-boiling-water/

Yes, that's an important part of any system. It sounds like we agree that the traditional diagram, with some boxes and some arrows between boxes, is quite inadequate when you actually have a tough problem that needs solving.

Some alternatives:

- Finger to the wind ("this feels like a big change"). - Domain-specific versioning scheme (so Ruff uses [this variant](https://docs.astral.sh/ruff/versioning/#version-changes) that seems reasonable to me; it's described as a SemVer variant, but the work to specify how various cases are handled seems very useful to me). - As you say, time stamps. FWIW I don't like that very much, because time is often so weakly correlated with progress / "breakingness," but it has its proponents.

I basically agree with this. Extra objects do carry costs. That said, usually the extra objects are necessary to make your code conform to reality. N things with N names in N files definitely carries overhead, but if the alternative is N things with 1 name in 1 file, and programmers carrying the complexity in their heads (or the complexity being a bunch of spaghetti in the one file), I'll happily accept the N - N - N side of the tradeoff.

(2)-ish patterns are more what I have in mind, but note that as soon as you're expecting the same `db.query(hats)` to give you the data you need for both (1) and (2), you might already be pretty far down the wrong road.

I'm trying this right now and I don't get it. There's no difference between

    HatsService
        getWearableHats() { return db.query(Hats).toDto() } 
        getThrowableHats() { return db.otherQuery(Hats).toDto() } 

and

    # wearable.py
    getWearableHats() { return db.query(Hats).toDto() }

    # throwable.py
    getThrowableHats() { return db.otherQuery(Hats).toDto() }

I agree that following expected patterns is a _prima facie_ reason to do something. That said, in this case:

1. The downsides of following it are severe, and 2. People often expect slightly different things, so you often don't get the benefits of following convention.

I really appreciate this comment. I have some passing familiarity with Clojure, but I don't understand it (and its motivations) fully and would like to understand it better. Thanks for the YouTube link; I'd love some reading material (essay-length preferred but anything will do) also, if you have any to recommend.

This is a great place to start! https://clojure.org/about/history

Thanks for the thoughtful reply. I address it (briefly) in a follow-up: https://www.natemeyvis.com/on-studying-for-your-upcoming-job....

People might not know what the code base is actually like; they have incentives to overstate its quality; and, even if they can point you to a relevant, authoritative book, that doesn't entail that the hour spent with it is better than an hour spent learning a tool.

I still disagree, but I think I better understand the disagreement now. I find it easiest to learn a new language by starting with the canonical beginner's book, e.g. the Pickaxe book for Ruby. I find it hard to learn tooling like CI/CD, logging/metrics, etc by reading or through personal projects, I much prefer to learn those on-the-job as necessary. It seems like it might be the inverse for you.

Even if a new codebase isn't exactly 'Effective Java' quality, it's good to have that reference to better articulate to yourself exactly how the codebase is flawed.

Author here. I certainly have a lot of opinions about what to study more generally! This was a short note for people who are specifically trying to make it likelier that they'll succeed at a job they're about to start. Lots of people (former versions of myself included) focus too much on learning a language when studying other tools would give a higher ROI.