3 ways your team can improve code quality

Pair programming with new hires

Even if the new hire is a great developer, they will inevitably have their own way of doing things that may not marry up perfectly to the way your agency does things. Taking the time to do some pair programming and code reviews can go a long way in getting them onto the same page.

There are also production benefits to this practise: Williams et al (2000), The Costs and Benefits of Pair Programming, indicates that for a slightly increased development time of around 15%, projects which utilise pair programming show a reduction in bugs and risk, as well as improving team skills and communication.

While some managers may wince at the idea of increasing development time, take this into consideration: between bugfixing, repeated deployments, QA testing and back-and-forth with clients, program defects can take up as much development time as building the thing in the first place. Even worse, if hard limits on time allocated to bugfixing is not discussed with the client, agencies can easily overspend on time spent simply getting a website up to standard. Without a doubt, it is more cost effective to do things right the first time around. In the long run pair programming could greatly decrease the cost and development time of projects.

Pair programming has also been shown to improve developer engagement and satisfaction, as well as making devs more confident in their solutions. There's also evidence that pair programming may help with inclusivity, particularly improving female representation in programming. It might be that it's a break from the monotony of independent work, the learning experience or just the chance to improve work relationships, but it's clear that developers who code in pairs are happier and have more pride in their work.

There are even Git workflows, such as Trunk-based development, which embrace the idea of pair programming whole-heartedly. This style of development is not only great for improving development quality in small teams, but also improves each team member by forcing them to explain and justify their code while taking in contributions from their peers.

Have everyone use the same auto-formatter

Formatting code is one of the longest running arguments in programming. Line length, tabs vs spaces, padding parenthesis with whitespace - all these issues can be made consistent by using a formatter. Even better, you can enable format-on-save in most IDE settings, meaning you can forget about formatting entirely. Just press save, et voila! Beautiful code.

However, this becomes an issue when working on a team of developers. Why? Well, if only one person is using a formatter, every time they save a file the whole structure will change. This will show up in git, so it becomes impossible to see what has changed with each commit, because when a formatter does its job it can change every single line of code. If you can't see what's changed, it becomes hard to figure out how something went wrong when it inevitably does. It also really messes up any merges you try. The same goes for if multiple people are using formatters with different settings. Each will end up overwriting the previous developer's code every time they work on a file.

The solution is for everyone on the team to use the same settings. We can then have beautiful, readable code, with no effort and no problems with source control. This takes a bit of time to setup, but for the time saved later on it's worth it.

Formatters

There are a few known formatters for most editors - I'll be focusing on VSCode, since it's what I used. If you use a different editor, google is your friend: experience will vary based on what you use.

Personally, I have been using the Prettier extension to do my formatting as it supports all the languages I use on a regular basis. If you're a frontend developer, chances are this will cover the majority of languages you need to use.

For other languages, there are plenty of other extensions that will handle formatting of these languages. You may need to configure your VSCode settings to get them working for specific languages.

If you're a backend developer and use Visual Studio, there are similar extensions which can handle formatting of any language you require.

Linters

Formatters tend to take their rules from linters - scripts that raise issues if your code doesn't follow a particular standard. It's a good idea to run linters alongside your formatter, so they can highlight any issues you missed or if you forgot to format a particular file. This might be redundant, however, if you opt to enable format-on-save in VSCode. This way, you won't even need to think about formatting - every time you save a file, everything is automatically taken care of.

Setting up format-on-save in VSCode

VSCode official supports format-on-save, so this can be enabled by changing a property in your settings.json file. To access this file, press Ctrl + Shift + P and type in 'settings' - then select 'Preferences: Open settings (JSON)'.

Add the following line:

"editor.formatOnSave": true

If not already set, you will also want to set your default formatter here:

"editor.defaultFormatter": "esbenp.prettier-vscode"

Once you've done this, save the file and reload your VSCode. Your files will now be formatted automatically, with zero time and effort!

Write up a methodology guidebook

We all know (roughly) how to use BEM, sure. We all know how to name variables, how to use the block-element-modifier pattern, and how to structure our CSS for performance and readability.

The problem is that even within those rules, everyone has idiosyncrasies in the way they use them. Some people who use BEM will insist on heavy nesting. Some people will style elements directly, even though it encourages the unholy !important rule.

Drilling down into exactly what the guidelines for code quality are helps new developers understand what is expected of them, encourages learning and higher code quality, and overall reduces potential problems caused by different approaches. It also helps bridge the gap between senior and junior/mid developers - by having the important information in writing, it's not locked away in the minds of only a few developers.

Take CSS, for example. It's a great language - very powerful. The problem is that, by using its multitude of features without any rules, we end up writing difficult to understand code. This is circumvented by methodologies, yes, but methodologies don't always go into the detail they should. Over time, agencies and individuals accumulate a set of rules which guide them to a cleaner codebase.

Keeping and maintaining a document or web page that explains these rules, including the minute details and unique features of an agencies own approach, is a fantastic tool for both new hires and old heads. Including this document in the required reading for new hires gives them a head-start, and being strict about these rules when reviewing pull requests can help to solidify the best approach in the workflow of developers.

There are a few principles which make up a solid coding style guide:

1. Comprehensive & accessible

Your style guide should be well documented: Lack of documentation will lead to confusion, and allows developers to fill in the blanks themselves. On the flipside, this document should be no longer than it needs to be. Nobody will be able to remember a hundred different rules, and so code standards will be fragmented and inconsistent.

2. Logical & justified

This material should not boil down to someone's opinion, and if it is it must be well thought out and justified. If not, it's likely that developers will disagree with the style guide and may push to change the guide. It's a good idea to get everyone's own opinion from your team and then debate pros and cons of each. The standards should work for everyone, not just one or two developers.

3. Purpose-built

While online guides are a fantastic starting point, they may not consider all the nuances and workflows of your team. Whether you need commits written a certain way for Git flow, or you're using a CSS framework such as Tailwind, there will be unique requirements for every team.

4. Enforced

It's no use having a style guide if it's just going to be ignored! The two most obvious ways to enforce standards are with pull requests, and pair programming. I would personally advocate for pair programming, since it's a much more focused format and because it's easy to skim over a pull request on a really busy day, but as with the previous point: Whatever works best for your team.