Oh wow, this is totally my jam. I love seeing this on HN because it’s a challenge to me to find analogies of how I can use this to inform my programming practic

Oh wow, this is totally my jam. I love seeing this on HN because it’s a challenge to me to find analogies of how I can use this to inform my programming practice (and how I might use programming to inform my queer, feminist theory and critique)! Here are some analogous experiences I thought of while reading: >The work of undoing what you know, or what you think you know, is hard. Trying to swerve around cargo culting, not getting so locked into one programming pattern >“next step is to get students to interact critically with the writing” One of the main reasons I love programming. Ask why one sequence of operations was applied versus another. Surface hidden complexity. To me, the exchange of code review and questions makes programming such a fun and in-depth form of collaborative writing. > “Take notes in the margins: mess with the text. Underline, star, jot down questions.” This mindset of interactive reading is exactly what has helped me be successful as a programmer. When I am reviewing code, I pull and try to mark it up with comments, drop in debuggers locally, snoop on variables. > Linger over passages that are unclear or that strike you as particularly helpful or that don’t jar well with you How I know when I’ve found a code smell, haha. > Contextualize the writing A good reminder for writing PR descriptions. I tend to get my note into the trees right before a PR and sometimes it’s hard to zoom out! > “Scaffold your question with the information people need to answer it; ground your question deeper into the text itself.” This is lovely. A nice reminder to me: before I run off and bug our senior DBA with a vague question, I should gather nearby context clues, log output, what I’ve tried, repro steps, whatever I can to support my question. > A good discussion question reframes some of the problems of the text Some of my fav technical mentors would ask questions to poke holes in my argument (my code), rather than telling me “X won’t work.” Their questions would inevitably cause me to dig into the why. > If you can answer your question while you are writing it Rubber ducking! On charting institutional and personal knowledge: > when we pool all of our knowledge because it really makes clear the overwhelmingly rich and global resources for left thinking that are both there to be accessed and also suppressed and forgotten as origins for our current thinking. I can think of many engineer discussions where mob diagramming what the group believes the architecture / structural history is reveals new information to folks and gaps in understanding. This are just some of the bridges I see between this post and my daily work of writing code. Thank you for sharing this!