Hacker News Reader

Comment by jsm | Hacker News Reader

> The tech is proprietary, and not that fun to work with.

> As someone who has worked extensively with Salesforce, the cult like fanbase is annoying. I'll be the first to admit the tech is underwhelming and in many cases nowhere near other modern technology.

True. But Salesforce allows fairly non-technical people to build fairly robust applications with very limited CS training. If I were interested in getting a technical job but had no experience, I'd consider becoming a Salesforce administrator as a way to get paid to learn to code on the job. [1]

You can build something that is complex and scalable without any programming experience. And what you build will be supported for the next ten years. It's not a terrible proposition for most businesses - especially outside of the Silicon Valley bubble.

[1] https://bluecanvas.io/blog/2017-07-25-getting-paid-95k-to-le...

View on HN

I've worked with engineers implementing Salesforce at two different companies.

While SF may or may not be the right solution for a problem, I disagree with your assertion that developing for Salesforce will in any way prepare you for a "real" programming job.

You would mostly learn how to configure a lot of UI, maybe write some custom widgets (with Lightning), and write a a little bit of integration code here and there - in an arcane Java-like language.

All you really learn is the Salesforce ecosystem.

You can make very decent money if you can sell yourself. As others have mentioned, Salesforce could be seen as a sophisticated employment scheme for consultants.

But I would advice anyone to steer clear of it as a career path. At least until you have some proper experience in other technologies.

You're still thinking of Salesforce from 5 years ago: https://developer.salesforce.com/blogs/2018/12/introducing-l...

No, that was 1 and 2 years ago respectively.

Lightning was what I was referring to with "custom widgets".

>allows fairly non-technical people to build fairly robust applications with very limited CS training

Ok. BUT... when those limited CS training people want it done right, they hire any one of the huge middlemen do make SalesForce integrations and modules.

ATG is one I know of first hand. Hiring tons of people to make SalesForce suck less. Mostly sales people themselves, then some programmers to do the real work.

This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.

Think of the other tech companies over the years that have seemed like behemoths to be utterly knocked out by someone that came in and sucked less. What do you think happened to the industry of Certified IBM Professionals that relied on IBM being market leader in PCs?

> This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.

It's worked for hundreds of thousands of people who make a living from turning raw Access/Excel/Wordpress/Microsoft CRM/Dozens of other products/etc into custom applications that solve the needs of particular business processes.

Every business has its own warts, that no one-size solution is going to solve well, and that will require someone to write a plugin for an off-the-shelf business product.

Outside of the Silicon Valley bubble, most software engineers make a living doing just that.

My first job was writing simple glue scripts that talk to a database for a small biology lab, to help them keep track of their samples and orders. It was ancient. I was so grateful to have the job. Man, I was happy.

This is the 99% of programmers who are a lot more grateful to have a stable API that reliably works than they are worrying about "obsolete languages".

The more time I spend in this industry, the more I begin to think that developers are really not the friends of users or even of their employers. Developers hate maintaining code they didn't write, which is the most important need most businesses have, as well as the most important need customers have. This creates a real tension where companies, especially as they become a monopoly, tend to lose the customer focus and start focusing on internal constituencies. And in a tight labor market for devs, that usually means mass rewrites, rolling out complicated ambitious new frameworks and models, rather than, you know, adding features that customers use to existing code.

The result of these rewrites is generally something with fewer features, an unfamiliar interface, and more bugs than what preceded it. Joel Spolsky has a nice article about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Well I mostly agree but you have to consider technical debt

Technical debt is always a problem. But generally I prefer refactoring existing code rather then rewriting to address technical debt, because I think the old system is well understood, and the deficiencies are known. When you blow it away, you are also creating more technical debt, but you just haven't discovered it yet.

This isn't to say "never rewrite". I am saying we rewrite way too much now.

What makes you think the hypothetical rewrite on a new technology is going to have any less technical debt?

By the time you get to feature parity with the old shitty system, your new system is also going to be shitty. In my experience, technical debt comes from three places.

1. The people who built the system didn't know how to do things right the first time.

Solution: Employ experienced people when you're building the system, the first time. If you didn't do that right the first time around, have experienced people rewrite the bad parts.

Non-solution: Rewrite the whole thing in a new technology that nobody is experienced with. (On average, your new team isn't any more skilled than the team that built the original system.) Waste time rewriting the parts that aren't bad.

2. The problem is actually incredibly complicated, and has no clean solution.

Solution: Don't do anything.

Non-solution: Rewrite the system, re-discovering all the reasons for why it was built the way it was.

3. Most of the system is actually fine, there's just a few bad parts.

Solution: Refactor the bad parts.

Non-solution: Rewrite the whole thing, even the parts that are maintainable.

I have seen a lot of painful rewrites, but I've never actually seen any featurefull software project that did not have a lot of technical debt.

> fairly robust applications with very limited CS training

peak hn

Meaning what, exactly?

>> fairly robust applications with very limited CS training

Historically, this hasn't gone well. I'm sure many Software Engineers here can attest personal anecdotes to that.

> peak hn

I believe that are saying that this this is the epitome of what HN has become. ( what they believe to be non-software engineers discussing things. )

While I don't encourage gatekeeping, I think anyone can become a software engineer if they read the right books and spend enough time. I had a similar sentiment about seeing the line:

>> fairly robust applications with very limited CS training

This is an oxymoron. Non-technical people simply cannot build 'fairly robust applications' for reasons they quite simply don't understand. Building robust applications is way more than making it work. You also have to make it maintainable and scalable. Salesforce code I've seen written by people with 'very limited CS training' is neither of these.

Reply on news.ycombinator.com