[thankthunk]

> I'm not sure how this is relevant.

It's relevant because you want to limit the number of people who have access to your proprietary software. It's pretty straightforward.

> the more likely they will be able to make nefarious use of the stolen code.

The point is to limit the "surface area". There is absolutely no reason for QA to have access to the source code. Giving them access is simply opening up another security vulnerability. It's not even using the code for nefarious purposes. People can sell the code for money.

> and I've personally seen people who have never written production code review someone else's code and find where it didn't match their idea of what it should do.

What? That makes absolutely no sense. Are you talking about tech leads or managers? Who reviews code who has never written code? That's like saying someone who never learned chinese critiquing chinese literature. Makes absolutely no sense.

> I wish it were more common, but it requires both motivation (on the part of domain experts / non-SWEs) and trust (on the part of the tech folks).

It makes no sense to do so. Especially in terms of security. Especially when proprietary software is involved.

[rahimnathwani]

I accept your points about limiting the surface area, but it applies more to tech companies than it does to other types of companies. For many (maybe most?) companies, their proprietary code is barely useful enough for its intended purpose within the context of that company's operations, and would be less than useful to a competitor.

"Who reviews code who has never written code?"

I'm not talking about reviewing code as in 'code review', but reading code to understand what it's doing.

And I didn't talk about anyone who has 'never written code', but someone who has never written production code. The article also wasn't talking about people who have never written code; if you do a Udemy coding course, you'll write at least some code.

I worked at a place a few years ago that had some popular consumer tech products. I was using one of them, and experienced what I thought was a strange error message. I was able to search the code base for the error message, and read the ~20 lines of code before it, to understand how it was triggered. I was then able to file a very specific bug about what I thought was wrong with the logic. I didn't need to be a SWE, tech lead or engineer manager to do that. I didn't learn to code using Udemy courses, but someone who did could have done the same thing in the same situation.