Vamsi Krishna, renowned MVP for Salesforce, is an influential voice within the Salesforce Community, and is a prominent specialist within the Developer space in particular.
Now owning his own Salesforce Development Practice, Techforce Services, and leading the Sydney Salesforce Developers Group, Vamsi holds valuable insight into which skills will be key for an up and coming Salesforce Developer to be competitive and successful in the coming years. We were interested in Vamsi’s own journey into the Salesforce space, and the evolution of the Salesforce Developer role.
Ben: What was your background prior to Salesforce and how did you make that transition?
Vamsi: I was primarily a Microsoft .Net specialist, since I graduated in 2001. I moved to Sydney in 2010, where I worked in .Net, including at one organization where they implemented Salesforce, and they moved me from .Net to Salesforce ‘one fine day’. That’s how it started, and I learned largely through self-learning.
Ben: Were you the only Salesforce Developer in the organisation at the time?
Vamsi: Yes, they moved me from .Net to Salesforce when the partner was close to finishing up the implementation, and after learning it myself, I was supporting the system. This is when I started engaging myself in the Salesforce Community. I was seeking some support, a place where I could learn and share my understanding. That’s how my involvement in the Salesforce Community started.
Ben: There was no Trailhead at that time, how did you learn?
Vamsi: Mainly through going to the Salesforce Developer forums, by using Stack Exchange, and the Success Community. I regularly attended the Salesforce Developer Group in Sydney, which I actually run now, but back then I was going every month and found it very useful. I started monitoring the questions that people were asking in the online forums, and I started consolidating the answers.
I found that most of the threads followed a pattern, and people were repeatedly asking questions around certain areas of Salesforce. It’s easy for you to filter by topic in the Stack Exchange or the Developer forum. You can see what people are talking about, what the complexities seem to be, and how people are solving similar issues. That gives you a better understanding, and insight into how others are finding solutions that could benefit you. That was my introduction to the Salesforce Community. After a while, I started answering questions within the online forums, rather than simply asking.
Ben: Was this because you gained the confidence to feel that you knew enough to start sharing?
Vamsi: Yes, that was the turning point; rather than being a silent observer or just asking questions, I started answering them. I found it to be more engaging, and that I could learn even more by actually answering questions. The Salesforce Success Community and Stack Exchange were the two primary places where I was visible online. I was regularly attending the Developer Group, and then I started presenting in the Developer Group. That’s where my engagement increased with the Salesforce Community.
Ben: How did you find that transition from .Net? Do you think .Net and Java are good platforms to transition to Salesforce from in your opinion?
Vamsi: .Net is object orientated as well. .Net is a framework, it’s a platform, and C# is one of the languages that I was using. There are a lot of other languages that you can use in .Net, but my experience was primarily in C# .Net, and that was okay to transition into Apex. I’d say that Java is even more aligned with Apex.
Ben: So in your opinion, can a Developer coming from other technologies learn Salesforce quickly?
Vamsi: In terms of coding, yes, but in terms of understanding the platform, that’s where they struggle, and that’s where they spend more time. With .Net and Java you run things in your own environment. With Salesforce, you run the code in the Salesforce platform. Salesforce defines a set of guidelines; governor limits is just one of them. There are other things, like when do you need to write code, when can you skip writing code? Not every single requirement or problem in Salesforce can be solved with code, or should be. You need to be able to evaluate when to use which type of automation. Coding is just one type of solution in Salesforce, whereas as a .Net specialist, it’s always code. There’s nothing else and so you just start with code. With Salesforce, it’s going back and checking, “can this be done with workflows”? “Can this be done with process or visual flows”, or anything else? You need to always keep monitoring the release notes. Every release introduces a lot of functionalities, that can make your code redundant.
Ben: Should a Developer be aware of release notes too?
Vamsi: Yes, if you’re in a Senior Developer role, and planning to get into that Architecture space, then you definitely need to be on top of the new releases. And if you’re the only Developer in the company, then you definitely need to do this because you carry that responsibility.
Ben: When you see bad code, is that usually down to people rushing and cutting corners, or is it because people ultimately just don’t have the capability or knowledge?
Vamsi: It’s both. Tight deadlines, and people don’t write Test Classes until it is going into UAT. They will be finishing the development work, and when it goes into UAT when the Testing team picks it up, that’s when the developers find time to write the Test Classes. Which is wrong, the Test Classes should go in parallel with your actual Classes. That way, you have more time to spend testing the functionalities themselves.
The other situation is people not understanding the Test framework in Salesforce. It’s a bit different compared to the other platforms when you start writing Test Classes in Java or .Net. Inside Salesforce you have to cover so many other functionalities, and there are so many other dependencies, and so your Test Classes can fail, not just because of your code. It could be because of a validation rule, or a process builder, or anything else that you’re not even aware of.
You have to understand the end to end business process, and then your Test Classes should cover that scenario, not just your code.
Ben: What is best practice?
Vamsi: We constantly do peer reviews within my own consultancy, Techforce. When one person is writing something, the other person comes in and reviews the code. We are all across what others in the team are working on, it’s a combined effort. That’s probably what every Salesforce Development team should practice. It’s like having someone on back up because even if someone is on leave, someone else can pick up the code and continue. It helps in reviewing the code, and it increases the team’s learning of what each other is working on.
Even though they are not involved full-time on the project, someone can understand what the project is, and they can understand different domains within Salesforce, not just what they are working on. If you have the bandwidth, this a good model.
Ben: How would you say the Salesforce Developer role has evolved since you’ve been working in this space, in terms of language and expectation?
Vamsi: It goes back to what type of development you’re doing. So, if it’s purely the process automation side of things, you work in the back end which is primarily Apex. That hasn’t changed much. The Apex compiler has changed over the period, there are a lot of new functionalities coming up in Apex, but the language itself is the same. There hasn’t been much change in Apex in that regard, but if you’re doing the front end side of things there’s have been some changes.
There’s been a big shift from the server side Visualforce, to client side Lightning. People have been required to learn the web development side of things. So, if you’ve moved from a web development background, then it’s fine, but if you’re talking about an enterprise developer using Java or .Net without much front end, then they may struggle with Lightning.
Ben: Do the web developers struggle with Apex?
Vamsi: If they haven’t done any back end programming at all, if you’re a pure CSS HTML5 front end specialist, then Apex could be a challenge.
Ben: We are hearing more and more about the front end, funky technologies. Do you now have to be a more rounded developer to be classed as a Senior Developer?
Vamsi: Previously I was using ASP .Net, which was doing the front end and C# .Net in the back end, and I was writing SQL queries for the database. It was kind of front end, middleware and then the back end. I was a complete, what they call, full stack developer. With people who have good experience doing full stack, they will find end to end development in Salesforce is very manageable. But if you are only front end, or you specialize in middleware services, or you’re a database programmer, then Salesforce is like a platform which combines all three. You cannot be tied to just front end, back end, or middleware. You have to do everything in Salesforce.
Ben: Do you think we’ll soon see Full Stack Salesforce Developers as a role or job title and people who just do front and back end?
Vamsi: With Salesforce you don’t realise that you’re actually already doing full stack. Because there is no separate database, no separate middleware, no separate front end. You cannot have a Developer who does Lightning or Visualforce, and have a separate Developer doing Apex. You have to have one person doing both, because it goes together. When you write Apex you obviously do the database interaction using SOQL queries. You cannot have a separate SOQL Programmer in Salesforce.
Ben: What would be your piece of advice for a client looking to hire their first Developer where there isn’t a Salesforce resource team already in place?
Vamsi: I’d advise seeking people who can adapt to the platform and self learn. When I say adapt, there are so many things happening in the Salesforce platform, that people need to be committed to continuous learning, and they need to be self-learners. Salesforce has three major releases a year which means new functionalities in terms of development and API’s etc. Your Developer needs to be across all of these.
So, anyone looking for a Developer, should primarily look for someone who can learn themselves so that they can develop into that next stage and push themselves outside of their comfort zone. Within Salesforce things are changing rapidly, with Einstein AI for example. They’re opening up Einstein APIs. If you’re not scaling yourself into those new territories then you are missing out.
As a hiring manager, you want to avoid finding silos of Developers who are specialists within certain areas. You want people who have the ability to move into UI work, or whenever there is an API project, move into that. Essentially flexibility.
I’ve been in the I.T industry for almost 15 years now, not just with Salesforce, but with Microsoft technologies. We always face these sort of issues, the technology, the language, in that what was valid a few years ago, isn’t valid now. So even if it was right before, when you look at the implementation now, you’ll feel it could have been done in a different way, because the platform has changed a lot. That’s why if you’re an internal Developer working in a company, you should always keep learning the new releases.
Also, when you find time, you should ideally go back and revise your previous work, and do, what we call refactoring. This is best practice, both for your own learning, and for the organisation itself. Of course, not every company will have the bandwidth to keep reworking. However, you just need to find time between your projects, as a continuous side project.
Ben: With all the evolution of the platform, what does the Salesforce Developer role look like in three year’s time?
Vamsi: It depends on what level of Development. Knowing one thing is fine to start with, but when you’re getting into that mid level, you should be able to scale into all the domains inside Salesforce.
If you’re getting into that Architecture space, going beyond Mid to Senior Developer, and into Architecture, it’s an understanding all of the different clouds within Salesforce. How each one talks to each other, and how they work together as a platform. Probably in the next two to three years, all of these individual clouds will be evolving. There are so many new things happening inside the platform, and in terms of development, the UI and API layers are evolving. It’s the full stack development we’re looking towards, where you’re not just focusing on one thing. You should be able to cover the full stack basically to make yourself competitive in the market for the next two to three years.
Ben: The Developer Group that you run is primarily for Developers, but who else might be welcome to that Group, and what might people typically get out of it?
Vamsi: Salesforce development is not just about writing code. It’s about understanding the platform end to end, and doing a lot of things the platform is capable of. Likewise, the Developer Group is not just for developers. People also think that the TrailheaDX conference it exclusively a Developer conference, but it’s not just for Developers. It’s for anyone who’s engaging in the platform, or customising it for customers. If you’re not a User, you could be on the customising side. You could be an Admin, a Functional Consultant, a Developer, or an Architect. You can make use of the Developer Group because we talk about all of the facets. It’s relevant to anyone who is customising the platform. They are definitely more than welcome to join the Developer Group.
We talk about different products, and different technologies that we can use, and we also talk about Heroku. It’s not just Salesforce, we cover Heroku as well. Therefore, if you have a Heroku background, you would also find Salesforce Developer Group very useful.