331–340 of 349 posts
Earlier quoted context omitted.
If it weren’t for pesky things like supply and demand. If the pay is so low, it’s kind of curious that the supply doesn’t drop.
Prestige can confound this in the short or medium term.
Earlier quoted context omitted.
-> SWEs for being economically rational actors It's okay just to say that you like the money. You don't always have to use the largest words. It's also okay for someone to say that software engineers are paid lots of money. Perhaps too much. -> how about starting a semiconductor company where people are paid more? I'm assuming you're being facetious given the enormous logistical and financial costs of starting a some…
> It's okay just to say that you like the money. I'm not an SWE. > You don't always have to use the largest words. Some words have specific meanings, rather than just being longer synonyms for short words. > Perhaps too much. Again, no. This was my point — this is like saying that the solution to homelessness is to take away the homes of everyone with homes, so that everyone is now equally homeless. Don't pay the peo…
Earlier quoted context omitted.
I think a lot of people don’t want to work in software because of the perception or reality of the software development systems that they have been exposed to. If the right tools were invented for them, they might take to it like ducks to water.
And then what? Let’s consider the following. 1. There is a limit of complexity that a given person or a given team can deal with happily. Below the threshold work satisfaction is great: “I am solving more and more complicated tasks”, after the threshold a stress eats job satisfaction: “I do not want to open my emails in the morning - what if I will not be able to solve some new problem”. 2. Complexity of each success…
Maybe a person loves developing prototypes and POCs, or shepherding new systems through phases of adoption prior to reaching massive “scale.” As some people are wont to say, “Everything breaks at scale.”
Everybody has a complexity band in which they are comfortable operating. Many problems of high complexity can be decomposed sufficiently that they can be attacked teams of mostly mere mortals, with perhaps some assistance or over-sight from the Anointed Ones. Also, many people have significant abilities to navigate the complexities of, say, differential topology but C++ not so much. And vice versa. How information is presented impacts our ability to cope with complexity.
Earlier quoted context omitted.
The vast majority of people who are smart enough and have the work ethic to finish an EE degree are also smart enough to become a FANG engineer. EE is harder than computer science by far. So for the set of people who can be fab engineers, live in the USA and speak English, yes, the FANG engineer option is always there.
EE isn't necessarily harder than CS, it just really depends on the school. CS degrees are extremely variable while engineering degrees are much less so. I agree with the rest of your argument though.
I remember a professor sympathetically talking about how little clusters of people just split up the homework load together like it was a team project from random classes and then tell each other how to solve it to each other to save time.
CS was just another science degree in comparison.
Earlier quoted context omitted.
They will feel stark to the locals only. In Britain, people from both places will leave their shoes on indoors at home, praise the NHS, watch football and think the queen is fine.
> In Britain, people from both places will leave their shoes on indoors at home This is by no means a universal thing here!
And yes, even the queen is not universally accepted. Famously, the Labour party used to be republican, but seems to have mostly given up on that plank of policy.
In any case, my main point was that intense local rivalries exist, but actual differences between neighbouring places are typically fairly minor.
Earlier quoted context omitted.
I can't corroborate this at all. I come from a CS background. If you leave school and enter the workforce at SAS, you will be at a disadvantage insofar as you are looking for a workplace that you hope to learn something from or one that you hope reinforces good engineering practices. The semiconductor industry, from the vantage point of an experienced systems thinker, reinforces awful engineering practices. All the t…
To offer a different point of view, I'm a software engineer at ASML in the US. I can only offer the experience I've had on my specific team, and I've heard that this does vary between teams, but we do follow normal software industry practices. We have version control. We have automated regression testing, and unit tests for everything we write. We do Agile and use Jira (with all the same gripes that everyone else has…
Earlier quoted context omitted.
I can't corroborate this at all. I come from a CS background. If you leave school and enter the workforce at SAS, you will be at a disadvantage insofar as you are looking for a workplace that you hope to learn something from or one that you hope reinforces good engineering practices. The semiconductor industry, from the vantage point of an experienced systems thinker, reinforces awful engineering practices. All the t…
Dan Luu worked in semiconductors and spoke quite highly of his time there.
When I mentioned Dan Luu, I was specifically referring to the recent thunderstorm on Twitter where he mentioned the uncanny valleyness of doing work for unsexy companies and that it's actually more like a blemish on your résumé than a non-zero positive contribution.
Just out of high-school, I worked in a fiber-optic component assembly plant - wave-division multiplexers, optical circulators, etc. It was clean room, bunny suit, microscope work for the most part. But it was also moderate-skill, repetitive work - they'd hire large cohorts and provide all the necessary training. If you could keep up with the quotas and QC, you were in and made a decent wage and there was some room fo…
If the work is repetitive I'm not sure you can say it was good experience. Your time would have been better spent learning or creating, I assume. No reason to want your children to work.
Earlier quoted context omitted.
To offer a different point of view, I'm a software engineer at ASML in the US. I can only offer the experience I've had on my specific team, and I've heard that this does vary between teams, but we do follow normal software industry practices. We have version control. We have automated regression testing, and unit tests for everything we write. We do Agile and use Jira (with all the same gripes that everyone else has…
I'm talking about making chips, not being a software engineer that happens to work in the same building as people making chips (or the building where people work on making machines that make chips). SEs showing up and saying things were fine at their SE job doesn't move the needle on this topic. Purdue's semiconductor degree program for EEs is only incidentally relevant in that case.
But going back to your point, there are certain areas within semiconductor manufacturing that are software engineering jobs. They tend to be closely related to what's called physical design in the design part of making a chip. Or EDA coders. It's a cool area. But the bigger part of semiconductor manufacturing is working in a fab, which is atrocious grueling work, which is quite boring and dangerous.
I think young americans will work wherever the money is. I see people everyday (both american and non) that are in software because that's what pays right now. You just have to talk to the nearest product owner, project manager, or bootcamp grad for an example.
Software has structural economic advantages that are difficult to match in other professions (particularly ones that can scale up to support such a large number of practitioners).
I do know that with Descriptor languages and 'libraries' for chip design they reuse blocks and patterns, I think the challenge they run into however, is the possibility that there is cruft built on the existing setup for circuits and the like, and tweaking such may have impacts to downstream customers, possibly undiscovered until after tape-out.
^0 - Even if sometimes they get mis/overused on a low level. By that I'm referring to cases where someone learning patterns thinks they -have- to use all of them.
^1 - Examples that come to mind would be the 'Grab from queue, do thing, update queue', 'Manual' ETL, and 'Timed Jobs'. The last of which is the most fun to see across orgs, as it tends to have the most derivation between orgs. The most slapshoddingly-functional of which being a bunch of scheduled tasks in windows server (which honestly, worked great for them and their use case)