3 ms·
> entire generation of young "programmers" who don't understand basic computing principles, stacks, interrupts, I/O operations Why would software engineers who
by unity1001 4y ago
> entire generation of young "programmers" who don't understand basic computing principles, stacks, interrupts, I/O operations
Why would software engineers who work on web apps, kubernetes, and the internet in general need to understand interrupts. Not only they will never ever deal with any of that, but also they are supposed not to. All of those have been automated away so that what we call the Internet can be possible.
All of those stuff turned into specializations as the tech world progressed and the ecosystem grew. A software engineer specialized in hardware would need to know interrupts while he wouldnt need to know how to do devops. For the software engineer who works on Internet apps, its the opposite.
- lordfrito 4y agoI'm not dissing cloud engineering. I've learned enough to really repesct the architects behind these large scale systems. My point was about skill level, not specialization. Specialization is great.. we can build bigger and bigger things not having to engineer/understand what's beneath everything. We stand on the shoulders of giants as they say. And I agree, there is no one job specialization that's more valuable than the other. It's contextual. If you have a legal problem, a specialized lawyer is more valuable than a specialized doctor. So yeah I agree that if you have a cloud problem, you want a cloud engineer and not a firmware engineer. Although I should add that things like interrupts/events/synchronization and I/O operations are fairly universal computing concepts even in the cloud world. If you're a cloud programmer and you don't know how long an operation takes / its big-O complexity, how much storage it uses / it's persistence etc. you're probably going to have some explaining to do when your company gets next months AWS bill. And yes plumbing is useful! Someone has to hook stuff up that needs hooking up! But which task requires more skill; the person that designs a good water flow valve, or the person hooking one up? I'd argue the person designing the valve needs to be more skilled (they certainly need more schooling). The average plumber can't design a good flow valve, while the average non-plumber can fix a leaky sink. AI is eating unskilled / low-skill work. In the 80's production line workers were afraid of robots. Well, here we are. No more pools of typists, automated call centers handling huge volumes of people, dark factories. It's a terrible time to be an artist if AI can clipart compose images of the same quality much faster than you can draw by hand. Back to original comment: I'm merely suggesting that some programming jobs require a lot more skill than others. If software plumbing is easy, then it can and will be automated. If those were the only skill I posessed, I'd be worried about my job. Like fusion, I just don't see general purpose AI being a thing in my lifetime. For highly skilled programmers, it's going to be a lot longer before they're replaced. Welcome to our digital future. It's very stressful for the average skilled human.
- unity1001 4y ago> My point was about skill level, not specialization I fail to see the skill level in someone working on the web knowing about interrupts. And a firmware engineer knowing about devops, integrations or react. > Although I should add that things like interrupts/events/synchronization and I/O operations are fairly universal computing concepts even in the cloud world Not really. I/O has nothing to do with cloud, likewise interrupts. Those remain buried way, way down in the hardware that run the cloud at a place where not even datacenter engineers reach. > If you're a cloud programmer and you don't know how long an operation takes / its big-O complexity That still has nothing to do with interrupts or hardware I/O.
- lordfrito 4y ago> I fail to see the skill level in someone working on the web knowing about interrupts As a firmware/app guy I'm not qualified on talking about relative skill sets between different areas of cloud development. I agree that interrupts/threads aren't important at all to the person writing a web interface, should have found a better example. I'm not here to argue, for sure there are talented people up and down the stack. What I can tell you is that I'm amazed at the mistakes I see this new generation of junior programmers making, the kind of stuff indicating they have little understanding of how computers actually actually work. As an example, I continue to run into young devs that don't have any idea of what numeric over/underflow is. We do a lot of IoT and edge computing, so ranges/limits/size of the data being passed around matters a lot. Attempting to explain the concept reveals that a great many of them have no mental concept of how a computer even holds a number (let alone different variable sizes, types, signed/unsigned etc). When you explain that variables are a fixed size and don't have unlimited range, it's a revelation to many of them. Sometimes they'll argue that this stuff doesn't matter, even as as you're showing them the error in their code. They feel the problem is that the other devs built it wrong, chose the wrong language or tool for the problem at hand etc. We had a dev (wrote test scripts) that would argue with his boss that everyone (including app and firmware teams) should ditch their languages and write everything in python, where mistakes can't be made. He was dead serious, ended up quitting out of frustration. I'm sure that was a personality problem, but still, the lack of basic understanding astounded us, and the phrase "knows enough to be dangerous" comes to mind. I find it strange that there is a new type of programmer that knows very little about how computers actually work. I find it stranger that they are even a bit productive in their careers, although I suspect it's because the problem domains they work in are much more tolerant to these kinds of errors. CI/CD system is setup to catch/fix their problems, and hence the job positions can tolerate what used to be considered a below average programmer. Efficient? No. Good enough? Sure. I suspect some of these positions can be automated before the others can.