Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CircleCI Layoffs

circleci.com

Post reply on HN
Print view View original

91–100 of 145 posts

Re: CircleCI Layoffs

#91

Post by Syntaf »

015a wrote: post #30

I don't want to turn a discussion surrounding layoffs into a lens about the business itself; it sucks to be laid off, and I wish everyone who was impacted great expediency in finding a new role. But I'm going to anyway: I genuinely don't understand how CircleCI is still a business. Every major code repository provider has CI built in. All of the ones I've interacted with (Github Actions & Gitlab) are just as good as…

Agreed on their stability. For a period of time earlier this year it felt like CircleCI went down every other day, and since we require checks before deployment it was a pain constantly having to deal with outages.

Re: CircleCI Layoffs

#92

Post by culi »

hobr wrote: post #19
johnrob wrote: post #13

Earlier quoted context omitted.

Surprised that is possible in the age of compliance for certifications (PCI, HIPPA, SOC2, etc).

If they are using Mobile Device Management (MDM), they can remotely wipe all the laptops before allowing departing staff to keep them.

from another comment here by someone who was part of these layoffs it doesn't seem like they're being wiped

Re: CircleCI Layoffs

#93

Post by saxonww »

Tao3300 wrote: post #43
meta2023 wrote: post #35

Earlier quoted context omitted.

You're being downvoted for telling people exactly why they got laid off. It's time to wake the fuck up engineers. When you complacently don't pay attention to your business and core offering, this is what happens.

Engineers aren't generally setting the priorities on what gets fixed when or what the business is actually offering. The complacency problem is usually in management. Can't speak for how CCI is run, but that's how it is at most places with more than 10 people.

I think the point is more that there's increasingly no reason for CircleCI to exist. All your major code hosting players have a CI tool and the various accessories you'd want to attach to it.

I think CircleCI has a niche in orgs that self-host code in e.g. phabricator or gerrit, and want a cadillac CI experience without building it themselves in jenkins or similar. I'd argue that niche is shrinking, and as a CCI employee or potential job-seeker I would wonder whether CircleCI is a good place to be because of that.

Re: CircleCI Layoffs

#94

Post by edgyquant »

TheDong wrote: post #61
prepend wrote: post #50

Earlier quoted context omitted.

Engineers choose who to work for. We go through these cycles where “I have no idea how they make money but they keep paying me” stops working. There’s only so long you can work for a company that doesn’t have a viable business strategy. I don’t expect engineers to fix the business strategy, but I expect them to consider it when choosing to join a company or to stay.

> I don’t expect engineers to fix the business strategy, but I expect them to consider it when choosing to join a company or to stay. For many companies, you cannot be qualified to make this determination. Let's say I interview at a farming tech startup. They tell me that there are X million farms in america, and Y million have told them they want the crop software they're building. How do I make that determination o…

Engineers should be domain experts. This isn’t the case now but I imagine as more people become engineers, and more stuff leans towards automation, this will end up being the case

Re: CircleCI Layoffs

#95

Post by aeyes »

aftbit wrote: post #15

I feel for all the engineers impacted by this layoff, but I do not agree that they are "the best CI/CD platform on the market". Our small team has moved away from CircleCI for all new projects. We are mostly using Github Actions these days. The major driver was not cost, which was minimal for our team, but the fact that CircleCI keeps breaking our build. In the ~5 years that we have used them, we have experienced at…

It is going to be interesting to see how many breaking changes GitHub Actions will have in the next 5 years.

At least they have the advantage that they weren't a first mover so they hopefully learned from the mistakes of other companies.

Re: CircleCI Layoffs

#96

Post by SkyPuncher »

015a wrote: post #30

I don't want to turn a discussion surrounding layoffs into a lens about the business itself; it sucks to be laid off, and I wish everyone who was impacted great expediency in finding a new role. But I'm going to anyway: I genuinely don't understand how CircleCI is still a business. Every major code repository provider has CI built in. All of the ones I've interacted with (Github Actions & Gitlab) are just as good as…

CI has essentially become a commodity with a need for reliability.

For us, we moved from Travis to Github because Travis just wasn't reliable enough (and had terrible security). We'd be blocked from deploying for hours at a time because Travis had a random outage. I know it's way more complex than "boxes that run some stuff", but CI/CD isn't exactly rocket science.

We also noticed that by using a dedicated CI provider, we doubled our deployment downtime. We'd be blocked from deploying when either Travis or Github had issues. Whereas, we're only blocked now when Github has issues.

Re: CircleCI Layoffs

#97

Post by SkyPuncher »

Tao3300 wrote: post #43
meta2023 wrote: post #35

Earlier quoted context omitted.

You're being downvoted for telling people exactly why they got laid off. It's time to wake the fuck up engineers. When you complacently don't pay attention to your business and core offering, this is what happens.

Engineers aren't generally setting the priorities on what gets fixed when or what the business is actually offering. The complacency problem is usually in management. Can't speak for how CCI is run, but that's how it is at most places with more than 10 people.

We intentionally involve our engineers in product decisions and customer discovery.

We don't expect them to be driving novel, new features (unless they're technical in nature), but we do expect that they call out BS and make sure what they're working on is valuable to the business. Exception is platform teams who's "customer" is other developers.

Re: CircleCI Layoffs

#98

Post by intelVISA »

015a wrote: post #30

I don't want to turn a discussion surrounding layoffs into a lens about the business itself; it sucks to be laid off, and I wish everyone who was impacted great expediency in finding a new role. But I'm going to anyway: I genuinely don't understand how CircleCI is still a business. Every major code repository provider has CI built in. All of the ones I've interacted with (Github Actions & Gitlab) are just as good as…

> I genuinely don't understand how CircleCI is still a business.

In slight defense of Circle CI I think that could be applied to at least 50% of tech companies. Though CCI is perhaps more guilty than most of this transgression.

Re: CircleCI Layoffs

#99

Post by SkyPuncher »

aftbit wrote: post #15

I feel for all the engineers impacted by this layoff, but I do not agree that they are "the best CI/CD platform on the market". Our small team has moved away from CircleCI for all new projects. We are mostly using Github Actions these days. The major driver was not cost, which was minimal for our team, but the fact that CircleCI keeps breaking our build. In the ~5 years that we have used them, we have experienced at…

> including the migration from v1 to v2 yaml configs

Holy shit. I forgot about this. I was infuriated when I needed to waste nearly a week rewriting my config with more complexity and reduced features. I literally wasted a week of my life so a company I was paying could save costs.

I would have happily paid 50% more to not have to waste my time on that crap.

Re: CircleCI Layoffs

#100

Post by aeyes »

WirelessGigabit wrote: post #54

To this date I cannot build the hypothetical result of a PR with CircleCI. Number 1 reason not to use it.

What hinders you from doing a rebase onto the base branch after the initial code checkout of the PR branch?

Maybe it would be good to have this as a built in feature but it can get complicated quickly, I actually prefer doing it manually.

Post reply on HN