It is not always only about skills, it is also about tools. Knowing which tools to use and how to use them makes the difference between a top-notch and not-so-top-notch developer, regardless of whether she's been working in web, mobile, backend, database or whatever.
Any coding project, starting from the first byte, has to be checked into any kind of version control. It does not matter so much, which of them is your favorite as long as there is one at all.
The tools I have been actively using over the years are:
Nuget for .NET or Maven and Gradle for Java is an absolute must. It is the first step in fully automating your workflow. It frees you from gathering libraries from all over the internet and it allows your code to be built by anyone, regardless of the editor.
I've always been a Java guy (bear with me, I'm working on it), so I really only worked with Maven.
I hereby fully confess, writing unit tests always really meant trouble for me. When I learned about it, I was completely thrilled. At least for a short time. After writing some 137 unit tests for a single class it turned out that maintaining the tests was completely unrealistic. I have yet to find out, how to organize test code correctly and what to test and what NOT to test.
That "continuous" term really means that you can trigger actions upon a single mouse-click. That includes automatic testing of your code upon check-in (you still remember me talking about version control, right?) or automatic deployment of artifacts to any environment. It's called "continuous" because it means that you can do it all the time, again and again without any trouble.
Being able to set up your projects like this automatically makes you a better team-player. By putting dependencies into a Maven script and by configuring automated deployments in Jenkins you also kind of document that information in a way that others (Devs and Ops alike) can easily pick it up.
In addition to unintentionally documenting dependencies and deployments, you should take the time and do code reviews with other devs. And here's the catch: not only review their code but also let them review your code. And don't be a whiner when someone finds a way to improve your code.
I worked with Crucible.
Application Performance Monitoring
Although this is more of an Ops topic, I regularly worked in small teams that also had to keep an eye on production. For me, APM differs from plain monitoring in that it's not about monitoring CPU usage or memory, it's about monitoring the performance of your apps and services. Discovering response times and bottleneck as fast and as focused as possible really helps in keeping your environment running.
You see, the magic of a good dev is not inside her code, it's the tools that magically put code into high-quality, productive apps. At the end of the day, the real pro's the one who gets stuff done. And getting stuff done becomes much easier with the right tools.