[jaylaal]

For a small but complicated project I got thrown into a while ago, the only way for me to understand it was to print out all the source directly, vertically tape together the pages for a single file, and then lay them all out on a huge table. Then I took multicolored markers and started physically drawing out the call chains. I then I sers-toi the system, and also found an enraging bug: the system widely used the variables "blah_name" and "blah_id", including in many functions' parameters. Except, in one case, blah_id was passed in as blah_name and thenceforth became known as blah_name.

I don't know if an automated visualization system is possible, but you'll have to understand the whole thing before doing so. Pen and paper was the most expedient solution for me at the time.

[DANK_YACHT]

I use pen and paper as well, but rather than print out all the source code, I write down the call stack. A calls B calls C, etc. along with the line numbers of the call. Much easier than printing out the source and you still have the IDE niceties like go to definition, find in source, etc.

[ASalazarMX]

This reminded when I had to maintain dozens of old 10,000 lines COBOL programs as a junior programmer. I felt so lost I made a program that would print only the names of data structures and functions. Seeing the source resumed in a handful of pages, and being able to highlight and draw on it, helped me a lot. Digital has flexibility, but sometimes paper works best.

[kbrannigan]

Paper is one of those Perfected technologies. It's been there for a long time but boooy. It's powerful

[er_d0s]

Hah! I did the exact same thing for ages on paper and eventually evolved the system to manage my workload and context switching… I still use it a lot for going deep while debugging/understanding code. I ended up making it into an app when I broke my wrist and could still type but couldn’t hold a pen. I can’t remember if there’s rules about self promotion in comments here but it’s up at journalist mode dot com

[_dain_]

I've done this too, taped a bunch of impenetrable code to the wall and scribbled on it with pen to figure out wtf was happening. I propose that this be called the "Pepe Silvia" debugging method since it looks like a crazy conspiracy chart. Eventually you'll figure out why nobody is getting their mail ...

https://www.youtube.com/watch?v=_nTpsv9PNqo

[jimpudar]

I also used to do this when working on a big convoluted system. I had a conference room near my desk with all the walls completely covered in code. A big pack of multicolored highlighters is key.

I remember a whole bunch of light bulb moments when I showed other developers the "big picture". It's an awesome technique when you're forced to work on spaghetti!

[zach_miller]

Sounds like something the type system should have caught!

[sixstringtheory]

Lucky you if you work with people who see the value in a language with good type checking or that doesn’t just use strings for everything.

[plonk]

Is it really worth staying in a team that doesn't? Sounds like you'll spend more time fixing bugs than creating features.

[growwrkr6]

Language support varies but if it’s possible, why not generate an AST and count references, bubble up most common, etc?

Could do similar with bash text mangling tools, but language native would probably be best.

I dunno, just a thought in an EOD fog. I don’t own a printer these days, so I guess I’d need an alternative.

Tell computer to observe self and report back.

[brailsafe]

First principles! I've totally done this. Especially in a large pub/sub oriented frontend codebase where it's really hard to map out where any given data could have come from