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”. 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 a lot of mistakes. The senior developer wasn’t willing to “hold my hand”, “wear kid’s gloves” or even try to teach me the right way so I could learn from my 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 **** it up”, “Eric’s an idiot”, “Don’t bother teaching him, he will forget and wander off and do his own thing”. There were a few more insults, but I’ve managed to bury them to forget. That developer said all 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 team again.
During the last couple of years, I’ve had the opportunity to be the lead on a few Sitecore projects. I have led 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 without requiring hours of guidance. If they do need more help, I always do my best to make myself available to answer questions and teach them the proper ways. However, this becomes more difficult when working with a larger team; the other developers may occasionally require my attention too. I will never leave a developer stranded and I will at least point them in the right direction. Time is finite and a lead will not always be available to give 100% of their attention to a single developer. Here are some tips to help you grow as a developer and how to be an asset to your team.
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, what are their recommendations 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 it.
Look at all the code in the solution. Before you start coding, be aware of existing code. Don’t recode something if it already exists and is reusable. Follow the naming conventions and patterns that exist. If existing View Models do not contain logic, do not start placing logic in the View Models 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.
If you are introduced to an OOP concept that is new to you such as DI, IoC or even unit testing, ask the lead or a teammate to give a quick explanation. Take some time and do additional research. In my opinion, it’s impressive to see a developer with the passion and desire to learn things they may or may not have a hand in on a regular basis.
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 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 , Unicorn or another similar product? Do research and learn everything you can, and don’t forget to ask questions.
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 C# 6 or newer? 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, unwieldy 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 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 a code review that wasn’t positive. Shocked, I picked up my jaw from the floor, composed myself and nicely explained to that developer 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.
My point is, if you want to improve as a developer or anything really, 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. 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 like 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.
I hope this post was informative and I hope you were entertained. Thank you for reading!
Do you have any tips you’d like to share? If so, please leave a comment below.
Do you enjoy my oddly themed blogs and wish you had access to even more of me and my ideas? Good news, you’re in luck!
If 140 characters is your thing, follow me on Twitter.
If you hate reading and watching Sitecore videos entertains you, head over to my YouTube channel! Sometimes I entertain, sometime I provide useful Sitecore information and sometimes I can do both in the same video.
I can also be found hanging out on the Sitecore channels on Slack, I like it, although it occasionally triggers AOL chat room flashbacks from the olden days.
You can also find me adding content on LinkedIn and on Reddit.