The Salesforce ecosystem is absolutely huge. In fact, it is estimated to be worth around 7.3 billion dollars by 2020, and to create 3.3 million new jobs by 2022. But one of the real beauties of this universe is the speed at which it adapts and changes, and how it is driving and defining the technology of the future.
In Third Republic’s Salesforce Q&A Series, we speak to industry leaders about what changes they have seen in the Salesforce universe, where they think it is heading, and what this means for those working in the ecosystem today.
Recently, we caught up with Kane Holbrook an experienced Salesforce Developer. Kane explained to us how his career in Salesforce began and reveals his top tips, tricks and insights for those looking to develop their own career within the world of Salesforce.
Third Republic (TR): Let’s start from the beginning, how did you kick-start your career in Salesforce?
Kane Holbrook (KH): After finishing my A-levels, I set myself the task of getting a job in development, if I failed to do so before August of that year, then I would enrol in a Computer Science degree. About three days before I hit the August deadline, I was offered an interview for a very small 3-man company who developed a .NET app around insurance.
After a year in my first position, I was headhunted by Brightgen. Whilst there, I rushed through my first four certs (ADM201 and -DEV401 were mandatory in order to pass probation). I was fortunate that Brightgen were growing quite rapidly at the time, as it meant I got an awful lot of exposure very quickly, but there was definitely a lot of pressure on the ground.
TR: How did you decide that the Developer route was right for you?
KH: A bit cliché, but I used to play a lot of video games as a kid. When I was about 11, I decided I wanted to create my own stuff, so I went on to learn to program in an awful defunct programming language called Pawn (a weird derivative of C), and the rest is history.
TR: Can you explain what a day in the life of a Salesforce Developer looks like?
KH: It depends heavily on the project, but the average day starts with a stand-up, where we discuss progress made the day before and our plan for the day ahead (e.g. what tasks/stories we’re going to be picking up, how far we expect to get with it etc.).
Depending on where we are in terms of timelines, some days I just bury my head in whatever I’m working through, but usually there’s a lot of interaction. I try to schedule a lot of face time with clients as maintaining good relations is often as important to a successful project as the actual build.
TR: What are your top pointers for others looking to become a Salesforce Developer?
1. Know what you are doing. With no disrespect intended, there are a great number of Salesforce people out there who know how to mangle a pre-written piece of code to do what they want. Whilst this certainly sets you apart from your garden-variety admin, it unfortunately does not make you a full developer. There is a big leap from adjusting someone else’s code to starting with a blank canvas and writing something new.
2. Clicks-not-code is important – usually. It’s very easy as a developer to see code as the solution to everything, but understanding the value in clicks-not-code is important. Bespoke code needs to be maintained (or it needs to have a resource permanently on hand to maintain it, just in case) it can often, but not always, be more costly than doing things declaratively. It will never be as robust and as well-tested as the declarative tools Salesforce have made available to us, (which are tested by tens of millions of users every day) and ultimately it defeats the purpose.
HOWEVER, there are also times where, whilst you could daisy-chain a bunch of processes, it becomes more complex and difficult to understand than simply writing a simple block of code – there is always a balance.
Finally what works for one client does not work for all clients. If, for example, you are working for a business with a strong development team, then I would lean more towards code than declarative development – it’ll be easier for their team to change a constant in Apex than to learn about custom labels, and how they are referenced in Visualforce, etc.
3. Apex development is not forgiving. It is often like trying to fight off a particularly upset grizzly bear with one hand tied behind your back whilst in a dark cave surrounded by razor-sharp stalagmites doused in really upset fire ants.
There are a myriad of frustrating little quirks with Apex – least of all bulkification. The tools for development tend to be exceptionally clunky, (things have gotten better recently) and don’t even get me started on how awful deployment/migration can be. There’s also a set of limits which, depending on what you are doing, either you’ll never come close to hitting, or you’ll find yourself daisy-chaining queue-able jobs in order to complete otherwise simple tasks, like extracting the content from a DOCX.
On the plus side, depending on what type of person you are, the challenge of taking on a language that doesn’t hold your hand in the same way that other modern languages do, can be very rewarding. Also thanks to how challenging it is, it keeps the marketplace competitive and it keeps our day rates up.
TR: How can others looking to become a Salesforce Developer stand out from the crowd?
KH: Have a handful of projects that you are willing to talk about in-detail, and be able to demonstrate a prowess for taking a technical problem and coming up with an elegant technical solution. Oftentimes, interviewers are as interested in hearing about how or why you came to a particular solution (vs other alternatives), as they are in the actual solution.
TR: Do you think Salesforce certifications are a good way to continue developing?
KH: Initially yes, but I think they become much less important as you gain experience and have an array of projects under your belt. If the marketplace became a lot more competitive, I might consider investing some time in accumulating a suite of new certs. Right now there are more projects than people and I don’t think I’ve ever been declined an interview (after which certs are practically meaningless) on the basis of not having a particular certification.
TR: Do you think soft skills are secondary to technical skills in order to succeed in a developer role?
KH: No not really, soft skills are important and can give you a great leg up, but ultimately nobody is expecting a social butterfly when they hire a developer. It’s considered a nice-to-have if you can maintain an appropriate level of eye contact over the course of a conversation.
TR: How has the Salesforce world changed during your time in it?
KH: It’s been flooded with partners who don’t know what they are doing – and the giants of old can no longer be relied on to provide quality output.
It’s a great market for contractors, I think.
TR: What emerging trends are you most excited about, and why?
KH: AI is becoming more prominent within Salesforce. I’ve used some form of it in three of my last four projects; ranging from sentiment analysis of statements made by members of parliament in the Commons, to flagging and detecting potentially fraudulent grant applications.
TR: What advice do you have for professionals wanting to ensure they can keep up in this ever-evolving ecosystem?
KH: Get involved in a diverse array of projects and don’t get pigeonholed into one specific type.
TR: Do you have any other advice for those starting their journey as a Salesforce Developer?
KH: Trailhead is a great place to learn but it can be a little abstract. Brightgen offer (or at least used to offer) an excellent grad scheme, as does a variety of other partners nowadays.
