5 ms·
Reading code always felt awkward, slow and ineffective. The cognitive load is huge, you have to compute some things while memorizing others and at the same time
by jesperlang 9y ago
Reading code always felt awkward, slow and ineffective. The cognitive load is huge, you have to compute some things while memorizing others and at the same time keep track of flows. Thats why I always have pen and paper while diving into a new big code base, you simply can't keep it in your head. But something we forget often is... the goal of reading code is almost always to understand a system or some part of it. And reading code for me is a terrible way to do it.
Code is just one level of abstraction and one way of seeing things. We should have multiple ways of "reading" a system depending on what level we want to understand it. No, I don't think that rushed, out of date "system documentation" you wrote will do. I still think this is not solved in a satisfying way. We could find inspiration from things that works well, just imagine how google maps lets you look at the world at many different levels, from continents down to street level. Also it provides different views of each level, street maps are useful for tourists, terrain maps for hikers and satellite images for someone who want to study vegetation. How you will "read" a system depends on what you are trying to understand.
- stenecdote 9y agoAs the author of the post, just wanted to reply and say I'm totally open to the notion that the solutions I proposed will not solve the problem. I'm much more sure about the problem than I am about the solution. A google maps zoom system for code sounds awesome, although I have no idea how that might work.
- lugg 9y agoBrackets inline editor comes to mind. Just replace CSS definitions with function definitions (I think it might already do this for ?) The zooming functionality you're thinking about probably wouldn't be very practical. (Zooming in down to opcode or out to high level framework calls.) But simply being able to inspect definition inline would do.
- douglaswlance 9y agoI find it useful to write comments about what's happening in the code as I am trying to figure it out.
- CogitoCogito 9y agoAssuming I can, I always study code with a debugger and various simplification techniques (say throw in `abort()` or raise an exception to get a stack trace or throw in `printf()` on interesting objects). Usually I just start it up with `gdb ./program` and step through and see where it takes me. If the code is complex enough, I'll even start ripping out parts to see where it's required (often it's not in whatever simple case you're interested in). If I can't use a debugger (i.e. my initial assumption fails), I usually run for the hills...
- lummax 9y agoCode as a city: https://wettel.github.io/codecity.html https://wettel.github.io/codecity.html
- klenwell 9y ago> But something we forget often is... the goal of reading code is almost always to understand a system or some part of it. And reading code for me is a terrible way to do it. Good point. A couple famous quotes that speak to this[0]: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious. -- Fred Brooks, The Mythical Man-Month Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -- Linus Torvalds [0] https://news.ycombinator.com/item?id=9487819 https://news.ycombinator.com/item?id=9487819
- shalabhc 9y agoSolid upvote and the map analogy is great. I think this is a very important point. We often think of a 'program' as a flat blog of text, but we really should have tools to explore various projections of both static and dynamic constructs that form the program. We should be able to view the high level system view of the running program, and query various interconnections.