[Tao3300]

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.

[saxonww]

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.

[Beltalowda]

I never used CircleCI so I can't speak to it specifically, but there's tons to improve on GitHub actions.

The Actions web UI is so bad it's almost a parody. Debugging stuff is harder than it needs to be. No good way to manually control builds. Possible but not very easy to run stuff locally. Very limited platform support (Linux Windows, and macOS, although other platforms are possible with VirtualBox hackery but it's SLOW and pretty unreliable).

It is enough to make a viable business when GitHub actions is right there? Who knows... But there are tons of reasons for external CI tools to exist, IMO.

[wfleming]

Even that niche has better competitors, I think. I haven't used on-prem CCI, but I used hosted CCI for several years and when my team switched to https://buildkite.com/ it was a huge breath of fresh air. I think BuildKite is the only CI system I've used I thought was actually worth paying for, and I bet it works out cheaper than self-hosted CCI in most cases as well.

[prepend]

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.

[TheDong]

> 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 of whether this is a viable business strategy? I'm not a farmer, I do not know enough farmers operating large farms to gather that data myself, I have to trust the company to represent this truthfully.

This even applies to things like CircleCI, where the product is something an engineer can understand well. I know what tools I as an individual developer use, but CircleCI is targeting enterprises, which I decidedly am not. I have no clue how some enterprise shop works. Again, I have to trust how the business present itself.

[prepend]

> For many companies, you cannot be qualified to make this determination.

It’s hard but useful. If you know this, you will be more successful whether you’re in engineering or sales or whatever.

I research every business and organization I do business with. It’s not perfect, but it’s part of my decision making process.

In CircleCI’s case, this would be me looking at the financials (hard because they are private), talking to some friends who use them, and, since I know some tech, trying the product.

It’s not wise to trust every business as every business has people thinking and saying they are great. It’s wise for an individual to assess these for themself. Companies success isn’t entirely random.

[tomnipotent]

This research helps you form a more informed opinion, but it doesn't make you any more qualified at predicting the companies future success potential. The people running these companies are barely in such a position, nonetheless the average person who thinks they're privy to prescient insight.

[prepend]

I’m not sure what you mean by qualified.

The research makes you more able to make an accurate decision. It helps improve your outcome.

I don’t think being qualified is important here. I think the important piece is to make a good decision to join a firm, or leave a firm.

There’s no perfect information, but every potential employee has the ability to improve their chances by researching important decisions like this.

I think a good litmus test is if I can’t answer “how do they make money” or “how will they make money” or “how do they create value,” then I don’t want to work for them.

[jamesfinlayson]

I do agree, though I think on the CircleCI front at least, it's had some not positive press on Hacker News this year (big price rises and or cutting the free tier from memory, plus the launch of GitHub actions).

But yeah, for industries we don't understand... hope it's publicly listed and has some insightful annual reports is probably the only option.

[sifar]

Instead of just giving up that you are not qualified to do so, you can at least do a preliminary analysis.

1) Follow the money - where is it coming from ? why would it keep coming in, what is needed ? where does it go ?

2) Competitors - who are they and what are they doing.

For your hypothetical farming tech company, find out about other farm tech companies who have similar product/market segment and look at their offerings, valuations and revenue model. If one does not have this reference point and doesn't have the domain knowledge, then one should not consider said opportunity unless one wants to gamble.

[edgyquant]

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

[bfung]

> Engineers aren't generally setting the priorities on what gets fixed

A good engineer would be like: “f—k it, I fixed it.” And the priorities would then get shifted around it.

Identifying when this is the right time to act and fixing it often makes the engineer gain seniority.

(Yes, it only works when both business and tech are broken. If it’s just the tech broken, then engineer will probably get pipped for working on wrong thing)

[servercobra]

I'm not sure how an engineer could be like "f--k it, I fixed it" to the company's business and pricing model.

[otikik]

By being 10x, full-stack, and a ninja rockstar.

[bfung]

The context to my post are the reliability issues that def. can be instrumented and fixed.

Business and pricing model not so much unless the engineer is willing to add the Sales prefix to their engineer role ;)

But even the pricing model - measure and compare the costs, competitors, and value derived (ok, commodity now vs 5yrs ago) and work with people pitching prices.

That’s still designing, analyzing, measuring systems - prices instead of code - definition of engineering.

[spoils19]

I've done this multiple times in my career.

[icedchai]

Exactly this. I've worked for founders at small companies (<20 people) who just did not want to listen to advice or suggestions. It would be almost impossible to change anything at a larger firm. Let's just keep doing the same old thing that isn't working.

[pitched]

I think the saying is “vote with your feet”. There’s always at least one thing you can change. Your time is worth more than your salary, otherwise they wouldn’t pay it. If you don’t think a business will survive, stop investing into them with your time.

[icedchai]

Definitely. And I did exactly that, eventually. (I waited too long!)

[SkyPuncher]

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.