[saurik]

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".

[wpm]

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.

[StopDisinfo910]

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.