I've been working on CMS projects for over a decade. Over that period 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 people had. Some people seem to answer questions and solve problems much easier than others, surely they were born this way? After reading a book called Bounce my thinking changed.
If you have ever wondered what makes a champion, this book covers it. It talks about practice. Success is less about having some special genetic super-power and more about practice. After reading Bounce, I started looking into ways of learning and practising how to improve my coding abilities. The difference between my career from then and now is extremely different. At the beginning of my career, I wasn't really that good. About 4 years after reading Bounce and implementing deliberate practice, I started to get a reputation with as the go-to guy to help fix issues, or, get answers to things. During those 4 years, I didn't get sudden superpowers or become more clever. I started practising 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 if you want some practical tips to help you level up your coding skillz then read on!
Put in your freaking hours
First, there are no shortcuts to being a really good Umbraco website builder. Unfortunately, the only way from my experience to become better is consistent hard work focused correctly. 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 book called Outliers. The main principle of the book 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, on talking, meetings, procrastination, etc... Out of those 40 hours, hardly anyone spends the whole time focused on good solid deep work. 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. A painter and decorator might spend his whole day with a paintbrush, however, 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 in terms of mastery.
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 in terms of mastering technology or a programming language. 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. Nothing I have mastered came easy. Everything has come with a constant focus on practice.
If you make a commitment to yourself to spend 7 uninterrupted hours focused 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 will be putting in to get better. If you need some inspiration on how to get started, I suggest you commit yourself to 30 things in a 30-day challenge. Each day, commit yourself to code on something new, that uses a different aspect of Umbraco everyday. 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 is not rocket science advice, however, it works.
As a contractor, I work with numerous people and teams. Out of this chop and change career, one observation that I have made, is that the most valuable engineers are the guys who know the codebase inside and out. When someone needs an idea of how to fix something, how to quote for a new feature etc.. they'll go to that guy. Whenever I start a new role, I make sure I fully understand the code-base, understanding why things were written in that way, and what's the limitations of changing it.
It takes 3-6 months for a new engineer to become productive in a new role. Learning coding practices, architecture, developer tools, and deployment practices is time-consuming. To become a rockstar Umbraco developer, you need to know Umbraco well. If you want a starting point, my The Ultimate Guide To Umbraco is a good resource. I've broken all the different aspects of Umbraco down into sub-guides on this page for v7 and this page for V8. At a minimum, you need to have basic knowledge of each topic. You might not want to use my tutorials to learn about each sub-topic, however, this will give you a good starting list! When you know more about those topics than your co-worker, you'll be the go-to Umbraco guy 💥💥💥
Get outside your area of expertise.
When learning Umbraco, there will come a point in time when you think 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 from learning new things), my advice is to learn a different CMS. Sitecore works very differently than Umbraco. I'm definitely more of a Umbraco fan, however, learning how Sitecore, or, Episerver will force you to design a site in new ways. This knowledge will then further increase your Umbraco skills. You will have different tools and ways of approaching problems, compared to the developers who solely focus on Umbraco. I've worked on 10 different CMS systems over the years. It's knowing a range of different systems that helped me to become a more rounded website architect. If you are completely new to CMS, don't worry about focusing on this. When you reach a point of competency in Umbraco, start thinking about using a different platform to help you learn more.
This also applies to things like CSS, Javascript, Ruby etc... After a certain level of competency, you'll find minimal gains by focusing on the same area. You can get much bigger knowledge gains and become a lot more of a valuable Umbraco developer if you master many things. Learning something completely new is tough. Having to find and put in additional time before or after work, to learn something and doing it all for FREE is a tall ask. This is why so many people don't do this. This is why being a rockstar is dependent on your commitment!
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-hustle idea, you want to create a personal website to help build your brand etc.. then this is your opportunity to learn something new. The more you can push your learning boundaries the stronger a developer you will become!
Know The Business
If you're building a website for someone, even though you're a developer, spend time understanding why you're building the site. I recently spoke to a director of operations and he advised me to become a project manager for 6 months. The reason was to see the project in a different way. To understand the pressures of the business, the money issues, the people issues etc... At the end of the day, if someone is willing to pay you to build a website for them, the ultimate purpose will be to help them to make money. If you can learn how the website fits into the company's money-making strategy, you'll be more capable of coming up with ideas that your bosses will like.
If you think that you are simply a developer and that it is someone else's job to figure that stuff out, you've just found a limiting belief in yourself. This belief will likely stop you from getting promoted at some stage. The rockstar developers have an understanding of how they 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 strange and uncomfortable the first time you do it, however, if you persevere it will help your career.
Never ask for Help
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 solely my responsibility to find the root cause of an issue. The time I spent on the support desk, helped me adopt a mindset of figuring stuff out on my own.
Average developers when stuck, ask someone else to fix their problems for them. Rockstar developers, will happily go and figure it for themselves. Granted there's a fine line here. If you do not have the correct server details, or you need to know specific domain knowledge wasting time not asking for help is unproductive. In those scenarios, it is better to ask someone who has some knowledge of the project. For the normal day-to-day troubleshooting issues, figure it out yourself. You're never going to be the go-to person if you need to ask others to fix things for you (this include GIT!)
Become a Debugging Rockstar
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, however, 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 to get their idea to work. Sometimes knowing when things aren't going according to plan and trying something different is the best action.
Manage Expectations
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
Work On The Impossible Tasks
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 developers are optimistic by nature when estimating. How many times have you heard someone on the team say, 'it's a 5-minute job'. At work, it is always better to overestimate and then over-deliver. If you say something will be done in a week and then 2 weeks later the task is still outstanding, you're the one who will 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 and you'll be known as a legend 👊👊👊
My advice on estimation is to always try and break all tasks into as tiny chunks as possible. If you're doing estimates for things are the scope is one day or less, the likelihood of you getting an estimate really wrong is massively reduced. break tickets down to ensure you hit your deadlines. Sometimes, things do take longer than planned. When you find yourself in this situation, you need to flag it to the team
Work On The Impossible Tasks
Over the years I always seem to end up working on the shit tasks that no one wants to take on. These tasks are the ones that people think might be impossible, extremely difficult, or there's no documentation. These tasks have always been the ones that have helped me learn the most. They force you to learn new things, this is good. Always volunteer for the shit tasks to get better at coding! When you do sprint planning, if you always take the hardest tasks, you'll be forced to learn and you'll get a lot better experience than simply doing the easy tasks. Yoou need to put in your time and work on things that will push your comfort levels... the impossible tasks will do just that.
Happy Coding 🤘
