The lines between different “levels” of developer are blurry. Ask any senior developer, development manager or technical director what the difference between beginner, junior, mid-level and senior, and chances are, you’ll receive vastly differing opinions.
Since there is such a wide range of opinions, there’s really no use spending any time on figuring out how to become a “Senior” or “Mid-Level” developer - levels are - for the most part - opinion.
Instead, let’s look at some things you might not have considered, of which if you implement a number of these, will increase your level as a developer.
React JS calculator? Cool demo, but not substantial. Todo list app? Once again, fun little tool, but not substantial. Most people can follow tutorials we’re talking about something else...
Something with many different views, endpoints and pieces of functionality, that is unique and demonstrates some developer creativity.
What are some examples of what we’d consider a “substantial project”?
- Tinder for dogs.
- A miniature social network for Pokemon lovers.
- An skeleton web backend or frontend framework that others could use - not that you expect to compete necessarily, but to give you an understanding of how to build one!
- Build a package in that primary programming language that you work with - one that you’d use in multiple projects.
There are some funky examples there but here’s the point - either build a larger project around something you’re super passionate about or build something that thoroughly pushes the boundaries of what you currently understand. By definition, both of those things are going to “level you up” because you’ll be coming across concepts
This means build your own open source packages / applications or contribute to existing repositories.
If you’re going to build your own packages, just make sure it’s not from a tutorial and something you actually want to put out to the world that others could use.
Bonus points if you create a blog post or video series around how / why you built it and your thought process. This not only allows you to think of it from a storytelling perspective and gain new insights, but it’s strong evidence of your abilities AND thousands of others trying to learn what you’re learning get to benefit from listening to how you went about this project.
Chances are, your favourite node, PHP, python, java packages and plugins are on GitHub. There’s an even strong chance that there’s at least a dozen open issues on these packages.
Check the repository contributors guidelines, usually in a .MD file in the root of the code, get a good understanding of it and go away and fix an issue. Better yet, add some functionality to it that would actually be useful.
This serves many purposes
- Evidence that you can following coding guidelines (Good for potential employer)
- Evidence that you’re part of the open source community and a named contributor on a repository
- You’ll learn about forking, pull requests, commits more in-depth
- You’ll see what a community maintained package looks like and have a chance to adopt some better programming practices
This is one of the quickest ways to “level up” as a developer. Because (most of the time) you’ll be staring at code that is almost certainly a level above yours.
Attempt to understand it - compare it to your own to find what patterns you can implement to improve yours - take note of all the little technical things they do that you could implement to your own workflow.
This isn’t always possible if you’re not currently working in a company, and if you’re not you can always look for open source projects from your favourite community developers who are highly experienced and read the code and try to understand.
It’s also great if the developer whose code you’re looking at is available to ask questions and happy to answer them - just let them know that you’re trying to better understand what a senior’s code looks like and get their permission to ask a few questions about things you’re trying to understand. A lot of people will be happy to help out.
Look into SOLID, KISS, YAGNI, MVC, and the vast list of other odd-sounding abbreviated design patterns and principles. There’s a massive Wikipedia page of them right here and another one right here.
Read through the definitions of each one and google for examples of each - examples are super important as if you have context about how a pattern is actually implemented, you’ll be able to understand it better.
Chances are, there’s a bunch you’ve not heard of. Most of the hiring managers here can’t recall all of them, and a quick read through some of them refreshes our memory and allows us to look at how it would improve our coding process.
We’ll probably put out a blog post with some contextual pseudo code examples of this in the future - programming patterns are something that a lot of developers never even try to fully understand, and we understand why: because they make no sense as an explanation. We need examples!!!
This is a small selection of things we think can help - please share yours with the world so other developers can benefit! No suggestions are invalid - there’s probably thousands of other developers who haven’t thought of the basics when it comes to moving forward in their learning. That’s why we’re all blogging here after all!
Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)
We worked for a couple of months on a professional design and 4 hours 20 minutes of video content to bring you our free crash course showing you how to code this portfolio website (which we constantly encourage you to customise to your own style)