Thank you so much for the video, I think my absolute biggest weakness is reading foreign code and hearing some advices is very useful. Would it be possible to have a bigger font size next time? As a TH-cam mobile user I gotta have a 2.5x zoom lol
my algorithm for exploring code is trying to follow the "signal flow"(not sure what else to call it, this what we called it in audio engineering) for some piece of functionality im interested in understanding. Ill just make little flowbox charts on excalidraw/draw-io and it really helps me visually parse how files/routines are linked together.
This is really useful for some tasks like debugging, or for tracing code where a signal passes through a lot of filters (like Pipewire, Iptables, much audio software, some parts of Kubernetes, etc). If you're in audio engineering, then this is probably a fantastic technique in general. But as I talk about at 18:26, it's usually not my standard approach. There are a few reasons for this. You can think of this strategy as something you get by drawing the call graph and plotting a path through it. The call graph can change a lot through refactoring, and in principle you should be able to abstract away from those details to understand a piece of code. So the call graph in a sense has too much extraneous detail. What you end up doing is trying to find some sort of isomorphism from the call graph to the underlying conceptual graph that the humans intended, clearing away convenience function calls and branching etc. But that's a lot of cognitive overhead. So it's usually clearer to me to focus on things like data structures and algorithms. The flow of a signal through a bunch of callers is then one kind of data structure/algorithmic approach. In my experience, the best thing that gives the "signal flow" kind of clarity for an arbitrary piece of complicated software is probably a good design doc written before the code was written. Design docs have only the detail that humans think are relevant to the engineering. Internally at Google those exist and are an outstanding resource toward the beginning of a project, but they eventually get out of date. Unfortunately it's really rare in the open source world to find a good design doc. That said, I generally take a very signals engineering approach to almost everything. I tend to think of everything as a sort of control system. So I'm very sympathetic to the approach.
@@ants_are_everywhere Thanks for explaining deeper where you feel this approach begins to break down. Definately something ill keep in mind when diving into a bigger project next time. I've only really encountered this when i wanna make a OS contribution to some specific feature of a piece of software. There I can get away with a limited scope of understanding in terms of how the project is overall engineered, and just focus on the flow of inputs/outputs from that feature. Ill keep this nugget in my head, ty. > "The flow of a signal through a bunch of callers is then one kind of data structure/algorithmic approach." Its interesting to me that you specify a design docs written BEFORE the code, and not just design docs in general. Care to elaborate a bit, id love to hear ur thoughts?
Just in practice that after the code is written it's hard to write an honest design doc that isn't just a description of what you did. It's kind of like the difference an architectural model produced during the design phase and a replica of an already-built structure. Part of it is probably that during the design phase your goal is to clearly describe to humans what you intend to do. You want to do that so you get good feedback and don't build the wrong thing. But after it's built, people tend to focus on making sure the documentation is technically accurate and complete, not clearly communicating on the human level. > There I can get away with a limited scope of understanding in terms of how the project is overall engineered, and just focus on the flow of inputs/outputs from that feature. Oh yeah totally. And definitely if you're skilled at it, then it makes sense to keep exploiting that skill as much as possible.
fundamentally deep advice, thanks for this. But is there any way to generate visual abstractions or physical intuitions about the specific snippets of code, like envisioning the entire internal process visually such that the code is just a syntactical expression capturing those elements of thought? I am speaking more like how people like Richard feynman used to translate maths or equations in specific intuitively.
Hey thanks for the kind words! There are a few ways I'm aware of to create meaningful visual depictions of the code, but I'm not a very visual thinker so I don't know how useful they are. Some common kinds of visualization: 1. Represent the code as a graph and draw the graph. For example, a. draw the AST (abstract syntax tree) like this: raw.githubusercontent.com/Codecademy/docs/main/media/abstract-syntax-tree.png. b. create a graph of the inheritance structure, e.g. using modeling tools like UML c. draw a function call graph 2. Create representations of the running program, e.g. flame graphs 3. Rewrite the code in a visual educational programming language like Scratch 4. Implement it as a cellular automaton and watch the cellular automaton evolve And there are many tools that help visualize things like performance, code health etc. The Feynman process is usually something you do after understanding a concept on its own terms. It's basically creating a lossy compression specific to a topic, and to create that compression you need to know which elements you can throw away while still retaining the core meaning.
@@monsieurLDN those are great things for visualizing code. I was taking the question to be asking about artifacts we can generate from the code itself before we understand it. The approaches I mention above in 1.b are a kind of block diagram and in 1.c are a kind of flow chart. But to get a really clear block diagram or flow chart, you need to understand the code. If you like diagramming, this is potentially something you could start with a first draft of and simplify over time. But there are always other things you can visualize, so I wouldn't call them the *only* tools.
This video is vague and provides no examples. Anything topical starts from 14:00, which is less than half of the video. Tips and Tricks implies that it's an educational video that should take you from point A to point B as much closely to practical value as possible. Learn to read books first - is not the topic such video should be primarily invested in. If it is not a tutorial but a mind journey, it should be named that way, not "tips and tricks" (that implies some sort of inductive or abductive style of explanation). Maybe next time think primarily about humans, not affiliate marketing. That way you will bring some value to this world.
Hey thanks for the comment. I appreciate that you have specific concerns that you've stated directly. I could do without the snarky second paragraph, but I won't hold that against you. Nevertheless I disagree with just about everything you've said. Second paragraph first, I think primarily about humans. That's actually part of the video. The channel is a volunteer effort I run on my own dime. It costs thousands to run and has made about $200. The small amount of money it makes is set aside as donations toward the open source community. I have a single affiliate link, which is to a book written 84 years ago. 14:00 starts what I think is the least important part of the video, which is why it was last. It basically says that it's easier to read code if you know the basics of CS. Any fool can tell you that. What people who come to my channel have been asking for are the more subtle tips and strategy behind what I'm doing in the other videos. > educational video that should take you from point A to point B as much closely to practical value as possible There is a lot of content like this and almost all of it I'd consider to be poor from an educational standpoint. Content is created like that because it's effective at driving eyeballs not because it's effective at education. You can learn from those videos, but generally speaking it will take you longer than if you learn from something with higher information density. I think part of what's going on is you're not in a place where this video is scratching an itch you have yet. But it is scratching an itch others have. And you may find it's the perfect video for you at a later time.
Hey Ants are everywhere , really nice video ! I was wondering if I could help you with more Quality Editing in your videos and also make a highly engaging Thumbnail and also help you with the overall youtube strategy and growth ! Pls let me know what do you think ?
Potentially... I think I'm honestly at least a month or two from wanting to hire someone to help with the channel. I'd ideally like to find someone who understands what we're up to and where we're going. I'd be happy to chat, could you send a DM on X or Discord or something?
This is actually a useful video, most juniors(including me) struggle getting familiar in a new codebase and being productive in it
@@EliasOjeda-mv6cg thanks! Please share it with folks you think might benefit
This is one of the most intelligent and helpful discussions about programming (and learning) that I've seen on youtube
hey thanks! 😎 Please share it with anyone you think might like it
Your content is so good in the sea of garbo on this platform
thanks! 😎
you are the best . i might write a blog post on this , more people can benefit from this kind of mental model
@@danishmehmood6110 that would be great! Send me the link if you write it up!
@@ants_are_everywhere i sure will
Thank you so much for the video, I think my absolute biggest weakness is reading foreign code and hearing some advices is very useful.
Would it be possible to have a bigger font size next time? As a TH-cam mobile user I gotta have a 2.5x zoom lol
Hey thanks! Sure I can increase the font next time. Sorry about that!
Thank you so much for this!
I'm glad you enjoyed it!
Sage advice.
Thanks!
Never seen this channel before. I’m glad I found it, looks great.
Welcome aboard! If you know others who would like it please spread the word!
AYYY let's goo! I can't wait to watch this! Thanks for making it
hope you enjoy it!
my algorithm for exploring code is trying to follow the "signal flow"(not sure what else to call it, this what we called it in audio engineering) for some piece of functionality im interested in understanding. Ill just make little flowbox charts on excalidraw/draw-io and it really helps me visually parse how files/routines are linked together.
This is really useful for some tasks like debugging, or for tracing code where a signal passes through a lot of filters (like Pipewire, Iptables, much audio software, some parts of Kubernetes, etc). If you're in audio engineering, then this is probably a fantastic technique in general. But as I talk about at 18:26, it's usually not my standard approach.
There are a few reasons for this. You can think of this strategy as something you get by drawing the call graph and plotting a path through it. The call graph can change a lot through refactoring, and in principle you should be able to abstract away from those details to understand a piece of code. So the call graph in a sense has too much extraneous detail. What you end up doing is trying to find some sort of isomorphism from the call graph to the underlying conceptual graph that the humans intended, clearing away convenience function calls and branching etc. But that's a lot of cognitive overhead. So it's usually clearer to me to focus on things like data structures and algorithms. The flow of a signal through a bunch of callers is then one kind of data structure/algorithmic approach.
In my experience, the best thing that gives the "signal flow" kind of clarity for an arbitrary piece of complicated software is probably a good design doc written before the code was written. Design docs have only the detail that humans think are relevant to the engineering. Internally at Google those exist and are an outstanding resource toward the beginning of a project, but they eventually get out of date. Unfortunately it's really rare in the open source world to find a good design doc.
That said, I generally take a very signals engineering approach to almost everything. I tend to think of everything as a sort of control system. So I'm very sympathetic to the approach.
@@ants_are_everywhere Thanks for explaining deeper where you feel this approach begins to break down. Definately something ill keep in mind when diving into a bigger project next time.
I've only really encountered this when i wanna make a OS contribution to some specific feature of a piece of software. There I can get away with a limited scope of understanding in terms of how the project is overall engineered, and just focus on the flow of inputs/outputs from that feature.
Ill keep this nugget in my head, ty.
> "The flow of a signal through a bunch of callers is then one kind of data structure/algorithmic approach."
Its interesting to me that you specify a design docs written BEFORE the code, and not just design docs in general. Care to elaborate a bit, id love to hear ur thoughts?
Just in practice that after the code is written it's hard to write an honest design doc that isn't just a description of what you did. It's kind of like the difference an architectural model produced during the design phase and a replica of an already-built structure.
Part of it is probably that during the design phase your goal is to clearly describe to humans what you intend to do. You want to do that so you get good feedback and don't build the wrong thing. But after it's built, people tend to focus on making sure the documentation is technically accurate and complete, not clearly communicating on the human level.
> There I can get away with a limited scope of understanding in terms of how the project is overall engineered, and just focus on the flow of inputs/outputs from that feature.
Oh yeah totally. And definitely if you're skilled at it, then it makes sense to keep exploiting that skill as much as possible.
fundamentally deep advice, thanks for this.
But is there any way to generate visual abstractions or physical intuitions about the specific snippets of code, like envisioning the entire internal process visually such that the code is just a syntactical expression capturing those elements of thought? I am speaking more like how people like Richard feynman used to translate maths or equations in specific intuitively.
Hey thanks for the kind words! There are a few ways I'm aware of to create meaningful visual depictions of the code, but I'm not a very visual thinker so I don't know how useful they are.
Some common kinds of visualization:
1. Represent the code as a graph and draw the graph. For example,
a. draw the AST (abstract syntax tree) like this: raw.githubusercontent.com/Codecademy/docs/main/media/abstract-syntax-tree.png.
b. create a graph of the inheritance structure, e.g. using modeling tools like UML
c. draw a function call graph
2. Create representations of the running program, e.g. flame graphs
3. Rewrite the code in a visual educational programming language like Scratch
4. Implement it as a cellular automaton and watch the cellular automaton evolve
And there are many tools that help visualize things like performance, code health etc.
The Feynman process is usually something you do after understanding a concept on its own terms. It's basically creating a lossy compression specific to a topic, and to create that compression you need to know which elements you can throw away while still retaining the core meaning.
Are block diagrams and flow charts not the only thing you need fir visualizing code
@@monsieurLDN those are great things for visualizing code.
I was taking the question to be asking about artifacts we can generate from the code itself before we understand it. The approaches I mention above in 1.b are a kind of block diagram and in 1.c are a kind of flow chart.
But to get a really clear block diagram or flow chart, you need to understand the code. If you like diagramming, this is potentially something you could start with a first draft of and simplify over time.
But there are always other things you can visualize, so I wouldn't call them the *only* tools.
/ is your friend.
in org-mode?
finally
thanks for your patience :)
This video is vague and provides no examples. Anything topical starts from 14:00, which is less than half of the video. Tips and Tricks implies that it's an educational video that should take you from point A to point B as much closely to practical value as possible. Learn to read books first - is not the topic such video should be primarily invested in. If it is not a tutorial but a mind journey, it should be named that way, not "tips and tricks" (that implies some sort of inductive or abductive style of explanation).
Maybe next time think primarily about humans, not affiliate marketing. That way you will bring some value to this world.
Hey thanks for the comment. I appreciate that you have specific concerns that you've stated directly. I could do without the snarky second paragraph, but I won't hold that against you. Nevertheless I disagree with just about everything you've said.
Second paragraph first, I think primarily about humans. That's actually part of the video. The channel is a volunteer effort I run on my own dime. It costs thousands to run and has made about $200. The small amount of money it makes is set aside as donations toward the open source community. I have a single affiliate link, which is to a book written 84 years ago.
14:00 starts what I think is the least important part of the video, which is why it was last. It basically says that it's easier to read code if you know the basics of CS. Any fool can tell you that. What people who come to my channel have been asking for are the more subtle tips and strategy behind what I'm doing in the other videos.
> educational video that should take you from point A to point B as much closely to practical value as possible
There is a lot of content like this and almost all of it I'd consider to be poor from an educational standpoint. Content is created like that because it's effective at driving eyeballs not because it's effective at education. You can learn from those videos, but generally speaking it will take you longer than if you learn from something with higher information density. I think part of what's going on is you're not in a place where this video is scratching an itch you have yet. But it is scratching an itch others have. And you may find it's the perfect video for you at a later time.
This comment is childish and unessential to humans.
@@SlinkyD you can read? o.O
@@shushtain Nope. Str8 illegitimate. I do know letters supposed to sound when put together.
idk why yt recommends me.low quality content
for real you should watch my videos instead
@@ants_are_everywhere Hey just one tip, try getting right to the point at the start of the video then elaborating more after it
@@systemoutprinthakimwhat a fascinating theory. Please tell me more
I suggest you two may find benefit in self-reflecting on your attention spans.
@@trudyandgeorge ding ding ding!
Hey Ants are everywhere , really nice video ! I was wondering if I could help you with more Quality Editing in your videos and also make a highly engaging Thumbnail and also help you with the overall youtube strategy and growth ! Pls let me know what do you think ?
Potentially... I think I'm honestly at least a month or two from wanting to hire someone to help with the channel. I'd ideally like to find someone who understands what we're up to and where we're going. I'd be happy to chat, could you send a DM on X or Discord or something?
@@ants_are_everywhere i think you'd fine one soon... channel's grown so much since inception. keep going man!