Off the top of my head: - Count the lines of code with find | wc, get a sense for what's there, and what language it's written in. The biggest file in the pro

Off the top of my head: - Count the lines of code with find | wc, get a sense for what's there, and what language it's written in. The biggest file in the project is usually worth a look -- it is often where the "meat" is. Read the function names. - Use the program. grep for strings that appear in the UI in the source code. That's a good place to start reading. Read function names. - strace the program. What system calls does it make when? ltrace is also sometimes useful, although it also gives a ton of output. - Look at header files. Understanding data structures is often easier than understanding code. - Look at commit logs. Those are hidden "comments". And reading diffs can be easier than reading code. - Do a "log" or "blame" on the file. How has it evolved? - Start reading main(). This often reveals something about the structure of the program. Even just finding main() in many programs is a good exercise :) Sometimes it's a little hard to find. - Make sure to build it. And if you can, look at the build system. How is it put together? Most build systems are pretty darn unreadable. I don't really know how to read autoconf, and GNU make is tough too. Forget about cmake :) But sometimes this can help. I haven't gotten that far with this, but I tried uftrace recently and like it: https://github.com/namhyung/uftrace https://github.com/namhyung/uftrace You can think of it like a dtrace that knows about every function in a C or C++ program. ----- I want to try some kind of code explorer thing. I saw this in a CppCon video and on HN: https://www.sourcetrail.com/ https://www.sourcetrail.com/ And older ones like: https://www.sourceinsight.com/ https://www.sourceinsight.com/ But somehow I get by with Unix tools. I think this is because I feel like building the project in a way to accomodate the source browsers might be a big pain. Counterpoint: I think the hardest part of understanding a project is usually the build system :-) I don't have too much of a problem with reading C, C++, Python, or (sometimes) JS code. Volume is always a problem, but I can read a specific function pretty easily. But the build system is where things get ugly, in my experience. Also, reading multi-threaded code requires some special consideration. grepping for every place that threads are started is a good idea.