This past week I had the pleasure of pair programming with a new member of our team at nonlinear. I don’t say that sarcastically, as it actually was a lot of fun to bring another person into the fold, fresh off of Sitecore certification. It’s also been a while since I’ve done any pair programming, and it really lets you see how much learning we do on the job, project after project.
Instead of putting our new team member on a “make-work” project to have them get their feet wet, it was time for sink-or-swim time! As the week rolled on, we started realizing some of the gaps that Sitecore training just cannot prepare you for.
What Sitecore Developer Training does
After receiving the training, a developer should understand how to use the tool, what the terminology and basic structure is, and also how to build simple components. If you’re lucky, you may have even learned some DMS and it’s still fresh in your mind. This training is making sure you know what Sitecore is, how it works for authors, and how you should be doing basic changes to the platform.
What Sitecore Developer Training does not do
You are not ready for the real world yet. Not after training. You will not know all the best ways to do every single aspect of a Sitecore project, nor should you. The best situation you can be in after training is to come home to a team of well-seasoned veterans who can coach you the rest of the way. Sitecore training is an introduction, not an end-goal.
There are a few gaps you’ll have to jump after training to get to real world scenarios. Below are just a handful of them.
Gap #1: Deployments
DevOps best practices and architectural decisions for automating deployments are not covered in training. Hopefully, your team has somebody who knows this already, but if you’re “the one”, training won’t cover this. There are a lot of blogs (including this one) that can get you started though.
Gap #2: Edit vs Preview markup
The concept of a datasource-driven component should have been covered in training. You may have even bound some items and fields to some Sitecore web controls. In most situations, this is not what you actually do in the real world. Complex components, especially ones that have advanced presentation requirements (like carousels, accordions, tabs, etc.) cannot be edited the way they are rendered. You need to be able to understand that sometimes what you render for editing is not what you want to render for presentation. This means knowing about Page Modes (Preview, Editing, Normal, etc.) and toggling visibility of controls in the markup.
Gap #3: Custom Experience Buttons
These buttons are additions you make to the Core database so that your component can have friendly buttons for interacting with your component. Almost any component you build will have datasource fields that you should not edit in the WYSIWYG interface, so custom experience buttons allow you a way to expose these fields to the author in an easy way. Check this post by my colleague for some details.
Gap #4: Using Include patch files
This is a task that I do almost every day, but it doesn’t seem to get much attention from folks just starting into the Sitecore development world. Stop editing the Web.config file and use patch includes! This is critical to maintaining your upgrade path and ensuring you have a cleaner architecture.
Gap #5: Scaling and Hardening
This one is tough. I’ve had developers who have been doing Sitecore development for years and have never had to be involved in the actual scaling and hardening of a Sitecore instance. The guides are out there, but even understanding what it all means and why you are doing it is not necessarily obvious. If you haven’t done this before, make sure you have an experienced hand guiding you because this one is complicated…
Try it yourself
I encourage anyone out there to place a newly trained Sitecore developer on their team and work closely with them to see what other types of gaps you might see. This allows you to identify areas for onboarding materials and blog posts of your own :).