[thesz]

  > I do read the code, but reviewing code is very different from producing it, and surely teaches you less. If you don’t believe this, I doubt you work in software.

I work in software and for single line I write I read hundredths of them.

If I am fixing bugs in my own (mostly self-education) programs, I read my program several times, over and over again. If writing programs taught me something, it is how to read programs most effectively. And also how to write programs to be most effectively read.

[padolsey]

> I work in software and for single line I write I read hundredths of them.

I'm not sure whether this should humble or confuse me. I am definitely WAY heavier on the write-side of this equation. I love programming. And writing. I love them both so much that I wrote a book about programming. But I don't like reading other peoples' code. Nor reading generally. I can't read faster than I can talk. I envy those who can. So, reading code has always been a pain. That said, I love little clever golf-y code, nuggets of perl or bitwise magic. But whole reams of code? Hundreds upon hundreds of lines? Gosh no. But I respect anyone who has that patience. FWIW I find that one can still gain incredibly rich understanding without having to read too heavily by finding the implied contracts/interfaces and then writing up a bunch of assertions to see if you're right, TDD style.

[thesz]

Most of the software engineers out there do the support, augmenting source code behemoths the least possible way to achieve desired outcome. I believe that more than 90% of software development was support roles as early as 2K or so.

Not that I had an opportunity to write new code, but most of my work through my experience was either to fix bugs or to add new functionality to an existing system with as little code as possible. Both goals mean reuse and understanding of the existing code. For both "reuse" and "understanding" you have to thoroughly read existing code a dozen or so times over.

Tests (in TDD) can show you presence of bugs, not the absence of them. For the absence of bugs one has to thoroughly know problem domain and source code solving the problems.

[GTP]

> If I am fixing bugs in my own (mostly self-education) programs, I read my program several times

I think here lies the difference OP is talking about. You are reading your own code, which means you had to first put in the effort to write it. If you use LLMs, you are reading code you didn't write.

[hosh]

I read other people’s code all the time. I work as a platform engineer with sre functions.

Gemini 3 by itself is insufficient. I often find myself tracing through things or testing during runtime to understand how things behave. Claude Opus is not much better for this.

On the other hand, pairing with Gemini 3 feels like pairing with other people. No one is going to get everything right all the time. I might ask Gemini to construct gcloud commands or look things up for me, but we’re trying to figure things out together.

[thesz]

If I need to change someone's code, I also read it. several times.

[dongguanxianhao]

>hundredths of them

Man, it would rule so much if programmers were literate and knew how to actually communicate what they intend to say.

[MDCore]

It's obvious from the context here what the intended meaning was. Everyone makes typos sometimes.

[Brian_K_White]

Man it would rule so much if programmers could manage not to be assholes by default so much of the time.

It's ironic that the more ignorant one is the one calling another ignorant.

Alright I've had my fun with the name-calling. I will now explain the stunningly obvious. Not a thing anyone should have to for someone so sharp as yourself but there we are...

For someone to produce that text after growing up in an English speaking environment, they would indeed be comically inept communicators. Which is why the more reasonable assumption is that English is not in fact their native language.

Not merely the more generous assumption. Being generous by default would be a better character trait than not, but still arguably a luxury. But also simply the more reasonable assumption by plain numbers and reasoning. So, not only were you a douche, you had to go out of your way to select a less likely possibility to make the douche you wanted to be fit the situation.

Literate programmers indeed.

[epgui]

Not everyone has English as a first language.