"Dang it, Carl" - Tips to Avoid Being the Least Favorite Character on Your Sitecore Project

Wednesday, March 22, 2017 @ 02:30

By: Eric Stafford, Sitecore Developer – Carl Grimes, a character from the TV show "The Walking Dead", has to be everyone's least favorite. He is always wandering off doing his own thing and consistently endangering himself and others in the group. Attempting to keep Carl from being "Carl", his father gives him busy work like babysitting his sister. Carl is a teenager and his actions and mistakes reflect that. He requires a lot of handholding and supervision and it takes energy away from the more important tasks. At some point in all our careers, we've probably worked on a project with a "Carl". Maybe you are the "Carl" on a project. Don't be Carl.

Truth be told; I was once a "Carl". Back in August of 2006, fresh out of college, I joined an advertising agency that had a small web department. They focused on the Microsoft stack of technologies: .net, C#, SQL Server, etc. In college, I took two C# classes and very few other object oriented programming classes, so I lacked a lot of experience.

While I was learning C#, the Agency assigned me an additional responsibility of front-end development and shortly thereafter, I became a Sitecore developer. I had a lot on my plate and I made lots and lots of mistakes. Lots of them. Oh, God. The number is unfathomable. The senior developer wasn't willing to "hold my hand", "wear kid's gloves" or to even try and teach me the right way, so that I could learn from my many mistakes.

As the team grew, the senior developer was not shy about telling these new developers: "Don't let Eric do it, he will just <expletive deleted> it up", "Eric's an idiot", "Don't bother teaching him, he will just forget and wander off and do his own thing". There were a few more insults, but I've managed to bury them deep inside my mind. That developer said all of this in front of me and, as hurtful as his words were, he did me a huge favor. His words motivated me to work insanely hard so I would never be the "Carl" on any project or any team ever again.

During the last couple of years, I've had the opportunity to be the lead on a few Sitecore projects. I have lead as little as two developers and as many as five. Nothing is better than being able to give a developer instructions and have them produce results without them needing their hand held through every step. I always make myself available to answer questions and teach them the proper ways, but when working with a larger team, the other developers may occasionally need attention too. Time is finite and a lead will not always be available to help. Here are some tips that I can offer to help you grow as a developer.

Ask questions, don’t wander off and do your own thing

The project lead is there for a reason. That lead should be more than willing to help you grow as a developer. You should be able to ask them what are their expectations and what their recommendations are for a task. Confused as to why something is set up the way it is? Ask. When you run into issues and you are not sure what the best, cleanest solution to a given task is. ASK. If the lead is busy, ask a senior developer or one of the other developers working on the project. Also, you may want to search the code to see if your issue has already been resolved, which leads me to my next tip.

Be aware of your surroundings

When coming onto a project, time and budgets are always limited. You will be assigned tasks and you will be expected to produce results almost immediately. However, whether it's done on the clock or off hours, take the time to familiarize yourself with the solution and the Sitecore architecture.

In Sitecore, be aware of all the customizations your team has done. Look at the templates and their fields, look at the template's standard values insert options and any renderings that are assigned. Check out the items in Layouts. Look at the renderings that have been created. Take note of how everything is structured and pay attention to the naming conventions and follow them. In my opinion, everything you create or modify in Sitecore should look uniform and as if one developer has been working on all of it.

Look at all the code in the solution. Before you start coding, be aware of the existing code. Don't recode something if it already exists and is reusable. Follow the naming conventions and patterns that already exist. If existing View Models do not contain logic, do not start placing logic in the View Models that you create. Every developer has their own coding style, but ideally you should try to at least mimic what is there within reason. Hopefully the lead and the other developers chose to follow .net standards.

Know your tools

Sitecore has some very useful utilities which I will be covering in a future blog post. Some of the utilities are StringUtil, MainUtil, ItemUtil and WebUtil. I use a lot of these utilities daily. To learn more of what is contained in the Sitecore.Kernel, download dotPeek, JetBrain's free .net decompiler. Use dotPeek to explore Sitecore and the other assemblies. You may find a lot of cool things you may not have been aware of and, at the very least, you may learn something new.

Is the project using Team Development for Sitecore? If so, stop! Talk to the lead and suggest switching to Unicorn. Hahaha… I'm joking(?). Seriously though, whether you are using TDS, Unicorn or another similar product, do your research and learn the proper way of to use it.

Using an ORM such as Glass Mapper? Read the tutorials, use dotPeek and explore Glass's assemblies and discover how it all works. Also, be aware of issues such as Editable and its inability to function in the Experience Editor when it's surrounded by "P" tags. One possible solution:

Using an ORM such as Glass Mapper? Read the tutorials, use dotPeek and explore Glass's assemblies and discover how it all works. Also, be aware of issues such as Editable and its inability to function in the Experience Editor when it's surrounded by "P" tags. One possible solution:

Is the project using the relatively new C# 6? If so, learn more about it's awesome new features such as the Null-Conditional Operator, Auto-Property Initializers, Expression Bodied Functions and Properties, etc. What developer wouldn't want to simplify, clarify and condense their code?

Resharper is hands down a developer's best friend. Purchase JetBrain's Resharper, even better, Resharper Ultimate. I cannot stress how awesome and useful this tool is. Resharper makes it difficult for a developer to produce bad, unwieldly code. Plus, it's a great learning tool.

Source Control is there to Protect You

After ten years, it still shocks me when developers refuse to use source control, use it infrequently, or use it incorrectly. Whether the project is using Git, SVN or TFS, it's super important that you learn how to use it correctly.

Make frequent, small commits with useful, descriptive comments. Avoid waiting till 4:55PM to commit all your code. Sadly, I am often guilty of doing just that. I get so caught up in coding and meetings that it slips my mind. I usually end up committing dozens and sometimes hundreds of files with a vague comment like "Some codez for modules and other stuffs… Oh! And a LOT of TDS files.". Apologies to my teammates. I'm improving this.

Debugging and Google are your Friends

So you made all your code and built your solution without issue. You try to load the site and the site blows up. Sigh, errors happen. Sometimes the error messages can actually be useful. You quickly track down and fix the issue all by yourself and life is good. Other times, error messages can be extremely vague. Before you run to the lead for help, debug the code! If you're new to debugging, you can learn more here.

After you gave debugging a shot and you are still stuck, Google. Please Google. Google is your friend. What do you think the lead often does when a developer comes to them with a question about an error? They use Google… or Bing if they want to waste time (joke).

Put in Extra Hours

Some time ago, I had a very junior developer tell me "I shouldn't have to put in extra hours to learn if I don't get paid for it". That comment came after the junior developer had a code review that wasn't positive. Shocked, I picked up my jaw from the floor, composed myself and nicely explained what the issue was and how I would have approached their task. The developer argued: "How am I supposed to know, I've only been doing this for x months". I totally agreed with them. The solution to their issue came from experience and I let the developer know that everything was fine. I understand they are inexperienced and I was once in their position. Surprisingly, they continued to needlessly argue and defend themselves to me.

Anyway, my point is, if you want to improve as a developer or anything really, you have to put in the extra time. Read blogs. Review old code and figure out ways to improve it. Decompile assemblies for Sitecore, Glass or whatever the product is and figure out how they work. Discover hidden tools that could help accomplish a task without the need for more code.

My bad experience during the first few months as a developer drove me to put in at least 60 hours a week. Ten years later, I still put in those hours, but more effectively. After all these years, a lot of Sitecore stuff has become routine and I get bored easily. I've used those extra hours for learning… now I need to use those hours to blog more and help others in the Sitecore Community.

If I could, I would thank my first senior developer for embarrassing me the way he did. If he had been a caring professional and properly helped me, I probably wouldn't have this work ethic and I wouldn't be the developer I am today.

If you haven't followed me on Twitter yet, why not? Follow me @SitecoreEric