In this tutorial, you will learn about some useful habits you can learn that will help you to become a JavaScript legend! We all know an absolute coding legend, however, have you ever considered what personality traits these developers have mastered that allow them to be so successful at work? Creating a legendary reputation can not be built by people who work on their own, so what skills do you need to master?

First, let us define what we class as a coding legend. A coding legend is the type of person you want on your project no matter the odds. If your client's website went down at 2 o'clock in the morning and it's starting to get light, who is the one person you would want to help you? That guy (or gal) that you picked has become a coding legend. Knowing what a coding legend is, or, even personally knowing a coding legend is great, but the thing we really care about is how can you become one? In this tutorial, you will learn some good healthy habits that will help you on this quest.

I personally think coding legends are made through graft, practice and hard work. By experimenting with new ways of doing things, learning how to play nice with others and taking on new responsibilities... it is guaranteed that you will become a legend🧙👼🧜🏽🧞🦹‍♀️.

When you think of a legendary developer, if your first thought is of someone who works all night and all weekend just to ensure some software is shipped to a deadline, this thinking is wrong. A legendary developer would have had a better plan, one that contained enough time for people to finish the project and still have a life. A legendary developer might be thought of as some great wizard whos the only person who can save the company as the website crashes, this is wrong.

In reality, if a project has gotten so far out of control, that only one person knows how to fix an issue that's a massive warning sign that there is something wrong with your team's workflow. A legendary developer is not a knowledge island, they make sure the team knows everything. A legend would ensure the website did not crash in the first place. If this situation happened on a project I managed, I would want to know how the team managed to get themselves in such a shitty situation without telling anyone. No one on a failed project is a legend.

The legendary developers that I have worked with have all been able to communicate well enough to ensure that the team didn't have to work under an unrealistic plan. The important question then is what skills do you need to become a legend. Below I will list some non-intuitive ways that you can level up your reputation at work. If you find yourself weak in one area, I challenge you to learn more about that topic within the next 30 days... game on 🤟

Introduce Quality Gates

Quality tools are designed to help improve the quality of your codebase, simple. It still surprises me how many developers do not make use of these tools within their projects. With only a few hours of effort, you can install these tools and easily make a massive improvements to the quality of your codebase. Using quality tools will ensure your project is written to a high standard.

The two types of tools that I think are essential on all JavaScript projects are linters and static code analysers. Installing a range of linters in your project will ensure good quality. There are many different linters out there, for NPM based projects I recommend you check out these tools:

You should also enable a static code analyser on your project. Some good ones to check out are:

Be The Automated Test Advocate

If you do not write tests (or don't know how) you are not going to be a HERO. No matter how good you think your code is, if it has no tests, then some poor tester will heave to manually test your code. When you need to rely on someone to manually test your application, you will be limited in how fast you can ship code into production. Having tests will allow the whole team to be more efficient. Having test automation means you can ship code into production several times a day. You will never be able to do this if you need to wait for a complete system-wide manual regression. If you can automate your testing, you will be working in a team that gets more shit done quicker compared to the teams in your company that don't follow these practices.

The side-effect of writing good tests is the need for less documentation. Let us face it, if I had a choice of coding or documentation, I pick coding 😎. If your project contains lots of well written tests, these tests will explain what the code should and should not do. These tests are solid documentation that will explain what the system does.

The main reason why teams do not want to write tests is the assumption that it takes longer. Some developers may also find writing tests a bit tedious and long-winded, however, when the world is about to explode, you wouldn't hear superman complaining that he can't be arsed as its too much work 🦸

Read Documentation Rather Than Ask For Help

Nobody reads the f-ing manual any more. Let us be honest with each other, when trying to solve a problem most of us would rather find someone who knows the answer rather than read the documentation in order to find the answer ourselves. Reading the manual takes longer compared to Googling or asking on StackoverFlow for an answer to our specific problem. We are all guilty of this at some stage in our careers and that's fine.

Over the years I have noticed that the best developers tend to be the people who read the documentation. The best C# developers consistently read the MSDN documentation, the best frontend developers are constantly looking in the MDN Web Docs, the best Android developers are on the Android docs.

It is likely that the manual will not contain the exact answer to your problem, however, by reading the documentation you will gain a better understanding of how things work. That knowledge will allow you to solve the problem yourself. Reading the documentation will allow you to get more familiar with the language or framework you are working on. Solving a problem from reading the manual alone will force you into learning how things work. Legendary developers always seem to have Sherlock Holmes mind palace knowledge on the systems they use. This is because they read the documentation 📄🕵️ 📄

Quality Vs Speed

Quality and speed are usually defined as opposite things in software development. When writing code, new and junior developers often try to rush things. Newbies tend to try and crank out code without properly testing it as they feel their speed will score them brownie points. I was guilty of this when I was younger. Saying I had finished a task quicker than anyone else, felt like I was being a valuable asset, however, during this period nearly all of the code I wrote contained lots of bugs. A lot of these bugs even made it into production affecting customers. Not all of this was my fault, however, this was the consequence of rushing. Going too quick and not caring if your code works as expected makes you a chump.

Just going slowly will not guarantee good code. It is true you can write crap code slowly. Understand the specification, test it well, and take care of your edge cases. The slightly slower developers on my team that can crank out bug-free code are more valuable than developers that I can not trust.

Getting done faster is always preferred, the caveat is that the number of bugs needs to be the same when you speed things up. Old legendary developers can be quick and work to a high standard. At the start of your career focus on being slow and correct and then eventually you can become quick and correct. Understanding the requirements and making sure you are building the correct thing is also another vital step in working quickly. If you waste a week building the incorrect thing quickly, it is still wasted time.

Constant Never Ending Improvement

Technology is not like other industries as it changes so frequently. When I started coding C# and web forms used to be the big new thing, 20 years on and no one uses it anymore. Just because you have legendary Jedi master skills in ReactJS today will not make you a legend forever. Over time things change, technologies come and go. This is why legendary developers are constant works in progress. Always learning and constantly improving.

There are lots of ways to get better. Advice that I have personally given people in the past includes, reading 4 programming books every year, taking at least 1 new course a year, writing a blog post weekly, or even just committing to a 100 days of code challenge every two years.

There are lots of ways to learn, the important thing is that you find the right balance of work, learning new things and having a life. A lot of developers are happy to spend lots of their free time at the start of their careers learning, after 10 years, when kids coe along it is common to see developers starting to coast. To be legendary you constantly have the reinvent yourself and your skills.

One of the current trends is being to become a T-Shaped developer. Having an understanding of a broad range of topics and being a master of one. As your career progresses you may have to become T shaped on multiple stacks. I started off solely doing backend C# and then learning more about HTML. I now spend most of my time doing Javascript and front-end work. You need to constantly re-invent yourself to say a legend!

Understand All The Things

Knowing how to code is only half the battle, legendary developers know about all aspects of the systems they work on. Asides from the code you will also need to know:

How to ship your code into production: Releases can be hard work and stressful. If you do not know how to ship your code into production, you will never be a coding legend at your work. To master application releases, you will need to learn how to write deployment run-books, you will need to know how to communicate, you need to know the people involved, you need to understand the fragile parts of the system, you will need to know how to revert a release when things do not go as expected and how to debug live production issues quickly and efficiently. If you do not know these things and you need to rely on others to ship your code, you will never be a go-to rock star at work 🌟

Understand how the Ci/Cd pipeline works: The Ci/Cd pipeline is a part of your codebase. You need to understand how it works, and you should be able to update and fix things as needed. In many cases, you may need to know bash or Powershell. Understanding what happens when you commit code and what happens is valuable knowledge!

GIT: All legends know how to use GIT from the command prompt. They know how to commit code without asking for help. Simple as 🔥🔥🔥

Commnication

Within a business, developers are not known as the best communicators. The legendary developers know how to bridge the gap between coders and business people. Communication is the key to succeeding in any profession. To get to the top, or be a legend you need to know how to talk to people and share ideas. The more influential you can be the more impact you can have.

Perform code review: As part of the development communication responsibilities is knowing how to perform a good code review. Performing good code reviews requires skill. Code reviews are not there for you to show off how much you know. You should also not force someone into writing code just because their personal preferences might be different to yours. Legendary developers can review code and do so without hurting feelings. The tone of your reviews should be polite and inquisitive, not stroppy and negative.

Documentation Legendary developers constantly updated the documentation, help write architecture diagrams and in general ensure that they spread their knowledge around the team. Some developers like to become a knowledge island. Hoarding knowledge to make them seem important. These developers seldom seem to rise far in an organisation from my experience. The developers who can communicate and share ideas are the ones who get promoted and put in positions of power. The next time you notice that your project is missing a REDME.MD file, be the person to write it!

Understand the ceremonies: Understand the project management process. Know how to run stand-ups, how to run a sprint pre-planning session, how to write JIRA tickets, what the sprint goal is and how many tickets need to be finished before the end of the sprint. Writing software is only half the battle. Being able to plan a project is how you can become legendary.

If you can master all these skills, show up for work each day with passion and a willingness to make sh!t happen, you are a legend. Happy Coding 🤘