Algorithms are coming for their jobs, workers are teaching themselves algorithms(latimes.com)
latimes.com
Algorithms are coming for their jobs, workers are teaching themselves algorithms
http://www.latimes.com/business/technology/la-fi-tn-automation-training-20180504-story.html
16 comments
> Of the stories you read in traditional media that aren't about politics, crimes, or disasters, more than half probably come from PR firms.
Always a good read: http://www.paulgraham.com/submarine.html
Always a good read: http://www.paulgraham.com/submarine.html
It's an interesting tidbit about Malware-bytes training QA staff via Udemy. Consumer Software QA is tedious, repetitive, and soul crashing task for many a entry level tech workers. A novel idea to actually encourage staff to "upskill" in position instead of having a vendor provide yet another product to replace company talent. I almost skipped this read because I thought it was another FUD article about technology being disruptive because the title is awful and not accurate.
One goal in testing is to automate yourself out of a job. That and to be sure you can test everything appropriately!
"With their newfound programming knowledge, they're able to identify errors in the company's codebase and contribute to a solution with the company's developers."
Nope, sorry. There's no way that a couple of online Udemy courses suddenly qualifies you to touch our codebase.
Nope, sorry. There's no way that a couple of online Udemy courses suddenly qualifies you to touch our codebase.
Even read-only?
Of course. Especially when proprietary software/intellectual property is involved.
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 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.
> Of course. Especially when proprietary
> software/intellectual property is involved.
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).
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).
> 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.
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.
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.
"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.
There are some things where you can climb up the value chain, such as this example; however, it’s naive to think that most things which can be automated would fall into this category. It’s delisional to think so.
In the long run, AI will keep getting better and will also climb up the value chain. It shall be an interesting race to watch, assuming you could do so from a third person perspective.
I'd like to see more specific & detailed examples.
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”