Algorithms are coming for their jobs, workers are teaching themselves algorithms
latimes.com
latimes.com
I’ve seen these types of moves several times in the enterprise and it seems to me an HR covering-its-ass move so that they can fire people with cause for not having the skills to perform a job role that changed under the employees feet. This is at least 10x cheaper than losing unemployment claims.
“Hey, we gave them access to some training videos and they just didn’t seem to be able to keep up”
Always a good read: http://www.paulgraham.com/submarine.html
Nope, sorry. There's no way that a couple of online Udemy courses suddenly qualifies you to touch our codebase.
I don't know of any tech shop that makes the source code available to the QA. QA is normally a "black box" operation. It exists to test/use the software as your client/user would. So QA just tests the software/app and then signs off on it or if there is an error, they update the bug tracker and assign it to the relevant dev.
I'm not sure how this is relevant. Surely, the more qualified someone is in software engineering, the more likely they will be able to make nefarious use of the stolen code.
> I don't know of any tech shop that makes > the source code available to the QA.
Sure, that's fair.
My point wasn't about QA specifically, but about GP's point about not letting someone who has (only) completed a couple of Udemy courses touch the code. That doesn't seem warranted, 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.
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'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.
"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.