What Not Reading Does to Your Writing | Hacker News Reader

What Not Reading Does to Your Writing

countercraft.substack.com

While it might be useful to state it again occasionally, I think people would generally find it strange to have a career writing books--wherein you might only publish ten books in your entire life--without having not just read but carefully studied hundreds of books written by other people. And yet, I feel like most of the software developers I know might technically read code in the sense that they have to to edit it, or to review edits by coworkers, but they have potentially never sat down and simply read through and fully internalized the entirety of even a single codebase that they weren't somehow involved with developing... and they think that is "normal".

I've found for me what helps me do such things is actually writing, but writing about what I read. It forces me to not gloss over or skip anything. Like a form of recital. "This function takes a pointer called blah and uses it to blah blah...". I'll go line by line basically rewriting the program in plain English. Especially helpful for languages I'm not that familiar with.

As someone mostly self taught that's how I've always done it until I do it enough I can do it in my head.

Reading a lot will not make you a good writer. It will hopefully get you familiar with the main characteristics of a good story, give you vocabularies and some ideas of how you should structure your writing and what you can do, but anyone who has attempted or studied creative writing now that it's fundamentaly different than just reading. It's like solving puzzles and building puzzles. To design a good puzzle, you need to understand how people will solve it but it's not enough.

Same with code but even worse because code is non linear. The reality is that you need to manipulate things to understand how they fit. You can read all the architecture schemas you can find and review a ton of good implementations - hopefully you will have done that during your study - but you won't trully understand any of that until you have successfuly added something to a code base. That's why onboarding new people is so difficult. But I think I fundamentally disagree with your premise. Most people work all their lives on things they weren't involved with developing. Green field development is the exception not the rule.

Reading a lot will not make you a good writer... and yet, I would have thought we would all be surprised if not reading at all didn't make you a bad writer (which is the angle taken by this article, as opposed to your strawman inversion). There are "great works" of software development, some of which aren't even in active production: the chance that they are codebase you will personally work on are approximately 0. Can you image a curriculum for literature or film or art or architecture or any other creative endeavor that didn't involve lots of critiques of old works? I cannot: it is firmly embedded in the entire concept of these fields... and yet, the vast majority of curriculums for software engineering do not involve ever cracking open existing real code -- not a pedagogical example to demonstrate how to do something in the small, but one of the great works of software, to see how things actually got done in the large -- to read, analyze, and critique.

>This “TV brain” prose is influenced primarily by narrative visual media—TV, film, TikToks, video game cut scenes, etc.

This trend is very palpable, I'm resistant even to the oft used description of passages, pages, or chapters as "scenes".

Reply on news.ycombinator.com