For those that didn't read the thread - this is for the Svelte compiler, not the Svelte library. Users of Svelte will be unaffected and typedefs will still be available.
Google employs 200,000 people. Suicide rate in the US is ~13 per 100,000 per year. This means there is an expected base rate of Google employees committing suicide per year regardless of working conditions that is likely higher than just 2. Maybe there is a real issue but two suicides within such large number of employees isn’t statistically significant.
EDIT: I added "statistically" in the last sentence to clarify my intended meaning.
> Google employs 200,000 people. Suicide rate in the US is ~13 per 100,000 per year. This means there is an expected base rate of Google employees committing suicide per year regardless of working conditions that is likely higher than just 2. Maybe there is a real issue but two suicides within such large number of employees isn’t really significant.
You're assuming randomness among the US population. Might be a good assumption.
However, there are externalities to this suicide that may affect others who work at Google or in NY, and so the story is worthy of being contextualized. It might be clickbait to put the word "Google" in the title but not because of probabilistic irrelevance. People who kill themselves at work have an impact on coworkers and company, no two ways about it.
Suicide is tragic regardless of the circumstances, and it's a really bad take to try to minimize this because it's not statistically "significant" or "clickbait".
There's nothing in the article (if you read it) that tries to paint that narrative. As far as NYP goes, it's actually pretty mild and factual. I don't understand why so many commenters here are jumping at the chance to defend poor little Google from the evils of bad journalism.
Also how is
> Maybe there is a real issue but two suicides within such large number of employees isn’t really significant.
It's /mildly/ crafting the narrative in the very title... "second worker," which is implying "this is a pattern." Even the first word of the title is "Google."
As for the minimizing, remember that on HN we aim to take the best possible interpretation of our fellow members' comments. I'll assume that the person who wrote "isn't really significant" isn't a heartless monster, and therefore what they meant what that "this didn't merit a Google-focused NYPost article."
I agree that suicide is tragic and we shouldn't minimize any instance of someone taking their own life.
I was trying to say that linking it to Google and implying it is a trend based on just two suicides given their extremely large employee count isn't statistically sound without additional supporting data. I was speaking about the link to Google rather than the suicides themselves.
If you want to have a meaningful comparison, then compare Google’s suicide rates with those of people in their thirties, gainfully employed / making six figures and have free access to mental health resources.
If you're seriously considering suicide, why would you bother going in to work, and then commit suicide in your place of work (your company's HQ, no less), if not to make a statement of some sort?
A worker kills himself at work by jumping off a work building and you are here trying to tell me speculation about work being involved has zero standing? I don't buy it.
It has no more standing than speculating that the suicide was related to a failed relationship with a coworker. And even in that case, a failed relationship is not usually the cause of suicide, even if it's a precipitating factor. Causes generally tie back to systemic issues.
Of all the ways one can die, suicide stems from the most deeply complex and systemic factors in one's life. To sit here and speculate about the cause with no information is irresponsible and I'd argue at the heart of what's wrong with social media today. For some reason people feel the need to have answers, even poorly considered speculation. I'd argue that it's far better to be willing to accept that there are times that require us to just withhold speculation until there's enough information to do so responsibly.
Whatever the cause turns out to be, these early discussions are the last contact most people will have with the topic, meaning whatever speculations are shared are likely to be the primary memories of those involved.
This community is quick to demand evidence and citations on most subjects (and rightly so), and this should be no different.
If it happened on the job then, yeah, they probably would. Just like there is a Walgreens security guard in the news currently for killing a shoplifter in SF. If he had killed someone outside his capacity as a Walgreens security guard, they wouldn't describe him as such.
If this engineer had killed themselves in another manner besides jumping off the top of their workplace, they might not be described as a Google engineer.
Edit to add: Statistically, I suspect that there have to have been many instances of Google employees committing suicide outside of work. I doubt those got headlines at all, let alone headlines including Google's name.
Their living in NYC is a more obvious connection, as there are studies showing that urban populations have significantly higher rates of mental disorders.
To me the more interesting question is: did Neanderthals value art?
Could argue all day about what is and isn't art and if they created artifacts that fit the definition, but what I'd really like to know is "did they appreciate things purely for aesthetics and cultural relevance, and not utility?"
There was an episode of In Our Time about cave art that features a discussion about the art not being solely for utility. Unfortunately I cannot find a transcript and I can't remember when the discussion came up. Still, if you are interested you might want to listen or look at some of the further reading links.
https://www.bbc.co.uk/programmes/m000mqn7
> "did they appreciate things purely for aesthetics and cultural relevance, and not utility?"
Many animals do, even sharing their sense of aesthetics with human taste. Just look at how flowers evolved to some form even we find pleasing without any skin in the game, or how animals that live in total dark (deep sea, for example) are atrociously ugly.
I think "create art" and "value art" are essentially equivalent in the context of the question we are pondering. You cannot argue they made art if there was none to appreciate it as art; art doesn't exist without an observer.
Memoizing the callback prop only matters if you wrap the child component in "React.memo".
If you don't wrap the child component with "React.memo", every time the parent renders the child will render regardless of prop equality, even with memoized props/callbacks.
> Several thousand borrowers with older loans will also receive forgiveness through income-driven repayment (IDR) forgiveness, plus another 3.6 million borrowers will receive at least three years of additional credit toward IDR forgiveness, the Education Department said in a statement.
I think this is the actual news. Although it doesn't state what the selection process is.
Drawing on the Right Side of the Brain is the holy grail. I don't think you'll find a much better single "diy" resource. I don't think you need to follow it cover to cover, but it's a great reference resource to have and contains a lot of super valuable exercises and resources for drawing "the right way".
Honestly, I wouldn't spend money on instruction unless it's in person - drawing is ultimately about seeing and it's hard to instruct that online. Other tutorials/lessons tend to be about copying existing work rather than drawing from life, which is the foundation of all drawing/art skills.
Learn about the basic elements of art (line, shape, color, value, form, texture, and space) and the principles of design (balance, contrast, emphasis, movement, pattern, rhythm, unity) and look up exercises to practice them all.
Most people only care about "line" when drawing (forced perspective, outlining the subjects, etc). This is a trap. Think about "drawing through the object" (don't outline and then fill in later, etc) and utilizing all the other elements of art.
Draw still life setups/landscapes/people from real life. A lot. Do long drawing sessions (4+ hours with the same subject). Short time boxed ones (15 mins max, 30 mins max, etc). Draw the same setup every day for a week. Draw every day.
If you want to copy other works, start with copying drawings/sketches from the "masters".
If possible, find a group drawing class to get IRL feedback.
Once you do this for a year or two you should have a pretty good foundation for pretty much any drawing/painting discipline.
Ultimately it's about repeated practice. Make it a daily habit and you'll see big improvements.
Source: art school, drawing/painting for 15 years.
Same thing happened to me at my last company. I was over worked, wore too many hats, and was paid significantly less than my team mates who were more junior than I was (and had less responsibility). I had a handful of conversations that never amounted to anything. As soon as I put in my notice with a new offer in hand suddenly I was able to "set my price".
I left for other reasons as well, but it really shone a light on how management thought of ICs. Managers: proactively reward your ICs, don't wait until they're halfway out the door. I would honestly take a less aggressive adjustment in comp if it was done proactively, rather than waiting until I'm fed up and on my way out.
Too many roles / too many hats is far too common and why I find it hard to stay anywhere more than 4-5 years.
As a senior IC in a super-flat & growing org..
I'm almost like a customer successs engineer, product manager, scrum master, senior developer and tech lead all rolled into one.
Management administrivia
I accumulate administrative things my manager doesn't want to do & pushes down
I do unofficially own a part of the team
Dotted lines of devs in my "team" that can be rolled in & out sprint by sprint
Customer success / product / architecture
I collect customer requirements, translate them into stories & documentation
I manage customer/manager expectations with status meetings & reports
I project plan out 3 months of work with JIRA hierarchies/Gantt chart
I design solutions given the requirements
Scrum
I run our standups, sprint plannings, backlog refinements
Corporate citizenship
I am involved in recruiting 5-10% of my week
I run working groups / long running cross team tech org
Development
I do IC work - directly assigned sprint deliverable tickets (analysis, development, infra creation) I need to accomplish
I've been looking at moving to a more official management role elsewhere so I can focus at being good at a few things instead of decent at all the things.
> I'm almost like a customer successs engineer, product manager, scrum master, senior developer and tech lead all rolled into one.
This is also me. Except I really like it. But I'm not sure what to do about it, it can reflect super poorly on a resume for some reason.
"Oh, your applying to be a Senior Engineer? Look at all this product management and developer manager experience on your resume, you must not really be serious about coding, you aren't strong enough technically, the developers won't trust you"
"Oh, your applying to be a Product Manager / Product Director. Look at all this programming and tech experience on your resume, you are really just a developer, you should just be pulling tickets from JIRA/Asana/Linear, you probably wouldn't be able to speak in non-technical terms in front of customers/clients/etc"
(loop on repeat)
I've not heard of a job name/title/role that accurately represents this sort of work, even though companies generally seem to like it, if I can somehow get through their application process.
I believe there was a post on here recently that talked about a person leaving _off_ experience he had on his resume and end up getting _more_ callbacks.
I'm in a similar place, although I'm not really seeing any resume problems. Maybe my resume focuses entirely on my technical side. But on my previous project, I often spoke with stakeholders, helped our ever changing product owners, but I also worked on every aspect on the application (even infra, though that's really not my thing), guided juniors, decided the direction of the application, etc.
But that was only one project, so it doesn't really show up much in my CV. The main problem that recruiters have with me is that they don't know if I'm front-end or back-end, but I consider that a pointless distinction. I pick up whatever needs to be picked up, whether it's a single technical focus or everything else. (I'll even do infra if I really have to, though I'd rather not.) I like the diversity, but I also like to adapt to what the team needs.
I have similarly varied background and I have not had candidate employers put it through that lens.
If anything I find people tend to look upon varied experience as proof that you can add value on multiple fronts and across functions within the organisation, which should make you a slightly less common cog in the machine.
> I've not heard of a job name/title/role that accurately represents this sort of work, even though companies generally seem to like it, if I can somehow get through their application process.
I think you will find that generalists are valued in extremely small orgs like startups, skunk works, spin-offs, and the like. Titles, when accurate, are likely to be vague (eg. Founding Employee). As organizations grow, roles tend to specialize, and generalists are undervalued, but reliable long term career success still tends to accrue to folks that have t-shaped[0] skill sets that allow them to be extremely productive in their area of specialization, and extremely effective at collaborating with other specialists across the organization.
You seem to be getting dismissed as a dilettante, though it is being couched in terms of your expertise in whatever the person you're talking to doesn't feel qualified to assess, or whatever they aren't looking for in the role they are seeking to fill.
There is, however, more than one way to specialize over the course of a career other than your role in an organization per-se. For example, you can develop domain expertise in an industry (finance, healthcare, legal, telecom, entertainment, retail, agriculture), market (eg. regional VARs, enterprise software, small businesses), delivery model (SaaS, information products, durable goods), or product/service category (content management systems, adtech, databases, business intelligence). Don't go crazy with combining these into something too hyper-specific, obviously.
The other aspect is organizational appetite for risk.
The first company I worked for let anyone grow into any role they proved they could do. If you solved the hard problems you were the senior developer, if you took the reigns you were quickly promoted to lead/manager. Seniority didn't count for anything and roles were very fluid.
That's an uncommon situation and what I've learned is it's hard to imagine if you've spent a career in more traditional organizations.
Did you consider skipping the non-relevant parts from the resume and interview discussion? Once you make it in, perhaps you can show them your full background.
TBH, reading this as a manager, I have to admit I feel like asking my engineers to take on SOME of these beyond-just-the-code duties... is a good thing? Obviously there are a bunch of caveats, and nuances to whether you want an IC engineer to be 100% coding and 0% talking to customers or doing admin (this seems bad), or is it 90% vs 10% (maybe okay), or 80/20 (sweet spot?), 50/50 (concerning), 20/80 (bad again), etc.
That being said, if you are doing all of these things, and not being fairly compensated for it, then that's definitely a problem. A $50k/year web dev position at some random agency, doesn't deserve this level of work from you, esp. if you could instead take all these responsibilities, and do them at a serious technology company or start-up, for 2x-5x the comp.
> TBH, reading this as a manager, I have to admit I feel like asking my engineers to take on SOME of these beyond-just-the-code duties... is a good thing? Obviously there are a bunch of caveats, and nuances to whether you want an IC engineer to be 100% coding and 0% talking to customers or doing admin (this seems bad), or is it 90% vs 10% (maybe okay), or 80/20 (sweet spot?), 50/50 (concerning), 20/80 (bad again), etc.
1. Agree 100% coding and nothing else is bad most of the time. You can leave out admin tasks but engineering is more than just coding, it's problem solving. Understanding requirements (e.g. by talking to customers) is crucial and also the best code is the code that had to be never written.
2. Think that is also in large part an individual thing, some people like to wear multiple hats to some individually varying degree while others don't.
3. It must work out in practice and you have to make sure the sum of both does not result in a value above 100%
4. I agree if the technical stuff is as low as 20% it may be better to just transfer in another role completely as it is hard to contribute meaningfully there then.
I agree most engineers should be doing SOME things beyond code-centric activities. There are things that almost nobody, whether they're an IC or people manager, wants to have take up their whole day. That requires spreading them out across staff.
Problems arise when that work isn't assigned out explicitly, evenly, and thoughtfully. Sometimes there's important work that isn't really assigned to anybody, and it can end up landing with whoever is least willing to ignore it. Over time, that can lead to situations that feel (and/or are) unfair.
Some engineers just want to do engineering. Nothing else. But more often engineers will be happy getting involved with the customers in some way, or working to improve some process they don't like, or some even love doing documentation.
Best thing is to bring up options and ask if any of them sound appealing. Letting people choose their work generally gets you stronger buy-in to what they're doing.
Same. As an IC I like ownership. I'd be fine with most of that list assuming it was related to something I owned. I may not specifically like some task, but I'm fine doing it if it's because I'm the person responsible for something.
The biggest issue I would have with that list is the description of the scrum setup, and being directly assigned tickets. I find it more engaging if I'm given or find bigger problems to solve, completing individual tickets isn't as interesting.
It's more that I spend near-zero time on any coding anymore, but also have very little visibility into the wider strategy (because there kind of isn't one).
So I am tasked to have work for my customer(s) / 2-3 devs on loan to me, planned out for a few months. However my manager doesn't really give us what his quarterly goals are most quarters. Product team doesn't publish them very often either.
In order of time spent in applications top to bottom it looks something like - Zoom, Slack, Email, Jira, Confluence, Sharepoint, Gitlab, VSCode.
Right, I'm rather experienced and make many multiples of 50k/yr, so its not really a compensation thing.
It's more that it feels very ephemeral / tenuous as none of it is in an org chart or official. It is basically what problems management has to solve and what seniors are available at the moment.
I am, officially in title and org chart an IC. In reality 10-20% of my time is IC dev work. 6 months ago it was 50%, 6 months before that it was 0%.
Further it feels like too much of a time split to really get any better at any of the aspects - software dev, tech lead, product, people management of this role.
It can be better, but it also can be just as chaotic sometimes. On balance overall, FAANGs are probably better at managing this "IC utilization" rate if you wanna call it that, vs just randomly expecting you to pick up and wear all the hats all the time or that hats are chaotically assigned, with no plan behind it. Certainly FAANGs aren't perfect, but at least it's easier to find "reference implementations" because there certainly are some very high-performing and well-managed teams, and if you're not on one yourself, then you can at least have the benefit of being able to see-and-compare, which then provides a potential for betterment and learning from others (which might be harder in non-FAANGs).
Right, I like the term "IC Utilization Rate".
I think for me its the chaos of the hat wearing. I went about 6 months doing pure project management with 0 leadership or development work.
I periodically go long enough with 0 hands-on dev that stuff in the SDLC has changed again. So I have to go poke around and figure out why my commit message formatting is rejected, which teamcity instance we are using now, and what QA box I should be testing on.
Also the unmentioned part for me is that while 10-20% of my time is Dev at best, 50% of it is high urgency fires I am brought in to extinguish because I have the most knowledge of that part of the code base and can ship whatever improvement in 1-2 sprints without needing to spend 2 sprints on analysis first.
I'm just a senior IC, and not at FAANG. But my employer does recruit from FAANG. 0%-20% sounds low for dev work, but the basic description looks somewhat familiar. We don't have project managers, and not all teams have product managers, so seniority can get you more of that work, and less dev work. I don't think ICs do managerial people management if you don't include mentoring. And I do know one or two directors who still code a lot. Maybe some FAANGS have senior positions with more IC dev work.
They do, but it's vastly easier to get promoted to those levels as a manager, because the organization needs managers to function, but super senior ICs are less critical.
For me it mostly depends on management staffing levels, if I'm in a standup with more management/business folks than developers I don't expect to spend a lot of time handling that side of the process, especially if we aren't in a place where we are stable from a technical perspective or have deadlines looming. On the other hand if I'm just directly reporting to a single person I'm much more open to lending a hand and pick up a lot of stuff.
My last title before I went on my own was CTO/Architect. And I was doing all the things you mentioned down to coding. I could not complain about compensation as it was very fair - $250K in 2000 (the last year). But I was becoming a wreck.
Now I have my own company and I still do all those things, LOL. Big difference being I choose what I do, how I do and obviously the size so I can chew it on my own or with my few trusty subcontractors. It is basically development of new products from scratch either for clients or for my own company and once in a while some very short hit and run type jobs. I now also leave plenty of time for myself to enjoy whatever activities make me tick.
Not even. This is far past what is expected of a staff, senior staff, or even principal engineer. This is a full-on technical cofounder, or hybrid cto/vpoe.
> and was paid significantly less than my team mates who were more junior than I was
This is the kind of thing that any company doing this should be named, shamed and blocklisted.
There is no reason other than greed that a higher ranking employee shouldn't make at least as much as a lower ranking employee in total compensation. "Person was hired earlier and is okay with the lower wage" is, frankly, a reflection of a company hating their employees. It's a shame and an embarrassment.
I don't know. At every company I've worked for (as a junior, and as a senior) there were some juniors who clearly contributed more to the company's success than some seniors. I don't think this is an uncommon experience.
To me the "rank" of senior engineer should indicate the engineer's experience, and maybe their "wisdom" and depth of knowledge, not their salary. A senior engineer may slack off a bit and be less productive than an eager junior, or want to take on less responsibility; it seems fine in that case that the junior is rewarded with higher pay.
Know your value to the company, and negotiate compensation to match it (or exceed it!). I'd also suggest companies not tie pay to title.
Disclaimer: I'm not trying to say anything about or against your parent here.
This can be a very subjective thing. How do you 'rank'? This is not something that is completely clearcut, cut and dry and you are 100% accurate without fail.
Example: I have a guy on my team that is 'more junior' than some others. He's killing it though. He's consistently behaving like he's got 10 more years of experience than he does and people that had 20 more years of experience than him couldn't do 10% of what he does without fail.
Of course you could say that the Senior developer should never have been hired if he was actually a Junior developer that's just been around for some time already but hiring practices aren't perfect, people get hired on one team and move to another and you're the first to actually do something about it etc.
Ranking can be hard for sure, but once that ranking existsz paying the lower ranked person more is indeed unethical. If the lower ranked person deserves more money, give them the promotion and title.
You are missing a few other questions and are assuming this can only go one way.
Are you going to promote him? If so, why? Are you going to give him a meager raise? If so why? Are you going to give him a proper raise? ...
FWIW, the "Senior" is no longer in play. I do not tolerate such incompetence for long. And yes I am doing everything I can to get the 'junior' a proper raise and a large bonus.
I swear at some of these companies it is going to take engineering managers going on strike before corporate actually respects that we know how to run effective teams for the good of the business.
You get what you measure, and the only thing they know how to measure is negative outcomes.
You can't prove that giving me an extra 5k made me stay long enough to pay it back at >= our revenue targets.
The semi-healthy version I see play out is when people who want to be better use the loss of a customer or a coworker as fodder for pushing their agenda. Essentially it's one class of teachable moment. People learn from pain when nothing else works, and you can amplify or dull that sense of pain.
proactively reward your ICs, don't wait until they're halfway out the door.
[Insert frustrated comment here about how capable, sufficient and well-performing ICs are absolutely rewarded.....with more work and additional duties]
Yawn. Another "hot take" article that's really just pandering to the HN/"true hacker" crowd that romanticizes anything pre-Google. It's a pretty shallow article that just regurgitates the same old "money makes things evil" rhetoric and slams the big Z cause it's low hanging fruit.
I'd be much more interested in something that highlights or talks about what _is_ better about web 2.0 than meme-ing about "old web good, new web bad". This is just click bait dressed up as anti-establishment / edge-lord blog spam.
Admittedly I haven't followed Svelte super closely, but isn't "no JSX/TSX" kind of a major ideological point? From reading the intro docs, it seems like separation of js/css/html is a selling point. JSX/TSX would contradict that, no?
Just wondering if my read is correct or if there's some other reason it's been left off the table.
Nobody truly separates JS from HTML. You either have to put something HTMLish in the JS, or something JSish in the HTML (HTML itself supports this of course).
IMO the HTML-in-JS solutions (i.e. JSX) are superior to the JS-in-HTML solutions (e.g. Angular/Vue Templates) because they put the standardised turing-complete language in the driving seat rather than the propriety, hard to extend template language.
Still, it's way easier to integrate a js library in a svelte component than in a react component. So maybe the two approaches have different tradeoffs and respective advantages
Also curious - I'm spinning up a small side project with Rust and Svelte. Was looking in Tauri as a replacement for Electron but wondering what other approaches people have worked with (assuming this is a cross platform desktop app, that is).
I'm using quickjs (rquickjs specifically) to bind GTK's C API to Javascript and adding a light DOM wrapper (get/setAttribute, add/removeEventListener, etc) that covers all the functionality Svelte needs. I've had to make a few modifications to the compiler (<10 lines total) to get binding and CSS working but so far it's been great.
Working in GTK with hot reload and instantaneous esbuild rebuilds is.... insane.
Tauri seems like a nice option. It's not as full-featured as Electron yet but their focus on security is great to see (last I saw they were getting the codebase professionally audited). The main reason I didn't go with it was just that doesn't seem to (yet?) suit my use case with zero-copy data transfer between Rust <-> Browser.
My hope is that by writing most of my backend in Rust, that it'd be easy-ish to switch to Tauri or other options if something changes down the road.
