A career as a developer can be a very rewarding choice, with countless options for where you want to take your expertise. I am sure you have plenty of unanswered questions, such as ‘how can I learn best practice development?’ in the absence of a mentor, ‘how do I begin learning?’, and ‘how can I future-proof my skills?’ so that you remain valuable to the industry over the next decade plus.
James Hou is a Technical Architect at Google, having worked with the Salesforce platform for a decade. I have been speaking with James back and forth about development and career advice for the last few years. I was keen to have this interview because I think others can learn so much from his advice.
From Jack-of-all Trades to Technical Architect: How James Started with Salesforce
Atlas: Can you tell us about yourself and how you got started in the Salesforce ecosystem?
James: When I got started roughly 10 years ago, I stumbled into Salesforce; I had just left a small mom-and-pop shop as a jack-of-all-trades System Admin, and found a gig with a mentor that just happened to work on the SFDC platform.
Well, it turns out that my boss left after 2 weeks (apparently I was being groomed to take over!) I self-taught my way into admin / junior developer since there was a sizable Apex and Visualforce implementation in that specific org. Having an affinity toward problem solving technology systems independently definitely helped. I grew up fiddling with technology (HTML, WordPress, Linux, home media servers) so that curiosity and persistence were beneficial.
My introduction to SFDC was on the force.com platform, meaning pure custom objects and almost no standard objects. Workflows, Triggers, VF, and Apex. That’s all the tools I had to learn myself – nothing like the crazy amount of tools there are today!
Solo Developer, No Mentor, Looking to Learn Best Practices?
Atlas: What do you recommend for people who are the solo developer in their org, or those without a mentor, looking to learn best practices on their own?
James: The single best piece of advice I can give is that you have to advocate time and space for your own learning. These dedicated periods of time must be respected by your stakeholders.
Setting timeboxes aside means you can really dig into the nitty gritty of the platform to “solution design” no matter the depth or breadth. The ecosystem now is much broader than it was when I started, so it’s next to impossible to know every single tool, and there’s an expectation that you should learn ‘on the job’.
The ideal scenario?
The most ideal is getting manager / leadership support in saying that “yes, we will give you time to figure it out” and then trying your best to meet the timebox you set for learning. This does not mean you need to be completely isolated. One of the benefits of this ecosystem specifically is the great community support (success communities, virtual user groups, discord and slack communities). Self learning also means you know where your limits are and ask the community to help expand your horizons.
The worst case scenario?
Let’s talk about worst case scenarios where you can’t (one way or another) create the time and space you need. Being completely transparent has worked for me in the past (it may not for you, but it’s worth a shot for your own sanity unless you want to change jobs which is also a completely reasonable alternative). What I mean here is putting your foot down and saying, very clearly, “I can’t deliver under these timelines, there are too many new things to learn and I need X time to figure it out. Can you give me X days? I’ll keep everyone updated”.
One of the consistent themes I’ve noticed among newer professionals in this ecosystem is that they can basically figure stuff out through historical, google-able, answers on the internet. This is a valid strategy in the Information Age! The only problem now is setting stakeholder expectations accordingly.
The big secret here is that technical skills can be acquired, but the propensity and self drive to learn by any means necessary is harder to teach.
New to Software Development? How Should You Approach Learning Key Concepts?
Do you have any suggestions for people who are very new to software development in general?
James: Great question and really difficult to give a one-size-fits-all answer. I’d probably start with asking yourself if you are technically inclined. I’m talking about do you like to figure things out by doing a lot of digging through various rabbit holes. I think that is probably a deciding factor in how you approach your “learning roadmap”.
If bootcamps are financially accessible and you have the time, I’d do my research and see which ones teach you more than just the technical skills – there is an entire framework for developing software typically called the Software Development Lifecycle (SDLC). The good bootcamps ready you for a real-life SDLC.
Before You Hit the Trailhead Trails
James worked with the Trailhead team on the Lightning Web Components Specialist Superbadge Superbadge, so I was curious to find out how he thought these Trailhead badges and Superbadges fit on this learning journey?
James: If you are new and learning software development in general I don’t think Trailhead and Superbadges apply at all.
The learning roadmap should really focus on honing your muscle memory for typing syntax and reading code (best done outside of Trailhead) and at some point, when you feel comfortable with JS, then dive into those Trailhead modules.
The LWC Superbadge was fun to work on but definitely has some nuances that are specific to SFDC. I would recommend it to boost your Lightning Web Component skills but not necessarily your generic JS skills.
The ‘Hidden’ Skills Required to Get Hired Successfully
Atlas: What is your ideal description of the job and its requirements?
James: I think a lot of skills that employers want aren’t actually listed out that well. I strongly believe my soft skills are definitely what set me apart and are a key differentiator in how I’ve come so far.
With regards to job requirements, one of the things I’ve done in the past is look for positions that are WAY outside my current level (like 3-5 years beyond), and see what kind of skills they’re looking for. That way, I can set my own expectations about how to go about acquiring those skills and eventually get to that kind of position.
One of the secrets about the SFDC ecosystem is that there are too many things to memorize, so you have to just know 50% (depth) of 50% (breadth). I think every developer is a good admin first, so you should at least learn the admin building blocks (PB, Flow, Screen Flow, Custom Metadata, Custom Settings, Flexipages, Dynamic Forms, Dynamic Actions, etc) and then reach into the programmatic side (Apex, Design Patterns, JS, LWC).
As you progress in your career, you acquire more of that breadth. Also, depending on which clouds you work on, you will know more about those as well.
Future-proofing Your Developer Skills
Atlas: What should you learn to stay relevant in the next 5-10 years?
James: Before I answer that question, I’d like to set some context. We’re at a pivotal point in technology where Machine Learning (ML) and AI are starting to get democratized. Gone are the days where you needed a data scientist and some crazy future tech/library just to even consider trying it out. Players like Salesforce have tried to bake this into the Einstein product suite and have, to some extent, succeeded and provided a ton of great value there. Google also has open sourced a ton of software that helps developers quickly get started on ML. Most of these innovations are in the consumer/web space.
I think in the next few years, the B2B and enterprise space will see the fruits of the consumer space innovations around AI and ML, making it more accessible and “normal”. What does this mean for your individual career? Well, it starts with why we are working in this ecosystem.
The goal of automation has always been to minimize the amount of time and resources required to perform a task. Incidentally, it can also generate large amounts of data. With democratized ML and an abundance of data, this means the goal post of automation has moved a bit. Before, the end-goal was to create dashboards/BI tools to surface data en-masse to make actionable, strategic decisions. Now, the end-goal takes that one step further and leverages the data itself, without human interaction.
In other words, the future goals of automation is now two parts:
- The immediate reduction of time and resources needed to perform a task (reduce clicks).
- The ability to automate any decision making when performing said task (reduce thinking/guessing).
How does this tie back into a 5-10 year roadmap? Technical skills come and go, I wouldn’t put too many eggs into one basket. Technology moves too fast to anchor on to one language/framework/tool. Getting good at learning is far more important.
Where I think you, as an individual, can make the most impact is to learn how to build systems and design automation in a way that lends itself to hitting goal #2 above. It’s not easy. It’s more than just gathering data – it’s about gathering the right data and asking the right questions so you can apply ML to answer them.
That’s it for now!
Thanks for reading and if you’re interested, you can find James and myself at our Salesforce Discord Community Exchange on Discord.