HackerTrans
TopNewTrendsCommentsPastAskShowJobs

nurspouse

no profile record

comments

nurspouse
·il y a 2 mois·discuss
As an aside, in Islam, people have to pay a 2.5% wealth tax annually for charity.[1]

This does make retiring a tad bit complicated. Say you've saved $3M and are ready to retire. That means each year you're spending $75K just to satisfy this tax.

[1] Depending on how your wealth is structured. Cash is 2.5%, but if you own, say, a business, you pay the tax on the value of the goods, not on the value of the building, hardware, etc. You don't pay Zakat on the house you live on. Agriculture is actually taxed at 10%, etc.
nurspouse
·il y a 3 ans·discuss
For context:

As a percentage of the population, Hamas's attack on Oct 7th killed 6 times as many people as Al Qaeda did on September 11. If you are an Israeli, you are 6 times more likely to know someone impacted by those attacks than Americans did in 2001. As a result of the 2001 attack, the US invaded two countries, resulting in million(s)[1] dead on the other side.

Make no mistake: For any country that has the means, losing 900 people in one day will always be seen as an act of war, and they will respond. While the Israeli response is certainly "disproportionate", it is not by any means an outlier when you compare with typical conflicts around the world.

I definitely think Israel's response should be condemned, but I will openly say: Our government(s) in the US routinely do worse. Let there be perspective.

[1] Depends on which study you look at.
nurspouse
·il y a 3 ans·discuss
I've been using xonsh professionally since around 2018 - in both Windows and Linux. Love it. Getting it to run existing bash scripts was a pain earlier on, but has gotten much better.

The one thing I don't do is make it my official shell in Linux. I keep bash/zsh as my shell, but the first thing I do in any shell is launch xonsh. Occasionally it does crash and it's nice to end up in a "backup" shell in case I need to recover anything.
nurspouse
·il y a 3 ans·discuss
Psst... xonsh!

Relatively terse, and quite readable scripts (they are mostly Python!)
nurspouse
·il y a 3 ans·discuss
PTD is almost entirely PhDs.
nurspouse
·il y a 3 ans·discuss
If he was a test automation engineer, he likely had transferable skills. Many/most of the fab folks have almost no programming skills, and are PhDs in things like chemistry[1], etc.

Now some of them do take the initiative and learn SW skills, or data analysis properly, and switch due to that. But the majority of them feel stuck. They have a heavy workload and do not feel they have time to learn new skills.

[1] For a long time, and perhaps even now, the fabs only hired either technicians or PhDs. An exemption would be needed to hire someone with "just" an MS. Of course, almost none of these jobs actually need PhD level skills.
nurspouse
·il y a 3 ans·discuss
> Intel isn't a great place to work (despite their corporate value claiming it is), but by most accounts, Amazon is much worse unless you really like a place with cutthroat corporate politics.

I used to work at Intel. Some data points:

When the news about how bad Amazon's culture was (e.g. people crying at desk), my thoughts were "This sounds like Intel."

When you talk to Amazon employees, most say "Every team is different. We don't see such behavior in my team, and I don't work long hours (i.e. more than 40)." And the same can be said at Intel. If you're close to the fab, the behavior is crap. Software tends to be pretty chill. And you'll see everything in between. I recall once going in on Saturday and talking to a guy - he said he'd worked every weekend for the last 6 weeks and expects to continue doing so for a month or two more.

Everyone I know who has left Intel to join Amazon is happier at Amazon. Everyone. The most common refrains:

1. Good work/life balance at Amazon (although some had it good at Intel too).

2. Far fewer morons at Amazon. When you're in the non-core parts of Intel (e.g. software), the people around you are fairly poor in terms of talent (e.g. complaining about having to use Git, saying we're using it only because Microsoft owns Git (!), refusing to use branches in Git and insisting on just creating command line arguments for every experiment you want to try).

Intel, though, does have better PTO.
nurspouse
·il y a 3 ans·discuss
Former Intel employee here. This may be true for their design folks, but the largest portion of the company is related to the fab, and there aren't many jobs for those folks. Moreover, the alternatives (TSMC, Samsung, etc) suck as much as Intel.
nurspouse
·il y a 4 ans·discuss
Intel hired over 20,000 people this year alone (likely a record for them both in terms of absolute and relative percentage). The freeze is similar to that of other companies: Uncertainty over economic conditions.
nurspouse
·il y a 4 ans·discuss
While such people may exist at Intel, it's not at all the norm, and to be frank, doesn't improve your chances of getting a job there.

(Worked at Intel and along with fab/process folks for a bunch of years).
nurspouse
·il y a 4 ans·discuss
This falls more into the electronics domain, which I know is sometimes put under the "semiconductor" bucket, but in universities usually has its own domain ("microelectronics" in my day). It's a lot more focused on the circuit/high frequency model of the transistor, and builds up form it.

Semiconductor theory is more about the transistor and everything below it: Starting from quantum mechanics and statistical mechanics, derive the equations of electron/hole transport in a doped semiconductor, how the material's band structure impacts current flow, etc. The derivation of the transistor equations is often the end point.
nurspouse
·il y a 4 ans·discuss
The industry doesn't have a talent shortage, which explains the working conditions. There will always be grad students who think "Cool! I get to do research involving quantum mechanics!"

Trust me, I've tried to talk them out of it and never succeeded.
nurspouse
·il y a 4 ans·discuss
Semiconductor theory is more interesting, but don't even consider it unless you love math and can do standard integrals without having to look up tables.

Also, the mistake I made when I went to grad school: Semiconductors seemed to be a "new" field compared to the rest of EE. One of my undergrad professors said "They still haven't figured out what a standard textbook should contain."

In reality, from a research standpoint, it's a very mature field. Don't expect low hanging fruit. If you're going to focus on theory, expect it'll take a number of years of dedicated study before you get to the frontier. You'll need to know quantum mechanics and statistical mechanics, and some electromagnetics, just to begin studying semiconductor theory. Then a whole bunch of specialized solid state courses. Then you start studying the specific subtopics (reading key journal papers).

> But later I'd want to work as compiler engineer

Why are you wasting time with semiconductors...?
nurspouse
·il y a 4 ans·discuss
I worked at Intel, and with process/fab people for a number of years.

Everything you're seeing in the comments is true.

Compensation is not that bad. Clearly, it'll not pay SW salaries - no engineering does. But if you're a fab person, you'll work long hours, be on call often (and you will get woken up often), and eventually will own a tool that you'll be responsible for, even when not on call.

Lots of abusive and pathological behavior, as well. And they often block internal transfers so you're basically trapped.

People with other skills (e.g. SW) get out. The rest are stuck, because they have, for example, a chemistry PhD and no other company will pay more.

See this thread from a while ago:

https://news.ycombinator.com/item?id=30027143
nurspouse
·il y a 4 ans·discuss
I assume that's because of pay. Working conditions for SW folks is fairly decent at most of the company, except possibly for firmware folks.

I suppose some people didn't like their status in a HW company.
nurspouse
·il y a 4 ans·discuss
> There is a preference for hiring people directly out of grad school and inducting them into the cult while they are still naive, so that's just what they come to expect for work-life balance.

Heh. I once interviewed for an internal SW position that dealt with fab automation. I openly told them in the interview that I knew about their work culture and that was of great concern to me.

Interviewer: I know what you mean, and I promise the org has been working to improve the conditions. It's not as bad as it was.

Me: Great! However, for me the comparison isn't the "old you" but the rest of Intel.

<Back and forth>

Interviewer: Look, you're not going to get a 40 hour/week job anywhere in the SW industry!

Me: Umm... All my SW engineer roles at Intel were 40 hour/week jobs. I haven't worked on weekends in years. <Proceed to list friends at big name SW companies who also don't work more than 40 hours/week>

Interviewer: OK. We normally interview people straight out of college who don't know any better.

Needless to say, I didn't take that job.
nurspouse
·il y a 4 ans·discuss
Good in terms of process engineers, poor compared to FAANG SW Engineers.
nurspouse
·il y a 4 ans·discuss
Having worked at Intel, I can tell you that the process side of Intel has similar work hours. This, in particular, rings true for Intel:

> Different positions may have different requirements, so work hours vary, according to the principal engineer. “An equipment engineer might start work at 8 o’clock in the morning and leave around 9 o’clock at night, but is it normal? This may happen two or three days a week. On a production line, the equipment must be maintained.

> “If you are a process engineer, it will be more stable. Maybe you can start work at 8:30 a.m.and leave before 7:30 p.m. If there are some urgent matters, you may have to stay later.”

At Intel, process engineers had to attend a daily meeting at 7:40am (mandatory), and would rarely leave before 6pm (meetings scheduled at 5 or 6pm were common). I sometimes would wander around in that part of the building at 7pm and a significant fraction of cubicles would be filled.

Almost all Intel process engineers have PhDs.
nurspouse
·il y a 5 ans·discuss
> The unwritten rule is that managers aren't incentivized to police this behavior.

Unless it is the manager who has to constantly do the reminding. Then there is swift policing :-)

Yes, this is actually normal "human" behavior. But this level of extreme was ridiculous, even within Intel. I quickly left the team once the project was over. Life is too short.

> Wise words. In cultures that do this, you have to adapt and work more on narrative/story-telling.

Narrative/story telling is good, but is orthogonal to the issue here. The usual flow is to use narrative/story telling to explain the why (motivation, etc). However, some senior management will expect you to also talk about the details. And this is where the advice came in: "Put the details, and make sure they don't understand them." My sin was that I was presenting the details in a manner where they could understand it (without losing the nuances and details - I was mere presenting the same material "well").

A more severe example will enlighten: I once solved a challenging problem with a really simple solution. My manager had multiple sessions with me to coach me on how to present that simple solution in a much more complex way. He emphasized that senior management should not realize that the solution was simple - no matter how impactful it was.

Yes - this is also a general "human" problem, and is common in lots of places. However, when you're striving to be the best company in X, it is wise not to settle for "average".
nurspouse
·il y a 5 ans·discuss
Spent years at Intel. Definitely saw what is described here. Must also add that it is a big company with no clear culture, so many people will have been in teams for years and not have encountered what skynetv2 is describing.

My two cents: Intel is full of people who are career oriented and not product oriented. Their main goal is to get a promotion, and often find means to do so without contributing anything meaningful to Intel's products. It's also full of senior leaders who believe strongly in credentialism[1], complexity[2], and style over substance (i.e. how the message is delivered vs the content).[3]

From a SW standpoint, I have not yet been in a team where all teammembers can handle branches.[4] This is quite acceptable.

In one team I was in, I was leading the efforts for a product that required features A and B by the customer. I was a junior member of the team with no domain knowledge, but I was somewhat of an expert for that customer's domain. Everyone was on board with the technical work. In every meeting we had for about a year, there would always be some person in the team who'd suggest things that would nullify feature B. I would have to remind them that we agreed to do features A and B." The response would always be "Oh, we're also doing feature B?"

The person who would say this varied from meeting to meeting. But I was very frustrated that they couldn't remember this basic fact, and often ended up writing code that had to be undone. And then deal with their frustration as if I had never mentioned feature B to them. I can understand if this happens once or twice, but I have to remind them in every meeting.

But this was normal behavior. I was the odd person who thought this was unacceptable.

Oh, and coming to meetings unprepared is the norm. No one will read your emails briefing them about the meeting ahead of time.

[1] "Let's hire the PhD with no experience and not the internal MS employee who's already doing the job they are hiring the PhD for"

[2] "I don't care if your code sped up our workflow by 5x. It's just what, 200 lines of code? Anyone can do that."

[3] Presentations break most rules of effective communications/presentations. A senior person once told me "You explained things too well, and your slides are fairly sparse. Fill it up with jargon and lots of plots, and don't explain it as well as you did. If senior management understands your work too easily, they will believe the work you did was trivial. If they have trouble understanding it, they'll be in awe."

[4] One former manager: "Every person will get his/her own private branch. Do all your experimental work there. There will be no more branches." A senior member in another team said "Why complicate things by adding new branches for our various experiments? Let's just keep it in the main branch and enable the different algorithms via command line flags."