[nickdrozd]

> You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it.

There is certainly some truth to this. On the other hand, it's possible to become blinded to defects in code you've written yourself. You see what you intended for the code to do rather than what it actually does. Reading someone else's code, it can be easier to see what's really going on, since you just see what's there.

[xanderlewis]

The comparison with mathematics also makes sense here. It’s much easier to spot typos in other peoples’ work than your own for exactly that reason: when you read back what you wrote, you read back what you meant to write rather than what’s actually there.

Open any textbook (even a fourth edition of a famous one, written by an expert) and you’ll find countless typos. In fact, in a certain sense, the more expert you are the less suitable you are as a proof reader for such books.

[lanstin]

One of my undergrad tutors taught complex analysis with a book she had written, and she offered a reward for any one who found an error. She said the best students never claimed the reward, only the people that had to study each word carefully.

[jpc0]

You touched on it but I've experienced the same reading code when I knew what was intended by the code, regardless of who wrote it. I miss obvious but simple bugs because I only read what it is mean to do.

[saghm]

I often tell younger engineers that the human brain is the slowest, lowest-memory, and most error-prone runtime for a program. If they're stuck trying to figure out a bug, one of the most effective things they can do is validate their assumptions about what's happening, because there wouldn't be a bug if everything was happening exactly according to expectations.

[alphazard]

> wouldn't be a bug if everything was happening exactly according to expectations

This isn't quite true, especially concerning distributed systems. It's relatively common for a software system to be broken by design. It's not that the developer didn't know how to use the programming language to get the computer to do what they want. It's that what the developer wanted reflects a poor model of the world, a logical inconsistency, or just a behavior which is confusing to users.

[wruza]

That’s why I learned to log literally everything into stdout unless a process is time-sensitive and it’s deep production and it passed the mark where bugs and insights occur once a month+ and there’s zero chance someone asking me what exactly happenes with X at Y afternoon-ish last Friday.

The obvious exception are recursive number-fiddling algos which would spam gigabytes of output due to big N.

This way I can just read assumptions and see branches taken and what’s wrong as if it was written in plain text.

When I see klocs without a single log statement, to me it’s readonly and not worth touching. If you’re stuck with a bug, log everything and you’ll see it right there.

[nfw2]

This is one of the reasons I think that the push towards server-side UI is misguided. It's much easier to walk through the runtime of a program running locally than it is to step through a render that's distributed across a network.

[hinkley]

I, for instance, learned years ago to refuse to help people debug promise chains in languages with async-await semantics. Rewrite it and then get back to me if it still doesn’t work. They usually transcribe the intent of the chain and not the letter of it, fixing the bug they can’t see. And if not the error makes enough sense they can figure it out.

[stonemetal12]

I believe that is the source of "the worst code I have seen is code I wrote six months ago" feeling. It has been long enough that the code has fallen out of your memory, making you less blind to the defects. You can now see it as an outsider would see it.

[HumblyTossed]

I don’t think that quote is true in all situations. I have worked with a couple developers long enough their code reads to me as easy as my own.

[ahoka]

Sometimes when I do code reviews, I understand other's code better than they do and find bugs they don't see. So yeah.

[jmkr]

There's some idiom that says something like "you don't understand something if you can't explain it." I think this is the real point of code review. To make a case for why your code is valuable. If it's just a blob of 1000 lines of "refactor" or "adding feature." It means nothing. A good commit has some kind of abstract tailored to what work was done.

Then a review becomes something like "the claim was made this function does this, does it look like the function does what it says it does?" If you can understand it in context, then you've added trust and knowledge of how it works.

However it seems to often be the case a review turns into "I like this word better than that word" so back to the explaining it point, it becomes a bit of a self review with the hope it might be helpful to somebody else in the future.

[lanstin]

There is a balance there. You can have 1000 trivial commits making it hard to see the fact you just have 10 features, and ten mind-breaking commits making it hard to see what each feature entails. (Then there's the 50 commits "try this" where you are fighting CI or CD and can't test without going thru a git commit/push.)

[noufalibrahim]

This is true and it's one of the problems I have with code generators and these days, AI generated code.

[iamflimflam1]

Nothing beats the experience of looking at code you wrote a year ago and thinking “who the hell wrote this nonsense”