[erez]

I hate these kind of headlines. There's nothing inherently special in Virginia Woolf when it comes to programming, and her name isn't mentioned anywhere in the article but the headline, so why use her name? And when I start reading the article, realising this is "to be a better programmer, read novels etc." article, I have no desire to go on reading.

As such, I've been a proponent of reading code like text, instead of the usual maintenance method of locating the line with the bug, making the most minimal change and leaving everything else as-is. I believe the more I read the actual program, the better I can understand why was there a bug, get some insight into the original programmer's thinking, and maybe get some more idea on how to better fix the problem.

[formula1]

To be honest, I have no idea what you mean by "read it like text". Your debugging method of

- locate the issue

- understand the entirety of the segment to avoid other pitfalls and understand the issues intended purpose

- minimize changes to avoid creating bigger problems. Rewrite entire segment if necessary (which is why encapsulation is so important)

I dont see how this is reading it like text or what that means to be honest. When I read poetry I read every single line. When I read a novel, I rarely I will glance over dialogue or entire segments because I understand the inteded gist. When I read the news I look for where the fluff ends and read the paragraph to understand what the hell is going on.

If anything I believe we should read more news to be better debuggers. Locate the problem quickly and understand in its entirety. A personal opinion of course

[erez]

First, broaden the concept of "entirety of the segment". For most it's the immediate scope, or maybe the next level. I'm referring to understanding every element in there, where it comes from, and what it affects, even if you need to look in several other modules for that.

But, the idea is to try and understand why was the code written like that, what is the model the original programmer had in mind, and whether there could be more of the same errors in other places. It's the way you can see a db table and immediately know where will there be issues in the db design.

[formula1]

Yeah, understanding how each peice works is generally a good idea since software tends to be very delicate. I certainly hope a programmer is willing to go deeper and deeper into 3rd party modules until they discover the root of the problem.

When you say it, it sounds complicated, nuanced and elegant. But, from personal experience, it simply relates to mental rules like "make sure your fix doesnt screw up more things" and "if you think a programmer is doing something weird, its probably weird" and "if everything looks fine here, look upstream"

For something like database design, usually there is a restriction of the orm that causes fluff or the programmer is trying to minimize memory usage by reusing variables or something else that can cause utter chaos. Im all for "thinking like the writer", but I feel like that doesnt present actionable steps only to approach it with sympathy. Id argue, get a mental model of minimal necessary steps and see how the other program fits into it or expands upon it.