Theaetetus

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 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.

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.

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.

[Author here.]

Thanks for the note! Unfortunately Eric's reference is not publicly available (as far as I know).

I'd love for more people to collect and publicize sets of commonly used code review notes.

Others here will know much more than I do about which publicly viewable projects have the best (public) feedback. Good luck!

[Author here.]

There are definitely other ways to represent this data! I think a useful exercise is:

(1) Sit down and think of a very basic representation of this data (in whatever language you prefer). (2) Figure out where in the current SQLite database the relevant information lives. (3) Write a function that is given some relevant set of rows from this database and returns an item in the representation you determined in (1). (4) Test it. (5) Think about how to persist it.

You can do some subset or superset of these as you see fit, but I do think it's valuable to think about how to represent the relevant objects before you worry about persistence details.

Thanks for your comment!

[Author here.]

Yes, I agree. I hope I was sufficiently clear about that. My motivations for writing this up were that (1) it's a wonderful example of a lot of things I often find myself saying about databases; (2) peoples' Anki decks are really important to them and I'd like to enable people to work with them if they want; (3) I do hit strange behavior sometimes in Anki and perhaps these issues are behind it.

I hope you're backing up your deck!

[Author here!]

I'd guess that (2) is more important than (1) here. Or, at least, it seems anecdotally right to me that programmers are very hesitant to do migrations.

As for (1), you must be right that a disconnect between a design and eventual use is important here, but I'd have said that the more central cause is just that systems change and that their eventual use is very hard to predict. I need to think more about your conjecture that there's a misfit between programming practice and what's necessary for database work; I like the idea that we're habituated to implement something very basic up front, and that this habit intersects particularly badly with database work (that is, it causes problems that aren't nearly as bad with non-database parts of computer systems).