2. Most devs I know at least consider writing simple web apps/interfaces as the most boring work you could possibly do.
^1 (I've seen 1000+ employee companies with workflows that include multiple people simply sorting and searching through data in hundreds or thousands of files manually, something that any PHP or Javascript script would be able to do in seconds. One time they simply didn't have an interface between two apps and there was someone who's entire job was essentially to type the data from one app into the other. A motivated high schooler would have been able to write something that would have saved 4000-6000 hours of work per year. These kinds of insanely low effort automation opportunities simply don't tend to exist in embedded areas, and it will probably take at least 10 years before most of them are gone from small to medium sized businesses.)
This isn't quite as prevalent in hardware applications where even well funded startups have to be concerned about actually achieving positive margins and cannot just hope for growth to eventually outpace whatever cost structure they have burdened themselves with.
I’m not sure this is a problem though. Many large companies are not hiring in the valley because the high level of compensation is making it uneconomical.
Sometimes I feel SF is all SW and HW has moved to Shenzhen.
I left embedded dev because I saw this coming and I'm just a slow developer that wouldn't have cut it with the demands of mobile software emphasizing cranking out stuff faster when that's just not how I work.
I get the impression embedded is still a somewhat slow market. Or has that slowness meant it's dried up really badly?
Embedded has been consolidated into a bunch of huge multinationals like Texas Instruments, Qualcomm, etc. and they're doing alright financially. It's just a very innovation-lacking industry compared to software, so you have a chicken-egg problem with investors. It'd be like trying to start a CPU company now when we've got Intel, AMD, IBM, and maybe one or two more boutique makers teetering on the edge of bankruptcy constantly.
[0] https://www.reddit.com/r/boeing/comments/c6tknw/boeings_737_...
demand / supply
You might find 1000 devs with react but if the need is 10000 while there is 50 for 40 VxWorks devs then it explains the salary.
If you downvote pls. explain how supply and demand is not a thing for tech salaries.
But it's not really enough to explain it because the engineers who do Vx could always just switch to a better paying platform.
I wonder if the low salary indicates that the Vx Devs at that low price aren't able to switch out. Either due to location, lack of ability, or some other capture.
Not trying to do that. But (unlike C++), you have to understand async to use JavaScript sensibly. If for whatever reason you haven't come across it another language, then you might struggle (esp. if you're coming from C or C++ where the skills required are very different).
See: https://news.ycombinator.com/item?id=8984648
More importantly, frontend is extremely demanding in terms of UI. While for e.g. QT, WxWidgets, native GUI toolkits, it is perfectly acceptable for things to look the same. On the modern web, every significant app is expected to have a "design language" and not look like each other. On the other hand, HTML by default isn't very stateful, sure it has some stateful components like checkboxes but in general you have to store the state in code. And every code base needs a custom UI. You end up with a state space explosion. That is also why frontend frameworks these days are trying to force things into finite state machines i.e. Redux, Elm architecture. Whatever term you prefer. Half of your UI codebase often have absolutely nothing to do with business logic and instead animations and user experience code to make things feel "slick". A ASP.NET WebForms just ain't going to cut it if you wanna build a SaaS. Sad because tons of money have been wasted on essentially marginal improvements on user experience, but good if you are the consumer of course.
HN is starting to look like Reddit where people bury your comment if it conflicts with their views.
I feel downvote on HN should affect your own karma with, say, -100.
(I also have started seeing significant misuse of flagging on HN)
On the opposite side a private company that makes billions $$$ with its website should be more prone to pay its devs better.
The React developer will have to retrain and rebrand themselves as Bojombo developers in 2 weeks and as Klazoum Framework ninjas in 2 years.
I find that almost every new embedded project comes with yet another vendor architecture, vendor-specific toolchain, documentation that's wrong, totally different peripherals and drivers, weird limitations, undocumented pipeline glitches, and so on. Even the CPU architectures and instruction sets are often different, if it's a DSP, or an SoC with DSP coprocessors glued on.
Basically, new things have to be learned often in that domain, at least with the jobs that come my way. For a while I got a bit anxious on new projects because I couldn't understand how to make seemingly broken tools do things the client wanted. Things like getting signal data into a DSP simulator when all the (GUI only!) buttons didn't do anything at all for example; but eventually I learned that it takes about 2 weeks on every new project of restraining the urge to swear, and than all the undocumented stuff, tools working differently than documentation says, secret header files and options, libraries that no client of the vendor has ever used and are full of empty function bodies or just broken, but sold to my client as if they are actually in mainstream use, weird memory models etc. starts to make sense and I'll be productive. So I just expect that on any new architecture project now, and it works out ok. Just budget 2 weeks of swearing-restraint at the beginning.
On front end webdev, there is infamously a huge amount of churn too. E.g. every time a new Webpack comes out I have to spend quite a while figuring out how to rewrite the config files for the new version for best results. WASM differs from asm.js; grid and flexbox are a new way to achieve what we used to do with floats, and there's an interesting new browser API each week.
But React hasn't change much in half a decade, and continues to be one of the main front-end frameworks. You could have learned React 4 years ago, and keep on using the same skills today and continue to be well paid if you're good at it. That pay is, indeed, at least 50% more than the pay offerred for low-level embedded, even though React work is way, way easier.
But remember, you can negotiate... Just taking a software dev position as an individual is not the route to the best pay in embedded hw/sw projects. If you can instead sell product development, where the client wants something built for them, and you build it, complete with project management, architecture, technology selection, supply chain, and subcontracting or setting up a project-specific company, then the scarcity of relevant skills works in your favour and the pricing is quite different - better. Those projects are great if you can get them, and sometimes a lot of fun.
Embedded C/C++ development has been around much longer and is far more conservative in terms of adopting new technology. So they have a much larger labor pool of experienced developers who are going to be familiar with the core technologies of the job. Web shops migrated quickly to technologies like Angular and React, whereas the vast majority of C++ shops likely won't be adopting C++17 any time soon unless it's a smaller team's greenfield endeavor. I'd also argue there's less training necessary to go from, say, C++03 to C++17 than going from ES5 jQuery to ES6+ (or Typescript) React.
Gaming has similar-ish needs but is famously oversupplied.
Quant finance pays really well, though.
Given the... mixed... reaction to large defense projects, it's possible that the defense contractors are not focusing on engineering per se.