Progressing from beginner to intermediate as a frontend developer
So, you’re not a complete beginner anymore: You’ve built a few webpages, learned the basics of HTML, CSS and JS, and perhaps you’ve landed a job as a junior developer.
There is a hell of a lot of information online about what you should do as a beginner just starting out, but the roadmap becomes less clear once you’ve got a handle on the basics. It’s not for lack of content: there are plenty of guides out there for all skill levels. Rather, the sheer amount of information, tutorials, opinions and technologies makes it impossible to know which route to go down.
Building a strong foundation
Bear in mind that I’m a frontend, and this advice is generally geared towards other frontends. I don’t think everyone should aim to become a full-stack developer; however, I think it’s worth everyone having some awareness of the entire ecosystem, as even a little experience will make it easier to work in teams.
Don’t take this list as the be-all and end-all to improving: how you improve depends on what you want to do. However, these are some areas that most developers could learn from in some way.
1. CSS organisation
It’s not sexy, but poor CSS organisation is the most prevalent cause of headaches in web development.
How many times have you gone to change a class only to realise it’s affected elements across the whole website? Or changed some HTML very slightly, only for the whole component to break?
Methodologies exist as an attempt to systematically avoid these types of issues. By following a particular syntax when writing CSS classes and following a set of rules, we can filter out most of the common problems and allow ourselves to just focus on building stuff.
Oddly, most of these methodologies aim to make you use less of certain features in CSS. While it’s a decent language, most devs know that CSS can be a chaotic language. Even between different methodologies, each has their own rules and situations where they work best.
Being aware of a variety of these methodologies allows you to easy fit into any team easily, but it also gives inspiration for further refining your CSS development. And above all, you’ll have less headaches! No methodology is perfect, so sometimes you’ll want to adapt your method for a certain project. CSS organisation is far from a ‘solved’ problem, as the flexibility of the languages allows plenty of room for new approaches.
Utility-first frameworks have become very popular lately, especially amongst React and Vue developers. I’ve written quite a bit about Tailwind CSS, which is just one flavour of the utility-first ideology, but I wouldn’t recommend any beginner to jump into a framework such as Tailwind, Bootstrap or anything that packages CSS classes for you until you deeply understand vanilla CSS and SCSS. If you want to give it a go, try to think about how to keep your CSS DRY using these technologies.
2. Go CSS-only
checkbox:checked to create toggles and trigger them using a
mouseover event to add a class that makes a dropdown visible, but in most cases there’s no need as you could use a nested hover state which would be easier on the user’s hardware.
3. Single source of truth
In all your programming, you should aim to have a single source of truth for everything. This is the core idea behind DRY – Don’t Repeat Yourself – programming. In order to not repeat yourself, you need to define everything only once. This plays out in different ways depending on the context.
In CSS, you want to store all the values that appear time and time again in variables. Colors, fonts, max-widths, even spacing such as padding or margins are all properties that tend to be consistent across an entire project. You can often define variables for a stylesheet based on the brand guidelines, if you have access. Otherwise it’s a good idea to go through the site designs and define your variables before starting.
Variables can also be sources of truth. It’s a good idea to put global constants – variables that will never change that are used across the app – into their own file for organisation. Some developers name global constants with
CAPITALISED_SNAKE_CASE to differentiate them from regular variables.
In a similar vein, get used to using environment variables. These are global constants that change depending on the environment: Say you have a ‘development’ API for testing and a ‘live’ API for production – you can define both in separate files, and when the time comes to build your app you can ask it to build for either a ‘development’ or a ‘production’ environment. This means you don’t need to change a load of variables when releasing an app – super helpful!
3. Go vanilla
Forget jQuery or any other libraries you might normally reach for. Try building your sites using no external packages, just vanilla JS. Feel free to compile your ES6/7 if you need to, but that’s it.
You’ll find this difficult at first, but eschewing 3rd-party code forces you to learn how every piece of your application works. Focus on creating reusable utilities for things such as selecting elements, manipulating the DOM, and handling requests.
Development will be slow, but the goal isn’t to build things quickly: Rather, you should spend plenty of time on the research to get these things to understand the building blocks of your craft.
Learn string and array methods, how to work with objects, using Promises and so on. Doing daily exercises with a service such as Exercism is a great way to learn each method, but using them in context is what will take you from beginner to expert level. You’ll see that there are many ways to skin a cat, and how you choose to solve a particular problem will depend on the situation as well as (to an extend) your personal style. For example, some people prefer to handle promises using
.then().catch(), but I would always use
async/await as I find the syntax much tidier. There are people who will argue you should use x over y, but it’s a good idea to understand every possible way of doing something since you don’t know if you’ll be dropped into a project with legacy code or if the previous developer just had a different way of doing things.`
How about building your own reactive framework? Watch Tejas Kumar’s fantastic talk about creating a rudimentary React clone. You don’t need to build it, just try to understand it. You’ll find that the technologies you use every day, while undoubtedly complex, aren’t so impossible to understand as they first appear.
4. Manage your own server
Although DevOps and servers can be scary to a beginner, having a small server to mess around with will help to introduce you without any pressure. Start small and build up: You don’t need to learn everything straight away: exposure to concepts and configurations surrounding your server will gradually engrain the knowledge in your head.
Even if you’re solely a frontend or aren’t interested in running your own websites, understanding things like htaccess, robots.txt and deployment pipelines will make you much more desirable to employers. You will almost definitely need to deploy to a server at some point, so getting the learning in ahead of time will put you a step ahead of the competition. Having a platform to showcase your ideas opens up limitless possibilities, improves your knowledge, and it’s just good fun.
5. Learn regex
Learning the regex for your language of choice opens up a whole host of opportunities including web scraping, which allows you to use any web page as your data source. It also allows you to write complicated logic for strings, such as validating form content, with much more brevity than when using string functions. Regex is commonly used for verifying the format of strings, for example ensuring a phone number is the correct length or a postcode/zip code is in the right format.
// replace 'tag' with your html tag of choice /<tag(.*?)>|<\/tag>/gi
You can use
(.*?) to create a capture group that will match any content between the string to the left and right of it.
() - creates a capture group . - matches any single character * - matches the previous character infinitely e.g. 'heel'.match(/e*/) = 'ee' ? - tells * to match the minimum number of times. You might not need this! | - 'or' operator
This allows you to find all instances of a particular HTML tag, regardless of the attributes assigned to it. This is really helpful for finding and replacing in your IDE, and can be adapted to fit your specific needs.
You could include another capture group to match the entire element instead of just the tags:
'<div class="something">Some content</div>'.match(/<div(.*?)>(.*?)<\/div>/gi) // matches
From here, you can go further and find all tags containing a certain class or attribute, capture the innerHtml of all tags with a certain class, find and replace all instances of a particular class to change it from a link to a button, you get the idea… You can do a lot with regex.
6. Don’t get stuck in your ways
The most important thing to remember to stay competitive as a developer, is that the industry is constantly changing. There are new ideas and technologies appearing every day. Although you shouldn’t be distracted by these new things, as they come just as often as they go, it’s good to have some awareness of what your industry is using so you don’t fall too far behind.
It’s also important to accept that even if you believe in a certain way of doing something, there might be something that comes along to solve your problem even more effectively. It’s good to have opinions, but many developers fall into the trap of believing that their way is the best way.
Programming is far from cut-and-dry: Everything has it’s upsides and downsides. Every project has it’s own needs, and the same technology or approach isn’t always best for all of them.
7. Be business-aware
We all love to code, but at the end of the day most of us do this to pay the bills. We’re (aside from freelancers and hobbyists) employed by businesses with clients, deadlines and budgets, and our performance in delivering projects is what reflects us more than the quality of our code – although high-quality code will generally make delivery go much smoother.
Becoming a mid-level or even senior developer is as much about what you know as it is about the responsibility you can take on and your commitment to delivering the best you reasonably can in the time you’re given. If you create the best damn website the world has ever seen, but it’s a month late, it won’t reflect on you well. Sometimes you will need to find shortcuts or outright cut things out of a project: At the end of the day, your company only has a limited budget they can spend before they start to make a loss.
Senior developers are paid what they’re paid because they’re reliable. Yes, they can solve problems faster and know a hell of a lot, but they will also do what it takes to deliver a project on time. They understand which technologies and approaches will fit the needs of a project without being overkill, taking too much time or requiring too much custom code.
This isn’t the most exciting or inspiring part of being a developer, but it’s what the people who pay you will notice more than how efficient a function you wrote is.
8. Be patient, and practise often
I’m a big fan of the phrase, “you don’t know what you don’t know”. Progamming is a long game: it takes years to become a truly competent developer, and the more you know the more you realise you don’t know very much at all. Have humility, and just keep on building things. Push yourself further each time, try new things and refine your techniques. Forget about the destination and focus on the journey.
Eventually you will have some idea, or you’ll start a project, and notice how much better you code is without even needing to think about it. You’ll have the knowledge engrained into your head enough that problem solving becomes trivial, and you can use the freed-up brain power to tackle even greater problems. Be persistent but patient, and you will become a great developer right under your own nose.