Menu
A retrospective on 2 months of learning Salesforce by Tom Blockley
This is intended to be a useful, but lighthearted look at the learning curve of Salesforce when you are already a developer of some sort. It is intended to communicate the advantages (and disadvantages) of learning Salesforce as a second (or third, or fourth, etc…) technology as opposed to learning it as a first technology as someone fresh out of university might.
In the form of an Agile Retrospective. Because why not.
This is aimed at people who already have a bunch of experience as a developer, who are thinking of branching out / retraining into Salesforce.
It is for companies who do a lot of Salesforce development work and are looking to bring on board an experienced developer.
It is for Salesforce employees and developer advocates who will have a little (a lot) more clout than me, to maybe grab some learnings for enticing career developers to switch to Salesforce.
I’m Tom! I joined Desynit (and the Salesforce community) at the beginning of April this year. I had never looked at Salesforce before.
I’ve been a *cough* professional *cough* developer since 2005.
Most recently I spent nearly 8 years at another great Bristol based company, writing a whole load of Python.
I have been a Certified Scrum Master since 2012 and have put that to good use.
I am not a specialist and I wear many hats (metaphorically – I actually don’t much like actual hats, they make my head sweat).
Loads of stuff went well, I’ve really enjoyed learning Salesforce so far. But that’s vague so here are some specifics:
Trailhead
Trailhead is a great learning resource and I wish more technologies had similar quality learning materials. Concepts and features are introduced in a neat fashion, and you are often reinforcing things you’ve learnt in previous modules, making sure they are nicely ingrained. The practical challenges are particularly good and it’s nice to get to the end of a module and get it checked for quality (albeit by a robot). Also badges. I have 40 at the time of writing.
Testing
The fact that writing tests for your code is given such a high priority makes me really happy.
I come from a background of relying on a QA team, a Selenium test suite, and the occasional unit test, to make sure that our code was up to scratch. But it took years to get to that point, and still it often fell to manual testing because sometimes your former self was just in a rush right then and there.
In Salesforce, in order to push a release live, you have to attain a certain test coverage. There is a full testing toolkit available and there’s a Trailhead module to get you started. Brilliant!
It’s in the cloud
I used to hate that term because it’s just a machine in a datacenter somewhere and it’s really not a cloud. But Salesforce is, to a developer. You don’t have to worry about whether your client’s site is going to go down in the middle of the night because someone kicked a power cable, or whether your vm/server/cluster is going to get a Zero Day, or how you’re going to run a staggered major OS Version update across your fleet. That’s someone else’s job and that is lovely. (Not for the Salesforce core developers and sysadmins I guess though… thanks for keeping it away from us!). You just write some code and wait for it to compile and there you go, it’s live (well, live in a sandbox).
Learning the language
The language is fine. A lot of what Salesforce is moving towards involves Javascript, so most people who are already developers will be able to grok that really quickly. Apex itself is much like Java. The developer documentation is easy to find and pretty complete, so far as I’ve found so far. The templating language(s) in the page templates is much like any other; you’ve just got to learn the magic words and it will do the hard work for you. SOQL and SOSL are clever and intuitive.
The Community
There’s a lot of great community spirit out there. Developers are helping each other out a lot on the Salesforce Stack Exchange and elsewhere, and that is always reassuring. I have been lucky enough to have met a bunch of the UK MVPs already, and and witness the monster event that is the World Tour. People want Salesforce to succeed. That is important. It’s also fun. The meet-ups and the user groups are really great and I plan to be doing a talk at one once I’ve learned something of use to others!
Of course not everything is wine and roses. Here are some things that I stumbled on that you can feel sorry for me about, or more usefully: avoid yourself.
Trailhead
Some of the trails and modules are aimed at the very beginners, and you find yourself skipping to the end to do the challenge and then working backwards up it to find the bits you missed by thinking you already understood. Bear in mind that these have to cater to beginners, and just try to be open minded and patient – it’s probably better in the long run.
I haven’t been able to spend a great deal of time in Trailhead. If you are a new employer, try to set aside as much time as you can, perhaps allowing for ongoing weekly doses. My learning started very broad thanks to Trailhead but I could have done with more.
Testing
Whilst in theory, testing your code properly in Salesforce should always be happening, I have already witnessed ways for it not to be.
You have to achieve a certain percentage of overall coverage for a release. This means that if you want to cheat you can do so by creating a really long apex class that does nothing (for example one that has a function which instantiates a bunch of really long lists of lists and adds to it one by one) and then write a test that calls it. Bingo! Increased Coverage! What could go wrong!? Apart from everything.
It’s in the cloud
For the most part this is a really great feature. It does sometimes make it slow to build though, and you can’t run a local instance of Salesforce so you HAVE to have a steady, reliable internet connection.
Learning the language
Coming from a very loosely typed, runtime compiled language (Python) to a strongly typed, precompiled one has been both good and bad. I miss having a command line interactive debugger most. I miss having dictionaries, generator expressions, and default values for method arguments, and I keep getting told off for forgetting semi-colons. But I’m getting used to it and it does do everything it needs to.
We’re not that different, you and I
Salesforce is a CRM. Yes, it’s a big, complex, almost infinitely customisable platform, but at the heart of it, it’s a CRM.
A CRM is not that different to a CMS, or any other system that needs to worry about access controls, user roles and groups, workflow, searching and sharing. In my past life I did a lot of work on a Python CMS called Plone. It turns out Plone and Salesforce have a lot in common, which made it easy for me to grasp a lot of the concepts of Salesforce.
Don’t bother trying to rename files
Really don’t. In fact, try to stop thinking of them as files. They’re not really once they’re compiled and such anyway.
If you (like me) like to work locally, you can. There are Salesforce plugins available for many IDEs. I use Visual Studio Code and that has at least two, including one that integrates with the excellent Mavensmate.
However, this makes you think you can create and rename files like you might in a normal filesystem codebase. Don’t. Do yourself a favour and use the plugin tools to create files. If you need to rename one copy the contents into a new file and then delete the old one through the web in the setup menu.
Clicks vs. Code
There is a lot you can do with the declarative side of Salesforce and I strongly recommend to any developer that they embrace it. Just because you can do it in code doesn’t mean you should. In fact sometimes it’s a lot, lot quicker to use clicks. Some things, like permission sets and custom fields is best done declaratively and as a developer you shouldn’t feel bad about that. In fact, you should feel liberated!
Use the Developer Console for log debugging
I personally don’t want to use it for development, because I have a nice IDE that I’m used to, has powerful editing and searching tools. But use it for your debug logs. You can set checkpoints where you can examine the state of all your variables, and query results. They are really snapshots of a point in time, as you can’t make changes then continue the flow, but they are really useful. You can also view the logs of any user by enabling logging for them, again useful for diagnosing user specific issues. Permissions here we come.
Version Control
I come from a world of version control and branching for features and tagging releases and keeping master clean at all times. Going into Salesforce where the only guaranteed canonical source of what’s live is, well, live, is difficult. There is not quite enough integration with version control, and it makes it difficult to run nice feature branches. It often winds up with big commits where you pull in the content from Salesforce and commit it to Git, rather than the other way around. This makes it hard to work in a team, on a single repository, which is really unfortunate.
I’m sure there’s a better way to do this though and I have all my fingers crossed that the Developer Experience will sort out a lot of this. In particular, the scratch orgs look very useful from what I saw at the World Tour. If not then I have some ideas of my own…
Nomenclature
Some of the naming is multiply overloaded, in particular the word App. I am still working on that and I have a feeling that Salesforce is too.
Declarative changes can really mess with your work
If someone goes off and changes stuff declaratively in the live organisation, this can really ruin your day when you come to releasing. In my head there needs to be some sort of pre-release merge that can be run between live and a sandbox so you can see the differences and confirm you’re unlikely to hit a nasty surprise that knocks your release of schedule.
.THIS and other animals
For the most part, the component driven nature of Lightning makes total sense. But there are limitations. I find myself copy-pasting the same snippets of style into multiple components, and there’s no pre-compiler like Less involved, so the CSS you write can end up looking pretty brutal.
The same applies to certain things regularly done in Javascript. The answer is to make these things global resources, I suppose, but then you lose the specificity of .THIS. What would be nice is for those components that are always contained by another component to be able to inherit those styles already declared. Perhaps triggered by some sort of scoping decorator on the definitions. Then you’d need a pre-compiler and you could have nice tidy nested CSS too 😉
It wouldn’t be an agile retrospective without identifying some sort of next steps. I should know, I’m dead agile me…
So here’s some things I want to do next:
If you are a developer looking into Salesforce, don’t stop at this blog. Read some more of the blogs in the Desynit Dev Zone
Dip a toe in – pop along to one of the many developer meet-ups happening all over the world. You can find your nearest one and just turn up. There’s usually some food and drink put on too.
Take the first step – sign up for a developer edition right now, and get stuck into some of the Developer Trailhead trails
Come to one of the Forcewest User Groups and chat to other companies who have employed developers to do Salesforce
Seriously consider making Trailhead a core part of your onboarding material for new hires – both experienced and otherwise!
Our independent tech team has been servicing enterprise clients for over 15 years from our HQ in Bristol, UK. Let’s see how we can work together and get the most out of your Salesforce implementation.
