The "$300 mental health" seems odd - for any kind of counseling/therapy/etc sessions this is a drop in the bucket in terms of cost.
It will easily cost 10x to work with a mental health professional (and insurance companies sadly pay a very small amount of it). So why add this to an otherwise reasonable package?
I think this is a case of small help coming across as worse than no help, even though rationally that's not true. Like if I ask you to write a quick script that'll take a half hour... offering you $5 may be worse than just asking it as a favor.
I'm sure their heart is in the right place and offering mental health coverage is a good thing, it's just the number causes a double-take.
They are paying the COBRA. So this goes toward copays and hitting deductible. Assuming their health coverage is good (why wouldn't it be, it's a San Fran tech company?), this gets you pretty far.
It’s like one private pay visit at a really good clinic. They can then help guide you somewhere that’s covered by insurance. Mental health is full of quackery so best start at a top notch place
To clarify why it bothers me: It tries to tell a story of "we as a company care about you", but at least in my experience, health care plans cover less than $100 per session, and in the SF Bay Area you easily pay $200+ per session for mental health professionals (as they are often out of network).
Maybe Apollo's health care plan has much better out of network coverage than what I'm familiar with, in which case I stand corrected (and agreed that its good to help cover copays, if this is what this actually does).
Why was this downvoted? You raised an important issue. Does this mean the health plan has terrible mental health coverage? I guess so. (It would be great if someone who works for Apollo care share details about your mental health coverage.)
When I worked in the US, my health plans had pretty good mental health coverage. You could spend 1,000s of USD per year for psychotherapy / counseling with zero-to-minor co-pays. If you required medication (prescribed by a psychiatrist), that was also well-covered with zero-to-minor co-pays. I remember specifically that mental health care had "higher coverage" because therapists were rarely part of the insurance company's network. You paid the health professional directly, then require reimbursement from health plan. (Yes, I know this isn't true for all health plans.)
To hire an experienced mental health professional in SF Bay Area, I guess the rate is 100 to 200 USD/hour. Most will have sliding scales, but that will not apply to well-paid engineers.
At least for Kaiser Permanente in the SF Bay Area, which is one of the biggest healthcare providers, they are notoriously bad at covering and providing mental health services
It's worth noting that a lot of therapists (especially solo or small-practice therapists) don't take any insurance at all, which makes visits de facto out-of-network.
Folks on an HDHP or who don't get through their deductible most years would probably end up spending most, if not all, of this out of pocket. Even if they would get something back they have to do all the dealing with the insurer.. and that's assuming that they understand superbills and all the BS that insurance companies make you wade through...
In short, $300 just clears all of this out of the way. You go; you get reimbursed for the visit; you get to decide what to do next.
It’s an amount that likely covers the first visit. People that have struggled in the past will already know the benefits and the service. People newly disaffected will be reluctant to “just go” so the 300 bucks takes that off the table. If/when they go and decide it’s a value add to their circumstances then it will be prioritized and paid for.
Fair point, I read this more under the light of paying for an ongoing therapist relationship to deal with a challenging situation (which as noted in another comment, $300 as a one time payment doesn't do much if you have weekly sessions with an out of network provider).
I agree it might help someone make a decision to try out therapy and see whether its a good idea for them.
Severance as in a 'voluntary' payment by employers is a US thing that I don't understand. Do you mind explaining why it gets paid at all?
In the UK, it's common for employers to have contractual obligation to pay a notice period, and for longer term employees they are legally obliged to be firing them on capacity or redundancy grounds - so it is common to pay some severance in order to pay the employee to resign themself and sign some legal paperwork saying it's okay.
I don't get why employers pay extra money "just to be nice" where there isn't some legal reason to do it...?
Not only is not common but it's definitely not "extremely common." In the current wave of layoffs signaling the end of the "cheap money era" it does seem more common however. At least among the types of companies that are likely to make it onto the HN front page. I've worked for plenty of startups where we got nothing more than being paid up through the day we were laid off. And most of those withheld our last check until we returned all company property.
Severance is definitely not common in startups. They'll usually burn the cash right up until the very last investor says 'no more' and then call it quits. They might have one more pay period (or two) in the bank.
Employers are by dollar amount the biggest actual thieves by far in the US. Business owners ought to generally receive more scorn and critical evaluation than common property thieves who represent a thin fragment, if we really care about theft
Doubtless for some cohort of employers you are correct.
Unfortunately your statement is painted with a wide brush, covering everyone from Jeff at Amazon to the owner of a corner grocery store. Everything from profitable FAANGs, to VC funded startups with hypergrowth ambitions, to small, finally profitable, boot-strapped endeavours.
Clearly among that group there are some who have embraced late-stage capitalism, who are milking their custoners and employees at every turn.
However, I would suggest, that many more have spent a life-time working harder, with less income security, doing what it takes in good times and bad. Looking after employees, treating them, and customers, fairly.
If after all this time they become well compensated, perhaps even rich, calling them "theives" belies the effort, and sacrifice, to reach that place.
To respond briefly, [Jeff at] Amazon has been convicted of being one of the leading wage thieves, and small business owners like the corner grocery store are also frequently accused and caught for wage theft. It is a pretty wide brush that's needed to evaluate the majority category of theft in the US.
I haven't mentioned anything about the effort or value employers provide. I don't think hard work from owners is relevant to the amount they thieve. And I wonder why you don't mention anything about the hard work provided by the labor who are victims to the largest category of theft, who by definition do the majority of the work obligated in business to begin with.
Why don't you go start a business and become one of these rich employers you speak of? If taking such risks wasn't rewarded accordingly, then I don't think people would be nearly as eager to start a business.
I'm talking about a system at scale, not individual actors. You don't know what I'm doing as an individual and it's not relevant to a discussion of material reality as observed. If your solution to this problem at scale is for everyone to become a rich employer in order to avoid wage theft, I don't know what to tell you
Re: risk staked, I will add that for many business owners their greatest risk and fear is simply having to work for a wage themselves.
It’s definitely common in parts of the world where workers have organized to have severance required by law or through other organized means. When workers demand it one on one with their employers, they have no leverage and are at the mercy of “nice owners” (ones that value reputations effects created by worker-favorable market conditions)
This kind of package is very rare. It's uncommon to get any kind of severance without tenure and many companies have been laying off w/no severance what-so-ever in my area regardless of tenure. They pay through the current week, expect you to return all equipment, and f right off.
not an expert, but my understanding is it depends on how the severance is paid off.
If the company keeps you on payroll and pays you weekly, then you cannot collect unemployment. If the company gives you a lump sum then you may be able to.
If a condition of the severance is that you sign a document saying you are quitting instead of being fired, then you cannot collect unemployment.
My understanding comes from recent googling because of similar layoffs that happened at my company. I'd welcome more informed thoughts on the matter.
If a condition of the severance is that you sign a document saying you are quitting instead of being fired, then you cannot collect unemployment.
This is false. If a company makes you sign a statement that you are quitting instead of being fired as a condition of getting severance, they are committing unemployment insurance fraud and are subject to civil and criminal sanction in most states.
(The point of trying to make employees do this is to avoid claims against the company's unemployment insurance account in the state. How UI works differs from state to state, but in all instances claims against UI increases the company's ongoing UI expense.)
This is how people get caught for fraud in quite a few cases too. They create a one sided contract that outlines their fraud and then they distribute it to people who run straight to lawyers, as they should.
> If the company gives you a lump sum then you may be able to.
Yep, in the case of the lump sum you're not being paid after you're given the lump sum. I was laid off in 2014. Got 4 months in a lump sum when I went out the door. There were no problems applying for unemployment.
I had a layoff like that, they gave me the option of choosing. Lump sum or "stay on the payroll but have no access."
I went with the latter because it paid better.
For a while I was always stressed out about background checks, because it showed that I was working two jobs. (I got a job to replace it almost immediately, but continued to get paid by the old place.)
I would think not. The one time I was on UE (back in 2008), you had to report any income you received.
edit: apparently in some states you can - at least in Colorado in 2008, you could not. Generally your unemployment would be reduced by the amount of income you brought in. So, in any case, severance payments from a typical tech job would far exceed UE anyway...
Including laptops with likely the customary IT spyware as well as confidential company data? If I were in this situation, I would at the very least wipe the drive completely, and probably reflash the BIOS too before actually considering it safe for personal use.
If you're talking about Brooks's law, that's a pretty specific observation that doesn't seem like it applies here. It's very specifically about adding workers to a project that is already behind schedule. It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."
But of the reasons Books gives, most apply regardless of the project being late, such as the communication overhead and the fact that splitting the project neatly is difficult.
Modern software projects are wildly different than OS/360.
The insights from 50 years ago is fine abstractly but it has its limitations.
Not only are there many more roles to fill but things like translation and QA scale pretty well.
It's an adage, not a hard and fast dogma.
Also it was specifically limited to when in the project people are added and often gets misremembered as some linear programming inspired exercise in optimal team configuration.
The latter is obvious and useful (right size the team for the job) but IIRC, Brooks doesn't actually address it in the famed literature.
I don't think I've ever worked on or even seen a software project that wasn't in some way considered behind schedule. Very, VERY rarely are the correct number of people hired at the beginning.
Sometimes it's more! You have nine projects you want to do. A, B, C, D, E, F, G, H. You have 2 developers. You hire 3 more. One of the new hires has more familiarity with what projects E and G needs than anyone on the existing team had. One of them is slower than the average of the existing devs. One of them is MUCH faster. The five of them complete those nine projects in three months (15 total people months, with boosts from one of the new dev's skills and the other's increased speed) when it may have taken 9 otherwise (18 total people months).
But I've seen a lot of companies not be quite that smart in their hiring...
(The faster scenario I've outlined above also potentially bites you in the butt if you don't have enough more valuable projects lined up behind that first set...)
There is a sweet spot for how many people should be on a team. That number depends entirely on a nature of tasks. I would even go as far as to say - in a good environment up to that sweet spot, productivity gain is linear.
And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything about it).
The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability".
What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0.
Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times).
Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you).
You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.
Large software orgs get around this by having multiple projects that are either loosely coupled or completely separate. Otherwise there’s be no point in hiring more than 10 engineers at any point.
I’ve actually spent a long time working at engineering orgs that run super lean. On the upside there are never layoffs, on the downside you’re really constrained on what problems you can tackle - and that can have some major (negative) business implications.
Anyway I can’t help but feel we are slowly reverting back to the aughts where people thought you could clone Google or whatever with like 5 engineers and didn’t understand why nobody took them seriously.
Headcount is a good way to justify a valuation given an investment round - and you have to spend the money chasing growth anyway whether it makes sense or not.
Too many business schools teach classes that claim that managers don't need to know the business that they're in. They just need to know the math. Then apply what comes out of "organizational psychology/sociology" courses to the remaining staff. And when a new CxO takes over, he brings in his cronies who puffed him up at the last place (aka "the new broom sweeps clean"). This is why software companies end up with mismanagers who don't know beans about programming.
I have my own distaste of "MBA Culture" but one thing I would not say is that they teach people to ignore the business and not learn it. From what I've learned, is completely orthogonal to what they teach you in any regionally accredited business school what you are asserting here.
Not all of that is dev. After a certain point, a lot of growth comes from marketing, sales, sales engineering, consulting, support, customer success, etc.
I'd wager most core engineering teams in a co like Apollo are probably quite small and focused. I'd guess the cuts are coming from the ancillary teams.
My comment was about the company as a whole, and slightly targeted more towards management. That said, you are right, dev usually has very little control over these kinds of decisions.
Far too often people are added to existing teams, as if they didn't believe Brooks' observations about communication.
Less often, but much better, are people being hired and put onto new teams, focused on new projects and products. Developers can scale horizontally, but not vertically.
There's a post-dotcom-bubble VC delusion that says that "growth" is the most important thing for an investor. Companies that can show growth, like Uber, are used as an example of "success," and "unicorn" becomes a thing that companies strive for.
So, companies did anything to show growth, which means marketing and incentives to acquire users, to adjacent services, to hiring more staff. I'm sure leadership either knew that this is what needed to be done to get more funding, or they actually drank the cool aid.
But...he's doing the opposite, he laid everyone off. If anything I think that should be encouraged, I remember Whatsapp had less than a hundred employees when they were bought for billions, same as Instagram. I feel like we should encourage embracing the maximum productivity per person rather than throwing more people, since as they said, it doesn't necessarily work.
Why should layoffs be encouraged though? Even if a corporation is bloated, I don't see why we should care if we aren't investors. It can even lead to cool stuff for everyone else, such as more open source tools and software that can usually be contributed by those "bloat" teams
I just like efficient systems, both programming and organizational. Having bloat so to speak just annoys me.
Making open source tools is not something I'd consider bloat, I'm talking more about those in the book Bullshit Jobs by David Graeber.
Having fewer people also leads to people achieving more, ie one company with 1000 employees versus n companies that are 1/n the size, I'd say the smaller companies are much more likely to produce innovations that are useful for society as a whole.
this seems more like a systems problem with a reinforcing and a balancing feedback loop: you're hiring for the future based on current demand, but there's a delay between the syncs of supplying capacity (hiring) and demand.
> Thanks to an incredible performance by our Talent Acquisition team, one of the best in the industry, we grew headcount 2.5x in about a year. But the problem is that growing the company 2.5x didn’t make us 2.5x more productive. It got harder to get things done because we didn’t add the right mix of skills and seniority levels to our team.
From The Mythical Man-Month: "If there are n workers on a project, there are (n^2 - n) / 2 interfaces across which there may be communication... The purpose of organization is to reduce the amount of of communication and coordination necessary". I doubt anybody would ever expect adding large numbers of employees to have a linear effect on productivity, especially if they aren't well coordinated. More people usually means more meetings and more communications costs, as well as more bureaucracy in the way. I find it hard to believe that a leader in software would expect otherwise.
Perhaps management sees tech work in the way they see assembly line workers - they believe that doubling the number of teams will double the ticket throughput.
> I am very sad to make this decision. It’s a consequence of the approach that Matt and I took in scaling the company over the last year, and we take full responsibility for the impact that will have on the lives of our departing team members.
Why do CEO's always say this empty nonsense. If you accept responsibility, you accept consequences - what consequences is Geoff Schmidt going to be facing? Hurt feelings? Give me a break.
This comes up every thread about layoffs -- accepting responsibility means not passing the buck and saying "it was out of our control!" or "this was due to outside circumstance X".
The explicit consequences are up to the owners of the company, not the court of public opinion. The owners wouldn't be beyond their rights to demand the CEO's resignation, although neither are they obligated to do that either since everyone makes mistakes. And as others have pointed out there are implicit consequences as well -- less trust from remaining employees, etc.
Yep. This is a strike 1 for the CEO and everyone knows it.
Unless there is someone else who can do better job, it doesn't make sense for him to step down. However, I do wonder if it would appeasing to take voluntary pay cut as a more visible form of taking responsibility. Just a thought.
The business they built is failing. The emotional toll is extreme. Founders I know are either in poor health due to stress, or place an outsized emphasis on staying healthy. You and others who post this every time seem to be saying "Ah yes, you're not suffering enough in my eyes". How much suffering is enough? Should your degree of blood thirst be applied to employee actions? Are blameless retrospectives a mistake and we should start firing people for making mistakes?
I think this comes from the broader general fact that we have all lived through recessions (e.g. 2008 housing crisis) very differently with very different outcomes.
I often view these statements with knee jerk cynicism (though I recognize it as such) because too often you read about layoffs while executives get golden parachutes. Why should the CEO get the 30 million payout to leave the failing company while everyone else gets comparative peanuts and loses their job.
I can sympathize a bit with why people feel bitter about these things.
I also know some business owners and people who run start ups, those who do it with integrity do have genuine feelings they have to process around this. I try to also remember that not everyone is Jack Welch.
At the same time, everyone in the startup game needs to know that this is a fairly likely outcome. It's just not as safe as being at an institution that can weather the storm.
I tell potential hires explicitly that this can fail, and that there's a runway, and that it's uncertain. I've seen so many places try to sell people that it's just kicking ass all the way to the bank.
So, when a CEO makes this kind of statement, I would refer back to the initial messaging before getting out my coals and rake. Nobody made anyone sign on to a nascent software company. It absolutely sucks to find yourself without income, but you've got to know your risk tolerance. And, by that, I mean you need to know how well you tolerate risk, and you need to know your exposure. If management wasn't forthright, well, that's really shitty.
"Institutions that can weather the storm" like Google? Like Facebook? Amazon?
The entire industry has had layoffs, regardless of size. In fact, in my experience there's plenty of startups that are still growing and hiring the laid off talent from the big institutions. Apollo was not one of those companies, but it doesn't seem like it being a startup had any impact.
Yeah. I figured an obligate contrarian was gonna gotcha me. Sometimes big companies do layoffs.
I stand corrected.
But, then again, the CEO does say: "we are not yet profitable: we’ve taken full advantage of outside capital to speed our growth. That was good stewardship in a time when interest rates were low and venture capital was widely available on good terms. But economic conditions have changed and we believe that it’s no longer prudent to rely on outside capital to support us"
I just don't know what to make of it. It was a healthy company.
> it doesn't seem like it being a startup had any impact
You're statistically wrong about layoffs. Big companies have had way more layoffs than startups. Pointing that out doesn't make me a contrarian. You can admit that you were wrong instead of digging your heels in.
It is humblebragging and getting ahead of rumors. "We are growing strongly, but" followed by the usual platitudes about funding, taking ownership without consequences by leadership, and showing how great the severance is. There is no good reason this should be a public communication.
"I'll be resigning when [the board/leadership] finds a replacement."
I always get massive push back when I suggest this, but it's the only remedy that makes sense. If you have to layoff 15% of the workforce when the growth was under your command, and you want to take responsibility, then step down. Own your mistake.
For startups such a step is likely to ruin the company. And in any case that founder would keep their stake in the company while not being able to influence it anymore. Doesn‘t make sense.
That's only true if the company is better-suited to be run by someone else. CEOs are prominent, but they're still just people. A person can make mistakes and still be the best person for the job.
What if the board doesn't want you to quit? Surely it's better to do what's best for the company going forward rather than to broadcast your self-flagellation.
The goal of the business isn't to maximize employment. It's to maximize profits. Getting rid of employees doesn't mean the CEO did a bad job of maximizing profits.
> what consequences is Geoff Schmidt going to be facing?
Loss in confidence of his employees, fear of mass exodus, pressure from stakeholders, etc...
I don't usually defend CEO's, and it sounds like this one has committed some pretty serious errors, but I certainly would not want to be sending that email out.
tRPC is for a single team working on Typescript frontend to Typescript backend (that's niche). If you have native mobile clients (different lang) or different teams that need to agree on a contract (GraphQL schema), GraphQL is the recommendation, even from ardent tRPC supporters.
I use GraphQL because my clients are not all TypeScript based. Also I don't necessarily want to write my backend in TypeScript either. My stack is therefore Rust with GraphQL with clients in React for web and Flutter for mobile.
> If you need you consume a Graphql API you most certainly reach out for Apollo on the clientside to query data.
Over the last couple of weeks I’ve been assessing whether to use Apollo in a Swift iOS application. If your backend is using GraphQL then it’s almost impossible to find even a StackOverflow answer from anyone not using Apollo.
But when I tried it out, I found the package was cumbersome to use, and the generated code was over-dimensioned and inelegant, and the dependency itself pulled in other dependencies.
With bitter experience of using other packages in the past, which start out as helpful, but which end up a burden to the codebase, I decided to write some queries and mutations by hand. And it was super-simple.
Eh, https://github.com/urql-graphql/urql is considered the improved re-architected project that doesn't contain the legacy baggage from the beginning of GraphQL like Apollo does.
Do you work for Hasura, based on your username? You've been spamming the same comment looking at your comment history.
Anyway, these are all tools to generate a backend based on your database which might work for simple situations but breaks down for more complicated ones. I also don't want to give my backend away to Hasura or Supabase either.
No. I have not been spamming the same comment. I have made several related comments, which I'm free to do just as anyone else is.
Now, YOU'RE free not to use Hasura Cloud (a fine cloud-managed product by a company I work for) or Supabase (a fine cloud-managed product by a company I don't work for). You're also free to use Hasura CE (a self-hosted OSS Docker image), Supabase (another self-hosted OSS Docker image), or Postgraphile (another self-hosted OSS Docker image) if you don't want Hasura or Supabase to host your application. You're even free to believe these tools work only for simple situations but break down for more complicated ones. The thing is, other people are equally free to make other judgments.
If you work for a certain company and you recommend it, you should disclose that you work for said company. Your comments are also near copy-pastes of each other so I wouldn't call them merely related at all.
For the record I have used Hasura before, both cloud and self-hosted versions. At the time Hasura didn't have serverless functions so it was very difficult to do anything custom even with workarounds. Now it seems Hasura has serverless functions now but now I feel that I shouldn't need to tie my backend and code to a database product lest anything happen to said product, lock-in sucks. That they are OSS or self-hosted does not make them any less susceptible to lock-in. I could also use, for example, Vue, also an OSS product, but if something happens to the primary contributor and no one else wants to maintain it, now I either have to deal with bugs slowly creeping in over time or rewrite my frontend.
So, no thanks, I'd rather keep my own backend and not use a BaaS product.
> If you work for a certain company and you recommend it, you should disclose that you work for said company.
I see no good reason to accept that proposition. Moreover, I'm not recommending Hasura in this thread (see below). That would be odd, given that I have also said good things about competing products (Potgraphile and Supabase).
> Your comments are also near copy-pastes of each other
Numbers 3 and 4 are similar but not the same, given their contexts.
For the record, Hasura has never had serverless functions. It never had them before and it still doesn't have them now. We view that as a product decision, but you're free to view it however you like. As for your other reasons for not wanting to use Hasura, you're free to have them just as others are free to reject them. My objective has never been to persuade people to use Hasura. Use whatever you want. My objective was counter claims that I believe are untrue.
> If you work for a certain company and you recommend it, you should disclose that you work for said company.
>> I see no good reason to accept that proposition.
You should absolutely disclose that you work for Hasura when talking about Hasura. Like the other commenter mentioned, this is basic decency on this medium. Failure to do so will reflect very poorly on you and your employer here.
Why? No, seriously. Why? Have I tried to persuade people to use Hasura? No. Have I tried to persuade people that it's good or better than the competition? No. In fact, I only mentioned it in equal terms along with two other competitors, which I DON'T work for (Postgraphile and Supabase, both good products).
What I have done is present not matters of judgment, but matters of fact.
Fact: Apollo is not _the_ GraphQL company.
Fact: Apollo isn't the only one with a GraphQL client library
Fact: Apollo isn't the only path to creating a GraphQL server
As matters of fact, these are either true or false, but readers are free to evaluate which they are on their own. They shouldn't trust me, because I'm a stranger on the Internet. But then again so are you and so are most or all people here.
You say that if I don't disclose who I work for people will trust me less. That's silly, because people here shouldn't trust me at all, nor should they trust you, or anyone else, for the reasons I just gave.
In short: don't accept without careful scrutiny anything you read on the Internet, no matter who says it.
The careful reader will note that I presented three alternatives, with the one provided by my company last. Moreover, what I wrote is in fact a matter of fact. If you wish to have a GraphQL server without having to write server code to do it, as fine a product as Apollo is you cannot use Apollo to do it because that's not what Apollo does.
> I see no good reason to accept that proposition.
It's basic decency on Hacker News or elsewhere. Feel free to accept it or not but know that others will think less of your comments' veracity and trustworthiness by not doing so.
> * Moreover, I'm not recommending Hasura in this thread (see below). That would be odd, given that I have also said good things about competing products (Potgraphile and Supabase).*
Even if you recommend other products, merely linking to it in a list while not disclosing you work there is distasteful.
> I made 4 comments originally:
Regardless of what the claims you were responding to were, your comments themselves for 3 and 4 are copy pasted in content. That is what someone means when they say one's comments are copy-pastes, or said another way, spam. Out of 4 comments, if 50% of them are the same, that's pretty spammy to me.
> For the record, Hasura has never had serverless functions. It never had them before and it still doesn't have them now.
That's funny, I just googled it now and it does seem to have support for them, at least a page that says so. If that's not really using serverless functions (while literally being titled "Using serverless functions") then perhaps they should change the title and clarify the content [0]. I also don't mean that Hasura should have serverless functions itself, like AWS Lambda, I meant that there was not a good way to trigger database events and if you wanted to write custom logic, the recommended way was running a whole other server, which at that point, I'll just write my own backend myself [1].
All this leads me to believe you're shilling for Hasura, don't actually work there, or some combination of both.
> That's funny, I just googled it now and it does seem to have support for them, at least a page that says so
That documentation page says that you can use serverless functions with Hasura, which is true. Hasura custom events call a web-hook, which can be and often is implemented with a serverless function, thought it need not be.
> I also don't mean that Hasura should have serverless functions itself, like AWS Lambda
Thank you for clarifying.
> your comments themselves for 3 and 4 are copy pasted in content
No. I typed out comments 3 and 4 independently "long hand." No copy/paste was involved, save for copying the URLs over.
As for the rest...let's just score that as "a difference of opinion" and call it a day, shall we?
They’re certainly good at getting their name out there, but their libraries seem to be waning in popularity in most of the places people discuss GraphQL.
I’ve personally never used Apollo stuff in prod —- there’s always been a more suitable alternative, but I’ve always appreciated their code for being quite clean. Federation is an interesting technology, but I haven’t had cause to use it yet.
Read maybe not, but I was there if you are curious about anything.
I was there during the transition period. Originally joined to work on the Meteor hosting platform that was called Galaxy. Handled integration of Meteor APM (which was an acquisition) both of which got sold off when the old Meteor business was sold.
I then worked on what was called Apollo Optics, the GraphQL APM product. Rewrote the time series backend to port it to Apache Druid (which remains in use today!). Was somewhat unceremoniously let go of during a bad personal period. Don't think I would have stayed anyway though, main reason I stayed as long as I did was I had a really good mentor there that taught me a lot.
Worth mentioning the company had already raised an absolute crap ton when on the original Meteor path, then the following pivot raised even more money. No idea how many rounds of financing the company has been through at this point but to say it exemplified the excesses of cheap money would be an understatement.
Developer tools is a tough business, no-one really wants to pay for that stuff at the low end which means catering to enterprise. Long sales cycles, annoying requirements etc.
I'm not sad about it, turned out really well for me.
I believe the compelling part of the current offering is the schema management features. We started building these when I was there. I don't know to what degree the alerting part of the APM product survived. It was originally requested by an enterprise customer and I re-implemented it on-top of Druid to make it much more scalable. My assumption is that should be a bit of a draw. etc.
Nice. Relatedly, as someone who has a few years of experience, how does one become a principal engineer? Anything I should know or do to get to that level?
I think most important aspect is experience, the second most important would be leadership. There is little point being a principal engineer if the intuition and experience you can bring to bear aren't embraced by your team so the soft skills definitely count. The role generally encompasses tasks that go beyond writing code, architecture being the most crucial (and technical) but you will also be expected to take part in hiring, making strategical and tactical decisions, etc.
Generally you get there through a senior or staff engineering role where you can demonstrate the technical and leadership aspects. I would focus on mentoring your more junior engineers and taking part in force multiplying efforts, i.e tooling, processes etc.
The expected growth of revenue by growing our workforce did not happen. Together with the tough economic climate, we came to the conclusion that letting 15% of our workforce go will put the company in a better position to survive and navigate the future. Hopefully there will be future opportunities that allow us to grow again.
We are all very sorry for this. Personally, I can barely sleep thinking about the stress and troubles my former colleagues will face having lost their job. We feel it‘s our duty to provide a fair severance package with at least x more months of pay, y months of health insurance, etc.
I am not a writer! Others could do this much better!
At least pretend to be a fucking human and don‘t write disgusting copy-paste trash that sounds like it came from a lobotomized HR junior like Mr. Schmidt did.
Nobody ever likes these announcements. Half the comment thread would rule at your “can barely sleep” comment. They’re too human or too detached, too brief or too prescriptive. At the end of the day, there are fewer things that matter to a firm than the text of their lay-off announcement.
Article starts with a title on gradient background and company logo. This is implemented as an almost 3 MB png file [1] How come?! Why not a simple text and couple of CSS tricks? Why not an SVG? Don't they notice it takes ages to load?
I have pretty limited experience with graphql. Why is apollos offering interesting to people? A hosted graphql proxy? You still need to write your own servers(but theres a ton of good libraries in multiple languages for this?)
Architecturally it seems to be adding a massive hop to requests made, but its not clear to me what the benefit is?
I don't know about the company or how they make money with it (support?), but Apollo is pretty much the standard GraphQL client for frontends. It has pretty sophisticated cache and state management, type generation for typescript, etc.
It’s arguably the least sophisticated of the major clients (Apollo, Urql, Relay), but they’ve done a great job with marketing and documentation. But I’ve personally never used it in a real project because Relay has always existed and I know how to use it.
Depends on language, I've build GraphQL servers in a few, though mostly JavaScript and Python. For Python I used to use Graphene, these days I use Strawberry.
For JavaScript, I originally used graphql-js and express-graphql, as these were the original libraries and I was a literal day 1 adopter. All the libraries are essentially just wrappers around graphql-js, so it's still viable to use directly. But for schema-building I now use Pothos (https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix).
Personally I wouldn’t advocate for these as I don’t believe it’s a good idea to automatically generate a GraphQL schema based on your database (I haven’t worked on anything in years where this would’ve been a good idea). But YMMV as always.
In a world where you have multiple clients, you want to minimise duplicate work of derived state. Unless your UI-level data model is 1-1 with your persistence layer (rare, in my experience), there’ll need to be a transformation somewhere, and since your GraphQL server provides a common interface for UI clients, this transformation should happen at or below the GraphQL layer.
I'm trying to follow you. Are you saying that different UIs should (or may) have different data models, which themselves are different from but still derived from and related to the persisted data model?
Say you have a web app, an iOS app and an android app. And let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data in the database. It means somewhere between the database and the UI template you’re going to be transforming from one model to another. What you don’t want to do is have the equivalent transformation implemented 3 times — once per app; instead you want to do this transform at or below the common interface that they call operate against, ie the GraphQL server.
In my experience it’s very uncommon for anything other than simple prototypes to not have at least some divergence between the UI model and the persistence model.
> Say you have a web app, an iOS app and an android app
and
> let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data
Question: If we stipulate that the UI models are different from the persistent model, are the UI models are different from each other or are they they same? What I mean is this. Do the web app, iOS app, and android app models differ from each other? This is important for my reasoning that follows.
Generally no, they’re not different. For example, the consumer Twitter apps; or when I worked there, Depop.
The situation may change if you also add internal tools to the mix, since they’re often operating on a superset of data that the consumer apps might have access to - though still not necessarily the same model as the persistence layer.
Can be, sure. But SQL, whilst very capable, isn’t the language I’d reach for in order to define my entire business logic layer. Sometimes these transforms are fairly involved and pull in things from multiple data sources and APIs, yes these can be done with advanced SQL wrangling, but at some point you’re just using the wrong tool for the job.
What these companies offer (another one I am using is "The Guild") is mostly tooling and DEX. GraphQL is a specification. The implementation will depend on the tools/infra you'll use. That's what these guys offer.
In addition to the other comments, their APM platform is built specifically for graphql so it includes things like query performance on the field level. Existing tools don’t always play nicely since a graphql server is usually just one endpoint and doesn’t use normal status codes.
They also provide libraries for both the client and server so they can tell you what versions of your client are using specific data.
I'm not the one at my company closest to the situation, but my understanding is that even though our federated gateway is self hosted, we still pay to use Apollo's proprietary schema verification and compatibility check service. I think our front end team also uses Apollo Studio a lot for building queries, which I'm assuming costs something.
One reason why they're laying everyone off. Lots of VC money sloshed around the past 15 years but now it's time to actually turn a profit for most of these companies. This will show whether their business models are actually viable or not.
In a low interest rate environment even if you were profitable, if you could get cheap money it might have been worth it to grow vs. slow down and let other competitors get market share. Many companies that could be profitable choose to invest low cost for capital in growth
This is one of the more straightforward announcements with minimal sugarcoating. Letting employees keep the equipment is a nice touch, since honestly they're not worth much to the company anyway. Wish those impacted best of luck.
It's near the end of the quarter and holidays tends to be less productive time for employees with many taking extra time off anyway. Even with the very generous severance is still makes sense to announce these layoffs before some of the least productive times.
Also personally, I think I'd rather know about being laid off before going into the new year.
Yeah, it's nicer to know you're on severance going into Christmas so you can tighten the belt than find out you don't have a job coming out with bills coming due.
January 1st would be calendar year though and not necessarily the fiscal year. The fiscal year can start and end any month the calendar year a company chooses. The fiscal year often does not correspond to the calendar year. See:
As soon as the economy recovers, doing these kinds of layoffs will be terrible for the companies reputation. Right now, it’s more like “who can blame them, everyone is doing it”.
Depending on your jurisdiction, most countries or states require companies to treat PTO as cash and pay it out upon leaving the company. One reason why unlimited PTO is so popular, no need to pay anything out at the end.
So they were basically a 100 person company before the pandemic if they grew up 2.5X. I feel like a 100 person company it's still possible to be familiar with most names and maybe even have interacted with all of them at one time or another. Especially if you've been there for any length of time. 246 people is a different beast altogether though.
Apollo should cease to exist. It is a terrible product and basically designed for being a DDOS attack vector. Never design things like this. They are on the opposite track to the entire web industry.
Can you expand on this? Is this a generic criticism of GraphQL? Apollo server? Client? And what do you mean by opposite track?
I really like GraphQL but agree that it‘s not trivial to implement well.
I also think it recently became a bit less relevant for web applications (React server components come to mind) but it‘s still very useful for some web apps, mobile apps and generally for designing nice APIs.
We use GraphQL a lot for static content. Most content on modern webs should be static, or at least deterministic. What I am saying is that GraphQL should not be used at runtime to do these dynamic magic queries, which is the key feature in Apollo.
> Most content on modern webs should be static, or at least deterministic
What does this even mean?
> What I am saying is that GraphQL should not be used at runtime to do these dynamic magic queries, which is the key feature in Apollo.
What does this even mean?
How are you defining "dynamic magic" and "deterministic content"? GraphQL sends a query to a server that resolves it into the requested data. Is it not true that if you plug this into something like PostgreSQL via Hasura, you naturally have "determinism" in the same way Postgres offers it?
Please, expand, I have no idea what you're saying and I'm a full time web guy
Apollo is literally build on top of REST. It adds types and clarify the dependencies between the types. It enhances an existing protocol by adding features.
It is not a silver bullets but it has advantages like self-documenting (Playground), ease of discovery on big API (generated documentation with types) and can have TypeScript type generated for your (reduce the number of interfaces/types to maintain).
Federation is also a good concept if you have many teams that need to converge into a cohesive API gateway.
Overall, if you use it properly it can be a great tool.
I can't speak to dysfunctional, but I can speak to hype. Both just had too much of it and it made me not so interested in them. Apollo is still trying to use hype as its main weapon – here's what its homepage says:
> we’ve taken full advantage of outside capital to speed our growth...But economic conditions have changed and we believe that it’s no longer prudent to rely on outside capital to support us
Lots of companies have been hiring for growth or for investment. What the companies should have done, though, is hiring to unblock. A couple of engineers build a product that turns out to be generating amazing growth, and then hire a team to polish the system.
I'm curious to know from some (ex?) employee how badly this was managed. In my experience it's really hard to fire 15% of employees by personally talk to each of them, without massive delays (e.g. one is on holiday, different timezones, etc). The first 2 or 3 that get their accounts deactivated, usually trigger mass panic in the company.
As someone affected by layoffs earlier last month, I can say this market is not looking great. With hiring frozen everywhere I'm afraid there probably won't be hope until Q2 2023
I was also laid off earlier last month. Comments like yours would scare me.
So I hope I don't come across as rude or anything, but I want to provide a counter-anecdote.
I was laid off in very early November. I took about 2 weeks just to get over about 80% of my saltiness at what I considered to be a betrayal. (I won't go into detail, forgive me, I'm still not able to talk about it without being salty yet.)
I then asked my two best tech friends (1 from college, 1 from my first job) for referrals to the companies they worked at. I did 2 interview loops, got 2 offers, and picked one. I got a ~10k raise over my last position in the process, though mostly out of region arbitrage (last job was geo-adjusting me down ~10% whereas my new job was not, but it's a smaller company and an earlier stage company, so less cash to sling around, but more equity).
(for the record, I have 9 years of experience and the position is "senior software engineer" which was the same as the job I got laid off from).
So - to all you fellow laid off peoples - don't rely on anecdotes from strangers on the internet. I wouldn't have ever made this post as a top-level post, but I hope my 2c calms folks a bit.
(And for the record... I was intending/expecting to apply to more than 2 companies, but I was a bit sick of applying to companies where I didn't have an inside opinion on the culture bc I felt like I got burned by tha tlast time, so I gave these 2 companies (where I did have that inside opinion) the benefit of being the only 2 companies in my first salvo of interviewing, so I could give them extra attention. And I happened to get an offer I really liked at a company I feel good about, so I took it, even if I guess I probably could've optimized a few more k of base pay if I'd grabbed more/bigger companies in my first round.)
This is called networking. You have a decade of experience and some good connections. The longer you go in any career, the higher paid you are, and the more important networking is. Don't burn bridges!
* 15 weeks base pay + 1 week per year of employment
* 6 months COBRA + $300 mental health
* no 1-yr cliff, options can be exercised thru next year
* you can keep all your equipment