SoylentNews is people
SoylentNews
The idea that American workers are being left in the dust because they lack technological savvy does not stand up to scrutiny. Our focus should be on coordination and communication between workers and employers.
Technology enthusiasts and entrepreneurs are among the loudest voices declaiming this conventional wisdom (see "The Hunt for Qualified Workers").
Two recent developments have heightened debate over the idea of a "skills gap": an unemployment rate below 5 percent, and the growing fear that automation will render less-skilled workers permanently unemployable.
Proponents of the idea tell an intuitively appealing story: information technology has hit American firms like a whirlwind, intensifying demand for technical skills and leaving unprepared American workers in the dust. The mismatch between high employer requirements and low employee skills leads to bad outcomes such as high unemployment and slow economic growth.
The problem is, when we look closely at the data, this story doesn't match the facts. What's more, this view of the nation's economic challenges distracts us from more productive ways of thinking about skills and economic growth while promoting unproductive hand-wringing and a blinkered focus on only the supply side of the labor market—that is, the workers.
https://www.technologyreview.com/s/608707/the-myth-of-the-skills-gap/
What do you think, is there a shortage of skilled workers ??
(Score: 1) by tftp on Saturday August 26 2017, @01:29AM (2 children)
My personal anecdote is that we were searching like crazy and couldn't find any contractor who'd be able to take an existing Android project and make changes in it. It's not even a difficult project - mostly USB and OpenGL, with some JNI thrown in. The candidates struggled for weeks to even comprehend who calls who. They were asked to add some gestures using an existing gesture processor class to resize some parameters... FAIL. We tried Indians, we tried Americans - no difference. The project is on hold for lack of smart people.
(Score: 3, Informative) by PocketSizeSUn on Saturday August 26 2017, @04:46AM (1 child)
Usually when I see jobs like you describe come up there are short term low budget deals.
The experience need for USB, OpenGL and JNI are each crossing boundaries that inexperienced people will have never touched.
JNI: Means you have to know Java and C well enough to understand the bridging API and it's caveats. It's not hard, but for people who were only taught 'Java' it is a non-starter.
OpenGL: Yet another sub-language in and of itself with several sub-variants (The original OpenGL 1 is a completely different beast from 2.0 in a lot of ways the difference from 2.0 to OpenGL ES is relatively minor. And to do anything non-trivial you almost always need to be aware of vendor specific crap.
USB: Another wide open mess, again, if you have not done it then it's a real non-starter ... what do you need to talk to and what API exists to get there?
So I'm not at all surprised you are having trouble finding someone.
(Score: 1) by tftp on Saturday August 26 2017, @08:02PM
If it interests anyone, the project was supposed to be a GUI monitor for an industrial hardware. The machine produces some data for graphs and charts and streams it through the USB (slowly enough) into the Android device. Here is where JNI comes in - the API for the hardware is written in C and is portable. The USB stack, though, is native - LibUSB required root last time I checked, and that is a big inconvenience. Anyway, there is nothing to hack there - this part works.
The OpenGL ES handles the 2D charts [ntu.edu.sg]. They need to be updated fast enough without reliance upon the CPU, so OpenGL is very good choice here. The projection matrix is already configured and works. The GPU renderer is programmed and works. Lots of other code exists to handle the gestures, annotations (OpenGL is weak on text,) the reticle grid, and many more. There is nothing left to invent from scratch - we always do that first. What needs to be done is just the usual maintenance - add this button here, this little function there, improve the scrolling, update the API to the latest, etc.
I was amazed primarily with general ineptness of the candidates. I can understand if they don't quite grok the layout of the arrays of vertices, for example - I can explain that and it won't take long, OpenGL has only ten primitives [khronos.org]. But what happened is that they look at the code and fail to comprehend what they see. That cannot be explained, unless I read them the book "Android for dummies" for a year. I got a feeling that they ran the IDE before and, possibly, compiled the stock "Hello, World!" app - but had done not much more than that. Candidates came with excellent self-written resumes, but these writings appeared to be just a waste of electrons.
We were not looking for the cheapest coders - and, in fact, these candidates were expensive, for the month that they were given to get started. This project had sufficient funding. I can suspect that Google and Apple, our neighbors, vacuumed up everyone who can [successfuly pretend to know how to] code for Android, and the rest, who know what they are doing, turned into one-man shops that sell inexpensive apps. The "free electrons" - those contractors - appear to be those who cannot get hired by the big guys and who cannot hang their own shingle. No surprise that they cannot handle a relatively simple task, even though the task is linked against a few specialized libraries. Their problem was not in specialized stuff, but in basics - one of the candidates, for the life of him, could not comprehend how the screen coordinates are translated into the world coordinates - and the code has a set of convenient classes exactly for doing that! They failed miserably - not because they had a wrong color of skin or a wrong accent (they were from different places, including locals) but simply because they are incapable of doing the work.