[jitl]

Often the docs for a library suck or lack suggestions about suggested structure, but LLM has ingested many open-source example uses from Github etc and so can offer code examples or explanations totally absent from the docs. I find this if a library has lots of comments for individual functions or struct types, but little tutorial-style and module-level docs.

Other times the docs are hundreds of pages, "read all the docs" is too much reading for a simple task, and so asking AI for just the code please is the right move to get started.

[godelski]

  > Often the docs for a library suck or lack suggestions about suggested structure

I don't disagree here. I do preach that one should document as you code. This gets a lot of pushback. But tbh, I think the one who benefits the most is yourself. What's the old joke? "What idiot wrote this code? Oh... that idiot was me." Give it a week and there's a good chance I forgot my though process, what I was doing, and why. Depends how many projects I have and how attention must be split.

But there's a lot of ways that documentation happens. One of my favorites is unit tests. Before I turn to reading source code to figure out how something works, I go look at unit tests. That way I prime myself for what to look for when I do need to look at source.

FWIW, even with highly documented things I go look at source pretty regularly. I'm a ML researcher and I'll tell you that I go poking around torch's code at least once a month. If you're using libraries quite frequently, it is probably worth doing this.

I also want to say that I remember the fear of doing this when I was much more junior. That it all looked like gibberish and inparseable. But this is actually the same thing that happens to any fledgling PhD student. Where you're required to read a bunch of papers that don't make sense. The magic is that after reading enough, they do start to make sense. Same is true for code. There is a certain "critical mass" needed to pull all the ideas together. Yes, LLMs can help make this process easier and probably reduces the requisite mass, but I also HIGHLY suggest that you still read source (not for everything! Of course! But anything you use regularly). It is scarier than it seems and you'll honestly be able to parse it before you know it. Learning requires struggling and as humans we like to avoid struggle. But the investment pays off big time and quickly compounds. Were I to go back in time and advise myself, I'd tell myself to do this earlier. I was just fortunate enough that I had a few projects where this ended up being requires and (un)fortunately extremely difficult to parse code (I was in template metaprogramming hell).

There's a bad habit in CS: move fast and break things; or alternatively, just ship. This is great in the learning process. You learn from breaking things and getting your minimal viable product is hard because you don't even know everything you need till you are knee deep into the problem. But the bad habit is to not go back and fix things. Little optimizations also compound quickly. You can never escape tech debt, but boy does it pile on invisibly and quickly. There's a saying that a lot of tradesmen and engineers use: "do it right, or do it twice." (alternatively: "why is there always time to do things twice but never enough to do it right?") I think we could learn from this. Software is so prolific these days that we need to move from living in the wild west. Truth be told, the better LLMs get, the more important this will be for you.