Conventions matter

First of all, what is a convention?

This is basically an agreed-upon rule about how code should look and be structured. Usually a thing like naming variables, formatting, and organizing files. 

Personally, I like conventions. They make coding feel cleaner and more structured, which is a win for both individuals and teams.

First off, they make code easier to read.

When everyone on a team follows the same style, it’s way simpler to understand what’s going on. You’re not wasting time deciphering someone’s personal coding quirks—you can dive in, make changes, and move on.

Conventions also help with scaling up.

In bigger projects or teams, having consistent patterns is a lifesaver. Need to fix a bug? Add a feature? Hand off work to a new teammate? It’s all smoother when the code is predictable and organized.

Then there’s the tooling advantage.

Many coding tools—like linters or auto-formatters—are designed to work with common conventions. They’ll flag issues or tidy things up automatically, saving time and helping you avoid silly mistakes.

At the end of the day, conventions aren’t there to box you in. They’re like traffic rules for coding—they keep things running smoothly and prevent crashes. Skipping them might feel fine at first, but down the road, you’ll thank yourself (and your team will thank you) for sticking to them.

That said, they do have one drawback: they can be a bit cumbersome at times. Following strict rules can slow things down, especially when you’re in the flow of coding or working on something experimental.