💃 An Admins Quest to Become a Developer🕺

Good morning, Salesforce Nerds!  Are you tired of seeing the dev team get treated like royalty?  Why do they get to ignore the dress code, make their own hours and work remotely whenever they want while everyone else is stuck in slacks and keeping their seats warm from 9 - 5?  Seems like they just throw bugs all over the place anyways, huh?  You know the old saying - if you can't beat 'em, join 'em!  But, are things really what they seem?  What can you really expect as a dev?  

Agenda for today includes

• The Birth of a Developer

• Daily Principle

• All the Memes

The birth of a developer

Let me set a scene - you've been a Salesforce Admin now for a few years.  You're crushing user stories, QA loves you and your lead has no issues sending  you complex requests from the business.  Maybe you've even got plans to cert up w/ PDI any of the other dev certs.  You start eyeing postings for dev positions.  The job reqs seems manageable so you think why not?  SalesforceChaCha supports you!  You got this!  We also want you to be informed.  What should you expect when you make the transition?

Coding | I mean, duh.  You knew this already.  But I had to put it here.  You're going to be expected to be proficient here.  Since you're just breaking into development you don't need to worry about understanding Design Patterns or Application Architecture.  But, you do need to command a solid understanding of both Apex & LWC.  Some Visualforce wouldn't hurt either. Be sure you know how to handle triggers elegantly, wire a controller method to an LWC, and know how to work within Apex Governor Limits.

Testing/Debugging | This is the least sexy part of the job.  Nothing sucks more than having to spend 3 hours debugging a test result that you didn't expect.  Now you're not gonna finish in time to grab that user story you really wanted to work on and Brad will get it again! It's always Brad! 😡 Become a dev for long enough and this will happen eventually.  So, your best bet is to anticipate it.  At every phase in your development lifecycle - estimating, planning, designing, coding, testing.  You're output isn't expected to be 100% bug free all of the time, but it is expected to be solid code that meets the needs of the business. So, build a good testing/debugging routine into your overall development process.  You're lead will like you better than Brad in no time!

Technical Solution Design | This one can vary depending on the team structure.  You may have an architect on staff that handles technical design for the dev team to implement.  Or you may be in a business that thinks a developer and an architect are one in the same (hint: they're not).  You may fall somewhere in the middle.  I've been in all of these positions in my career.  The takeaway is at some level, you will be expected to understand how to design a solution, how to read & implement a solution design, or actively participate in a solution design.  The days of just designing business process and workflows are over now.  You're going to be directly involved in technical architecture of the Salesforce solution.  

Integration | Business don't run a single system in a silo.  They're running multiple applications to meet the needs of their business and their clientele.  If Salesforce is amongst these then there's almost a 100% chance there will be integrations of some kind.  As a developer, you're going to be expected to be able to write code that helps facilitate these integration.  Both Inbound to & Outbound from Salesforce.  This can be extremely complex and if the wrong architectural decisions were made in the beginning you might have a total 💩-show on your hands.  Take time to understand each system, read through Salesforce's Integration Patterns & see where/how you can apply them.  Oh, and stay away from Point-to-Point integrations.  You've been warned.

Release Management | While you've probably got some experience with Change Sets as an Admin.  Maybe even a third-party tool like Gearset or Copado.  I can guarantee as a developer you're likely going to be expected to not only have a deeper understanding of  how to properly promote code & features - you're going to be responsible for managing the entire release process of one or more stories at a time.  A lot of modern teams follow an agile process, with a repo as a source of truth, and a tool like Gearset to help facilitate a CI/CD pipeline that will auto test/deploy code. If that last sentence confused and/or scared you, don't sweat it.  There's a cert for that! Best advice here, crawl - walk - run.  Get cozy with a tool like Gearset.  Understand how to manually promote code.  Move on to git, repositories, and find out what your team's branching strategy is (this is important). Then start experimenting with setting up a CI/CD pipeline.  If you don't have much git experience, it may be a mind bender for a while.  Stick with it.  When it clicks you'll feel like Neo.

Daily Principle

and now....Your Daily Memes