It’s way easier (for this type of scenarios) and far more effective to learn by doing than to learn by reading (even tens of thousands of pages of) documentation, that is the crust of it.

▲

aleph_minus_one 4 hours ago | parent | next [-]

> It’s way easier (for this type of scenarios) and far more effective to learn by doing than to learn by reading

I don't think so: the problem is that there exist lots of parts in the system that are quite complicated but which one very rarely has to touch - except in the rare (but happening) case that something deep in such a part goes wrong a for requirement for this part pops up.

If you "learned by doing" instead of reading, you are suddenly confronted with a very subtle and complicated subsystem.

In other words: there mostly exist two kinds of tasks:

- easy, regular adjustments

- deep changes that require a really good understanding of the system

	▲	jakub_g 3 hours ago \| parent \| next [-]
		I tend to document some tricky non-obvious pieces of knowledge directly above the relevant code. "We have to do X below instead of obvious-first-idea-Y because Z". Any time a refactoring comes up which moves code around, AI (or my coworkers) remove those comments without thinking twice, and I need to tell them "hey this is still valid".
	▲	flyinglizard 4 hours ago \| parent \| prev [-]
		It's kind of a learning JIT. It's no use to go through and memorize something you don't need in the short term. It's hard to memorize well and by the time you need to draw on the knowledge it's already hazy. This is why you can think of such documentation more as a reference manual and not just plain documentation. In any case, AI is great for traversing a codebase and producing at least a draft of such documentation.

▲

chrisweekly 4 hours ago | parent | prev [-]

crust (edge/border) -> crux (heart/essence)

	▲	paganel 25 minutes ago \| parent [-]
		Thanks , am on phone with a tiny input. I was most probably also a little hungry.