Conversation
I have been able to find almost nothing substantial on how to read legacy code. Most of the material I have found is highly questionable. I would feel that I have missed something obvious except most of the material that does talk about it opens with "this is a grossly neglected topic that nobody likes to write about".

This is like 60% of a programmer's life and nobody teaches it. How is this possible? Is it just that it isn't fun?
4
1
2
Imagine trying to write a book about how to read a book.

I don't think it's possible. There are no secrets. Every author is different. Every reader is different. The context is almost always different. Abstractions are on an almost infinite set of layers.

Impossible.
2
0
3
@tyler peoples specific workflow can be different but there are common patterns that fit into how human brains work in general. Flash cards work for basically everyone, for instance. Memory chunking is similarly universally applicable.

I'm developing a technique that is ultimately for me, but it's drawing a lot from the research that is out there and I think it could work for most people.
1
0
0
Frankly it's a good application for something like Claude to speed up comprehension of a difficult function if something is poorly written.
1
0
1
@tyler @kc-poast I've seen a LOT of attempts for AI to explain code at this point and I have not been impressed. It can generate but it can't analyze worth a shit.
1
0
1
It would be cool for you to write a synthesis of the good advice.
1
0
0
@tyler I am yeah. My ultimate goal is to develop a plugin that can automate a lot of the manual labor I've already been doing such as screenshotting and allowing drawn annotations, but I'm first writing a "Bible" of how the current manual workflow is done as a guiding document.
1
0
0
Interesting, I've had generally good results. Like it didn't get it 100% right the first time but neither do I.
0
0
1
Would be happy to purchase from you when you're done.
1
0
1
@tyler in the meantime, this books technique isn't exactly what I'm doing but I'm getting a lot of excellent notes from it that are more eloquently stated than I could describe them https://www.manning.com/books/the-programmers-brain

This does cover annotating over source code to enable depth-first-search style analysis of it but it does not recommend sane ways to actually do that. Its methods are tedious and impractical and therefore you'd never realistically do them. I currently use a program called excalidraw combined with ShareX to make an infinite canvas of screenshots. Works well but it takes a lot of setup and tweaking to get right.
1
0
0

Lovin', touchin', squeezin' all the caucasoids🍟👩‍❤️‍👨🍔

@RustyCrab Run it in a debugger and start setting breakpoints
1
0
1
@YTFoidLover1488 that really does not help you dig into a program that's millions of lines long and has 400 subsystems
1
0
0
Perhaps those techniques that take a long time exist for a corporate setting where you have some code monkeys and you need want to fork an MIT project and close source it.
1
0
1
@tyler I suspect the author simply didn't know a better way to organize the workflow. It is difficult and a lot of very helpful software that I use didn't exist at the time of writing.

The advice is like "print out your source code and put it on a bulletin board". It does not even function in the same universe as the problems I am needing to tackle.

Besides, it seems like the author is more of a psychologist and teacher than actual software engineer. That's fine. I can personally attest that the advice is good because several methods presented are ones I independently discovered by just grinding away for years.
1
0
0
@RustyCrab consider how narcissistic the average programmer is
1
0
1
@benis_redux there is that, but reading source code is genuinely harder than writing it due to the text->mental model bottleneck. The arrogance is assuming that what he writes in its place is actually better as compared to him just understanding it better because he wrote it; a common failure of thinking in new programmers (and sadly many experienced ones)
1
0
0
Oh you don't print out your source code if it's been a long time working on it?? I do that all the time.

It's a LOT faster than scrolling on a screen, to follow the program flow, especially if you are a man (strong spatial reasoning)
1
0
1
@tyler I do, but we're talking about digging into over a million lines, not hundreds
2
0
0
@RustyCrab yes, it goes both ways: those who wrote the code I have to read were clearly retarded, and I am certain to do better than them; those who will have to read my code won't understand it because they will simply be incapable of understanding my genius, and will just defile it with their simplistic thinking.
1
0
1
@RustyCrab brother I need a few words more
1
0
1
@benis_redux @grips @RustyCrab I comment pretty much every line of code in my own code. I have memory of goldfish when it comes to code.
0
0
1