Progressing from a beginner to intermediate 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.

What now?

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

Your route to improvement will generally depend on what you want to do. With that said, you can't go wrong with simply improving your fundamental skills. Let's say you want to eventually be a React developer: Yes, learning React now would certainly get you into the ecosystem faster, but ignoring what React is built on - plain old JavaScript - can limit you in future. If you want to raise the ceiling of your potential skill level, learning the ins and outs of the base language is the way to go. You will end up with more clean, intentional code that you understand completely, and spend less time figuring out why it's not working straight away. Don't feel like you can't experiment with different technologies: Learning SASS, for example, isn't so far off CSS that it can't teach you the basics while also gaining the benefit of a preprocessor. React is still just JavaScript under the hood. You'll get the best results by pushing yourself out of your comfort zone just enough to make sure you're learning at a steady rate, while also making sure you give yourself enough time to soak in all the information.

If you want to be a frontend at an agency, master basic CSS and fully understand what each line of your CSS is doing. If you're a backend developer, wrap your head around the key concepts and build as much as possible yourself before reaching for a framework. If you'd rather be making frontend apps in the future, get to grips with vanilla JavaScript - ignore jQuery and any flashy framework for now. Of course, feel free to dip your toes - but remember that learning programming is a life's work, and building upwards with a poor foundation will reflect in the quality of your work.

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

Here's a fun exercise: build a functional navigation, with hamburger button and multi-level sliding mobile menu without a single line of JavaScript. It doesn't really matter how it looks, just that it functions as you'd expect a mobile nav to. It's surprising how much use you can squeeze out of plain old CSS for simple things such as toggling a 'class'. You can use sibling selectors ~ or + alongside checkbox:checked to create toggles and trigger them using a <label>.

CSS is much more performant than JavaScript, so while you shouldn't go overboard with these hacks it's good to be aware of performance shortcuts like these. In general, even if JavaScript is unavoidable a good rule is to keep it as minimal as possible without affecting functionality. Usually the simpler something is, the less there is that can go wrong with it. A common example is hover states: You COULD use the 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.

How about no images? The background property is surprisingly powerful: it can be used to create complex shapes similar to SVG. Alvaro Montoro even created Homer Simpson using just one element.

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.

In JavaScript, every function you write should only appear once. If you need to reuse it in a different place, isolate it from the context you're working in by putting it into it's own file. You'll often see a util folder in JavaScript file structures - generally this is where you'll find more generic functions used across the app.

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.

To get you started, here's a quick rundown of a pattern I use constantly in JavaScript (syntax may change depending on language).

// 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.

I recommend MDN's (javascript) cheat sheet and regex101's Regex Tester to get you started.

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.