I've been working on CMS projects for over a decade and over that time I've worked with some bad developers, some good developers and a handful of rockstars. When I first started my career, I thought that being a rockstar developer was just some magic ability that some developers were simply born with. After reading a book called Bounce, a book that explains that if you’ve ever wondered what makes a champion, that success is less having some special genetic super-power and more practice. Since then I started looking into ways of learning and practicing and the difference between my career from then and now is extremely different. At the beginning of my career, I wasn't really that good, however, even 4 years after reading Bounce I started to get a reputation in the companies I worked with about being the go-to guy to help fix issues, or, get answers to things.
In that time I didn't get sudden super-powers, however, I started practicing and following a few simple rules that really helped me progress in my career. In today's post, I'll share a few of those tips with you, so read on if you want some potential helpful career tips.
First, there are no shortcuts to being really good building Umbraco websites. Unfortunately, the only way from my experience is better, consistent hard work focused in the right direction. Granted, it’s simple, it’s cliché but it works. From my own experience, when I just turned up to work and did the bare minimum to get by, I did a very average job. Malcolm Gladwell wrote a great article called 'Outliers'. The main principle is that it takes 10,000 hours of practice to be great at something.
Say an average job requires a programmer to show up for 40 hours per week. Almost everyone wastes at least half of those 40 hours, sometimes more. None of us work 40 hours of good solid deep work, we all check emails, go for lunch, meetings, constant interrupts. In reality, we all only probably do 15-20 hours of good solid deep work per week. At that rate, it will take you about 10 years to become an expert.
Putting in your hours isn't enough, you also need to focus your attention correctly at that time. A painter and decorator might spend his whole day with a paintbrush, but he's never going to be the next Michelangelo.
When I say you need to put in the hours, I'm not saying you need to become a workaholic. Simply turning up at 8 am at your job and then leaving at 8 pm probably won't get you any further than turning up during normal working hours.
The thing that will get you ahead, is spending time on deliberate practice. When I started writing articles for this website, I forced myself to read new things, to experiment with different ways of working and to try out new languages and patterns. On average I probably spend 7 hours + on this site and I've done that for 5 years. Speaking from experience, it's these hours that have been my money in the bank hours. Anyone who worked with me in the first 3-4 years of my career compared to the later years would all say that my knowledge and attribute at work changed dramatically. None of those things came easy for me, they all came with a constant focus on practicing on new things.
Now, if you make a commitment to yourself to spend 7 un-interrupted hours to focus on learning new things and trying out new ways of working. After a year, you'll have spent 364 hours dedicated to getting better. Based on the amount of work we actually do, that amounts to nearly a third more effort than the people you work with. If you need some help how to do this, I suggest you commit yourself to 30 things in a 30-day challenge. Each day, commit yourself to writing a one hour project, that uses a different aspect of Umbraco. Day 1 is usually helpful to build a base Umbraco build. Day two you add in a feature like multi-language and you add that in. Rinse and repeat. I know it does not rocket science advise, but it works.
As a contractor, I end up working with numerous people and teams. One thing which is really obvious is that the most valuable engineers at each client's site are the guys who know the code base inside and out.When someone needs an idea how to fix something, how to quote for a new feature etc.. they'll go to that guy. Whenever I start anywhere I always make sure I fully understand the code-base, try to understand why things were written in that way, what's the limitations of changing it.
It takes 3-6 months for a new engineer to become productive. Learning coding practices, architecture, developer tools, and deployment practices is time-consuming.
To become a rockstar Umbraco developer, you need to know Umbraco well. My advice here is to go to my Umbraco Developers Guide page. In here, I've broken all the different aspects of Umbraco down into sub-guides. At a minimum, you need to get a good understanding of all these areas. You might not want to use my tutorials to learn about each sub-topic, but I'd recommend you start with that list as your starting guide of topics to learn. When you know more about those topics than your co-worker, you'll be the go-to Umbraco guy.
Most developers focus on say learning Umbraco, might start outputting the hours in focusing on learning cool things, but, there will come a point when you know a lot. When you reach that point, instead of thinking you know it all (if you ever think of yourself as an expert in anything, that will stop you learning new things), my advise is to learn a different CMS. Sitecore works very differently than Umbraco. I'm definitely more of an Umbraco fan, but, learning Sitecore, or, EPiserver will force you to design a site in new ways that you never would if you only know Umbraco. I've worked on 10 different CMS systems over the years. Through all that experience it's helped me to become a better website architect.
If you are completely new to CMS then don't worry about focusing on this too much at the beginning, however, when you reach that point of competency, start using a different platform to help you learn more.
One of my biggest personal demons for not learning something is that I just don't have an idea for something to build. If you have a side-huddle idea, you want to create a personal website to help build your brand etc.. then this is your opportunity to use a different language.
If you're building a website for someone, even though you're a developer, spend time understanding why you're building the site. I spoke to a recent director of operations and his advice was for all developers to become project managers for 6 months, just so they could understand the pressures of the business, the money issues, the people issues etc.. At the end of the day, any website project you'll ever build is generally to help a company ultimately make money. If you can learn how the website fits into the company's strategy to make money, you'll be more capable of coming up with ideas that your bosses will like.
If you think you're simply a developer and that it's someone else's job to figure that stuff out, then you've just found a limiting belief in yourself that will stop you getting promoted at some stage. The more senior and the more rockstar you are is coming from an understanding of how you fit into the money-making pipeline. If you are unsure about how to get started here, an easy one is to just email your boss, or, your bosses boss and take him out to lunch and ask. Some of the best business insights I've gained about companies have come this way. Granted it feels a little bit tired and uncomfortable the first time you do it, but, if you persevere it will help your career.
When I graduated, the first company I worked for forced me to work in the support team for 8 months. The reason was they wanted to develop analytical problem-solving skills in junior developers. In the support team, I was responsible for figuring out what went wrong. 90% of the time it was up to me to figure it out. After months of doing this, it helped me adopt a mindset of figuring stuff out on my own.
All of the average developers I've ever worked with all seem to have this same trait. As soon as they get an issue, they ask someone else to fix it for themselves. All the rockstar developers, will happily go and figure it for themselves.
Granted there's a fine line here. If you don't have the correct server details, you need to know something about a system that you have zero knowledge, then instead of wasting time, it's better to ask someone who has some knowledge with the issue. For the normal day-to-day troubleshooting issue, figure it out yourself. You're never going to be the go-to person if you spend the whole time asking someone else to fix things for you.
To get considered good at debugging, after you fix something, people should ask you, how in the world did you figure that out?
Learning how to debug well isn't easy. Some debugging boils down to experience but a lot of it is simply being able to come up with a plan of attack and systematically following through on it. Another common issue I see with developers who want to learn Umbraco is that they'll spend hours and hours banging their heads against a wall trying the same thing over and over, sometimes knowing when things aren't going according to plan and trying something different is the best action.
You'll never be considered a rockstar developer at work if you're constantly missing deadlines and not getting projects done on time. Naturally, I think most people are pessimistic by nature, how many times have you heard say 'it's a 5-minute job'. At work, it is always better to overestimate and then over-deliver. IF you say something, like be done in 1 week and then 2 weeks later the task is still outstanding, you're the one you'll look like an idiot. If you said the work was going to take two weeks and you did it in 8 days, people will be happy.
My advice to managing expectations is to always try and break all tasks into as tiny chunks as possible. If you're doing estimates on 1 day tasks, the likelihood of you getting an estimate really wrong is massively reduced.
Sometimes, things do take longer than planned. When you find yourself in this situation, you need to flag it to the team
Over the years I always seem to end up working on the shit tasks that no one wants to take on. These are usually the ones that people think might be impossible, extremely difficult, or there's no documentation around it.
If you read a lot of articles on this site, you can find out, as some of the things I've written about no one else has. When you do sprint planning, if you always take the hardest tasks, you'll be forced to go through API's with a fine-tooth pick, you'll be forced to use your brain to try and figure out how to fix things and you'll get a lot better experience than simply doing the easy tasks. As I mentioned in point 1, you need to put in your time in and work on things that will push your comfort levels... the impossible tasks will do just that.
Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge