Don’t learn to code in your production Salesforce instance

If you spend time in the Salesforce developer forums, as I have for nearly 8 years now, you’ll regularly see posts asking for advice on how to implement complex start/end of day process. The scenario will be along the lines of identifying all accounts whose owners satisfy a number of criteria and processing the associated tasks, opportunities and cases, often with a callout to an external system to update a subsidiary’s view of the world. I read these and think that’s the kind of interesting problem that our enterprise customers here at BrightGen ask us to solve. The kind of solution I’d estimate in days rather than hours for one of our experienced developers to design and implement. And then I read the final sentence with a strong sense of foreboding:

I am completely new to development and know nothing about Apex.

When I see this, every fibre of my being wants to write a one word response — don’t!

It’s one thing to put together a simple trigger based on examples and help from the community, but quite another to build a complex solution that forms a key part of your business automation. To me it’s a bit like taking your car in for some work and being told:

This is our new mechanic — he knows nothing about cars but we’re going to let him replace your braking system using this really helpful online forum and some youtube videos.

It’s unlike that you’d be happy with that, but for some reason it’s okay to practice coding on the system that runs part or all of your business. If someone is new to development they are also going to be new to unit testing, which makes it highly likely that they will produce just enough test code to allow deployment to production, whereas this is a situation where robust testing is an absolute must. The happy path through code often turns out to be the exception rather than the rule once real data is involved.

This doesn’t mean that the code will break in production — it might appear to be running fine, completing successfully every day, just not actually doing what it is intended to. As it’s an automated solution, everyone will expect it to be working and won’t be verifying things every day, so problems may not be found until they are costing real money. Once that happens you not only have to fix the code and data in a hurry, but your users will also lose confidence which damages adoption

This doesn’t mean that if you aren’t a developer you shouldn’t learn how to write Apex code, but the key word is learn. Take the time to get a grounding in Object Oriented programming and understand how Apex the language works — in the long run this investment will pay you back over and over. But do this in a developer edition rather than your production instance, because you will write code that breaks — we all do.

I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 5 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring.

BrightGen Careers_At BrightGen, we do more than manage Salesforce implementation projects for our customers. We play a pivotal, strategic…_www.brightgen.com

You can find my (usually) more technical thoughts at the Bob Buzzard Blog

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!