Has anyone read The Programmer's Brain and have an opinion about it? I'd like to improve my ability to read and understand code and was thinking about reading it.
Writing code is easy, reading it isn't
61–70 of 76 posts
Re: Writing code is easy, reading it isn't
#62I am really bad at reading code to be honest (especially other people's code). Any tips on how I can go about becoming good at this like starting from baby steps?
Practice, context and domain-specific knowledge. #1 is easy, #2 requires some investigation, #3 requires studying. If you're looking at say, banking code - but you know nothing about finance - you may struggle to understand what it's doing. You may want to gain some domain expertise. Being an SME makes reading the related code a heck of a lot easier. Context comes down to learning the code base. What code calls the p…
Very good advice!
To add to the above; IME, #3 comes first. Study the domain to understand the concepts and their relationships. Read some books/Articles, Watch some Videos, Read Documentation etc. to come up to speed on the terminology/jargon and the general concepts/ideas. Then, in order to understand their mapping to the specific application at hand, sit with the local "guru" (there is always at least one in every group) and pick his/her brain for a few sessions (getting them brown bag lunches works great for this) on the overall architecture of the System. Next sit with testing and use the app as an end-user to understand use-case scenarios which brings all of the above together.
During all the above stages, take copious notes, draw diagrams/graphs/etc. use source code analysis/documentation/browsing/etc. tools eg. doxygen/cscope/opengrok/etc. tools to navigate the codebase and cement understanding. Note also that the above stages are to be done both iteratively and parallelly until you are somewhat comfortable and not necessarily know/understand everything.
With the above in hand, pick one use-case scenario, preferably the most complicated, critical and important one and walk through the code from beginning to end for that path. Remember that you are trying to get the overall picture and hence treat all irrelevant details as blackbox abstractions during initial phases. Over time as you iterate and review the code again and again you can slowly add in the details for a more comprehensive understanding.
Finally, there is no shortcut to the above; it takes time and self-effort. We Humans are natural-born, trial-and-error, continuous-learning problem solvers and so trust to your intelligence and commonsense to find a path to move ahead when stuck at something.
Re: Writing code is easy, reading it isn't
#63You need to be twice as smart to debug code as you need to be to write it. So if you write the smartest code you can, then you by definition are too dumb to debug it Just write simple code
This is not just about writing code, but designing systems. If you design the smartest (most complex) system you can, you won't be able to debug/fix/extend/maintain it.
Re: Writing code is easy, reading it isn't
#64This is the same dissonance as the post about "never write bugs". The premise is wrong to think of code as something you can fit in your brain like you remember the shape of a new building you frequent or a persons face.
You need to both remember the processing done in the code and the structure. The structure will need your working memory in the language center as its n-dimensional and not representable with a closed surface 3D model - at maximum you can do graphs which well dont look like much you will be able to draw from memory.
Remembering state and data needs your whole brain to debug what will happen when you run the code.
All people here telling you they can train this train either an abstract concept like functional programming or work with software in their field which will have a similar scope - you will NOT be able to easily comprehend code written in another style or purpose. Don't be mistaken doing 10 years of mobile apps, ERP or whatever would allow you to follow any C-written code for systems or sth.
Fitting code as an abstraction in your mind is literally neurons growing new pathways - its expensive, no one likes doing it and if you are not in the same field you will try to bend it into your domain or not engage much.
Trying to find general assumptions here will not work - if you could condense n-dim rulesets to some general principles - you would simply do so and refactor the code.
Thinking theres no way to debug abstracted, proveable code you can not fit fully in your working memory is wrong, because you only need to test each function / morphism to be correct, not the whole thing. Its certainly doable to write systems that interconnect 30-40 entities you need NOT remember all at once and still end up with bugfree code because each part is constrained to strict interfaces and types.
That's how rulesets with bigger scopes work - no one designs the aircraft carrier all alone - there's restrictions and interfaces everywhere, not a single engineer knows the whole thing down to the molecules and electrons. Still it works.
Re: Writing code is easy, reading it isn't
#65This is positively false. In my anecdotal experience, I have produced code that was brutal to write, but then it was easy to read afterward.
Just like a piece of music being easy to listen to after sweating out the composition.
Sone coding is like solving the puzzle. Once it is written and debugged, you're looking at the solution. The code will readily spoon-feed you the solution again when you revisit it months or years after forgetting everything, possibly even its existence.
Wen code is easy to write but hard to read, you must be writing fluff. Maybe try to steer your career a bit away from that. But do improve your ability to make fluff readable.
Re: Writing code is easy, reading it isn't
#66You need to be twice as smart to debug code as you need to be to write it. So if you write the smartest code you can, then you by definition are too dumb to debug it Just write simple code
Good ol' Kernighan strikes again [0]
Re: Writing code is easy, reading it isn't
#67KISS yet they want to test leetcode bs. the irony in this industry...
Re: Writing code is easy, reading it isn't
#68This is not unique to the age of LLMs. PR reviews are often shallow because the reviewer is not giving the contribution the amount of attention and understanding it deserves. With LLMs, the volume of code has only gotten larger but those same LLMs can help review the code being written. The current code review agents are surprisingly good at catching errors. Better than most reviewers. We'll soon get to a point where…
I wonder if the paradigm shift is the adoption of a higher level language. Akin to what python did to blackboxing C libraries.
I'm not a programmer but I always had the impression that different languages were appropriate for different tasks. My question is, "For what type of programming tasks is English the correct level of abstraction?"
Re: Writing code is easy, reading it isn't
#69I am really bad at reading code to be honest (especially other people's code). Any tips on how I can go about becoming good at this like starting from baby steps?
I find it useful to open the code in an editor and make running notes in the comments about what I think the state should be. As long as the code has good tests you can use debugging statements to confirm your understanding. As a bonus you can just send that whole block of code - notes and all - to a colleague if you get stuck. They can read through the code and your thoughts and give feedback.
Neat technique!
Re: Writing code is easy, reading it isn't
#70You need to be twice as smart to debug code as you need to be to write it. So if you write the smartest code you can, then you by definition are too dumb to debug it Just write simple code
[dead]