Earlier quoted context omitted.
It depends on vertical. Large corps likely have some huge codebases of overengineered spagetti code, which are hardly comprehendable by LLMs. But if you want to build for example some new/smaller web/mobile apps talking to various API, LLM can boost your productivity significantly, because it will easily generate ready to use code snippets.
> Large corps likely have some huge codebases of overengineered spagetti code, which are hardly comprehendable by LLMs. I think it's the other way around, though. Those code monstrosities aren't comprehendible by humans , especially after the wanton RIFs that have happened in the past couple years that have cut loose a lot of people who know where the bodies are buried. However, with copilot you can just figuratively…
Salesforce will hire no more software engineers in 2025, says Marc Benioff
141–150 of 409 posts
Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#142Current SFDC software engineer - this is just cover for a widespread engineering hiring freeze since the layoffs in January 2023. There's a ton of pressure to control costs after the near shareholder revolt that caused the layoffs. The public nature of the announcement is certainly marketing for our AI offerings as well, but at this point I think most engineers are just worried there will be additional layoffs, in th…
Looks like it. The only other explanation is they just stopped investing in other products and focused on Agents, thus no need for loads more of engineering. No way in the world they got 30% gains. 5 maybe realistically
Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#143Current SFDC software engineer - this is just cover for a widespread engineering hiring freeze since the layoffs in January 2023. There's a ton of pressure to control costs after the near shareholder revolt that caused the layoffs. The public nature of the announcement is certainly marketing for our AI offerings as well, but at this point I think most engineers are just worried there will be additional layoffs, in th…
There’s other things going on though this will help spin.
There’s no way that productivity metric includes the last 2-4 months.
Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#144Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#145I tried to buy Pro Tools a few years ago. Avid was using a SalesForce system, which is such a monumental piece of trash that they couldn't complete the transaction. The attempt involved weeks of back-&-forth, mind-bogglingly incompetent and defective. They ended up giving me a temporary license because they thought I had a project to complete. SalesForce, SAP, and the other purveyors of steaming legacy enterprise exc…
Everywhere I've worked at that had some kind of Salesforce integration, that integration seemed almost incomprehensibly complex or a source of endless problems, and often both. But I've never been (nor wanted to be) very closely involved with any such integrations. Is Salesforce garbage? Is that just how CRM systems are? Is everybody just doing it wrong? What's the deal?
These kinds of tools cover 80% of what you want to do out-of-the-box.
For the remaining 20% to build it correctly you need to either hire expensive consultants or hire in-house staff to build.
Nobody budgets properly for this, and it isn't in the sales pitch, and so that last 20% is built as horrible spaghetti code by the cheapest possible devs / consultants.
Even if you wanted to pay good salaries and hire people in-house how many great engineers want to be limited to programming in Apex on salesforce?
Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#146Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#147Current SFDC software engineer - this is just cover for a widespread engineering hiring freeze since the layoffs in January 2023. There's a ton of pressure to control costs after the near shareholder revolt that caused the layoffs. The public nature of the announcement is certainly marketing for our AI offerings as well, but at this point I think most engineers are just worried there will be additional layoffs, in th…
Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#148He will be hiring by Jan 15, 2025
https://careers.salesforce.com/en/jobs/?page=1&team=Software...
Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#149Re: Salesforce will hire no more software engineers in 2025, says Marc Benioff
#150I tried to buy Pro Tools a few years ago. Avid was using a SalesForce system, which is such a monumental piece of trash that they couldn't complete the transaction. The attempt involved weeks of back-&-forth, mind-bogglingly incompetent and defective. They ended up giving me a temporary license because they thought I had a project to complete. SalesForce, SAP, and the other purveyors of steaming legacy enterprise exc…
Everywhere I've worked at that had some kind of Salesforce integration, that integration seemed almost incomprehensibly complex or a source of endless problems, and often both. But I've never been (nor wanted to be) very closely involved with any such integrations. Is Salesforce garbage? Is that just how CRM systems are? Is everybody just doing it wrong? What's the deal?
One, the salesforce data changes all occur through APIs (ok) which various enterprise integration tools (Informatica, Mulesoft, etc) support (ok), but those tools typically dont support easy options for retrying a change to a specific row that causes an error. If you are updating 100 Accounts in a single Salesforce Bulk API call and "5" are busy/locked, you have to build a lot of custom error handling to notice and retry just those 5 rows. Its not part of most connectors or python libraries I've seen. Also, 3 of those errors might be fatal and 2 might be retriable but you have to learn which are which or blindly retry them all. In database terms, their API transactional semantics are not statement by statement ACID but row by row within an API request.
Second, no API or SOQL operations can pull back or process or update more than 50,000 rows.
Given those two things, unless the integration person is skilled about both error handling and testing, some of the object busy/contention failures only show up in production traffic with many jobs going on so a generic integration specialist doesn't know about these Salesforce-specific pitfalls and they are discovered after the integration goes live under strange production access patterns.
EDIT: a third issue is that most Salesforce developers are UI-centric in their thinking and training and don't have database or data modeling or data integration experience to draw on so the troubleshooting for data issues on their end tends to suffer.