> The recent maturation of AI revealed how many people in software seemingly loathe their own profession.
I always had an inkling this was the case, but man it's been depressing to see it laid so bare. So many proudly screaming "I hated programming!". Well, I don't, I love it, and have my entire life, and imagine I'll continue to as long as they will let me...
More relevantly to the article and comment we're replying to: I miss doing firmware engineering. Gosh that is so much fun.
I can assure you the same thing is coming to fw and ee as well. If your in hw because you like building stuff its going to be a fun time to be alive, but there will be large chunks of engineering work that go away.
Oh I'm well aware. It's lagging behind "pure" software, but is catching up.
The only thing I can see that acts as a bulwark is liability, bascially. The FW work I was doing requires a human and a large amount of careful review before acceptance. The "throw slop at the wall" that my current job is okay with won't fly there.
But there's _lots_ of FW jobs in consumer gear that is already filled with god awful slop, so maybe it won't take as long as I think.
I remember my Apple II days (different platform, similarly constrained environment) where every game had a hard real-time multitasking core under all the code. In the Apple II it was particularly critical, because you didn't have programmable sound generators - you had to programmatically change the voltage of the speaker. If you were really crazy, you could do PWM and expect the electronics of the board would coerce your output square wave into something pleasant.
It never worked well, but it was still super cool.
I'm the other way around, I've been shocked to learn how many computer scientists consider programming to be the core of their work. I had always understood programming as simply an end to a means in order to implement a design/algorithm. But man! Design and algorithms! That's where the real soul is!
> I always had an inkling this was the case, but man it's been depressing to see it laid so bare. So many proudly screaming "I hated programming!".
For personal stuff? Sure.
But I certainly get why people get burned out on corporate programming. It's either tedious busywork following orders designed by architects whose last time writing code was 30 years ago and they never learned anything ever since, waterfall with glaring issues that the lowest rungs are supposed to magically make go away because upper management doesn't want to reset like they're supposed to, or it's "agile" in its various abominations. There's barely any time, budget or possibility left for actually experimenting a bit or for actually crafting out stuff that works. It's all output, output, output, and being micromanaged by Jira or whatever only adds to the dissatisfaction.
Personally, I left the field for good - I'm heading towards electrical engineering. Good luck coding a robot pulling physical wires.
Idk, I'd like to see AI design a schematic and lay out a board. Even the occasional "Show HN" that combines AI+PCB stuff is about analysis and checks. It doesn't seem like anybody is even near any kind of ECAD using AI. People still complain about autorouters. Even frontier models need architecting and guard rails in software to avoid spaghetti, it seems like an even harder problem to get them to choose the correct parts, create accurate footprints and symbols, and wire those all up together.
"This is wrong, fix it" + recompile, can happen twenty times in ten minutes, but "we discovered the layout is wrong, fix it" is precluded by the cost and time of a new board spin.
AI + text (code) seems like a good match but (E)CAD seems a lot harder to interface AI with. If I'm wrong, I'd like to share that with the EEs on my team, though.
PCB routing is still a murderously-hard NP problem, AI or no AI. Not least because a fully-automated schematic-to-PCB flow has to be driven by component placement, which in turn is driven (or at least influenced heavily) by requirements further up the chain.
I'm sure it'll happen -- if you can defeat the world Go champion you can certainly route traces -- but so far it seems to be an exception to the bitter lesson, where proprietary hand-tuned algorithms are still on top. Given the lack of large quantities of PCB CAD files that can be appropriated for training, it might be one of those things that has to be self-learned by the AI, again reminiscent of how Alpha Zero worked.
> how many people in software seemingly loathe their own profession
There will always be people who work to pay the bills, not to answer some inner call. I am happy - don't tell my boss, but I would do my work for free, including meeting users and extracting requirements (some colleagues say I'd be a master interrogator in another universe).
I think it could just be that they like different things about the profession? Personally, I got into it because of a love of algorithms and computer science. To me, actually writing code is just the drudgery I have to do to implement my work.
I could say the same, ee graduate who majored in telecom/RF but there was no work in it (or rather nobody wanted to hire a graduate). I did get hired into power electronics, but the work they needed was in software. Since then it has been redundancies every few years, through automotive application development, some audio visual, and even dev-ops.
The AI trend and yet another redundancy foreced me to reckon with what I hate about software, which is a tech ethos of "move fast and break things" that runs contrary to "measure twice, cut once". AI also transforms my strengths into executive functioning tasks, which are a mental bottleneck.
> "FPGAs reconfigured during program execution to speed up hot paths"
The IEEE conference on Field-Programmable Custom Computing Machines (https://www.fccm.org/) is in its 34th year, to give you an idea of how old that idea is. The answer to your question is both 1 and 2 and also 3. that FPGAs have rather poor efficiency, both in terms of cost and performance, so it's not worthwhile outside of a few niches.
Developer testing is checking whether the code does what the developer themself thinks it should. QA testing is checking whether the code does what the customers / users / rest of the world thinks it should.
The problem with that quote is that all of us reading this are telescope operators, not astronomers. The quantity and quality of our telescope photos is what we are paid for so we have no choice but to know our chosen brand of telescope inside and out.
reply