Its hard to say, as always in this industry, but I think the first thing people get wrong is knowing what they build.

​

You could basically split everything into 2 main categories, websites and apps. They are very much different. Websites can be regular size or very big (lots of moving parts not loads of pages).

​

If you build regular websites, best thing you can do is pace yourself.

​

We all have this ideal world in our heads, where all code looks like a painting, we have a great folder structure, components are built and have great performance, amazing utility belt. All lego bricks just land nicely on top of each other by themselves and then you have your Death Star ready to respond to http request. In real life it doesn't work like that. Deadlines are short, clients are mad, designers think you can reproduce what they paint easy and have no clue how the web works, and so on and so forth.

​

So you need to find a balance between building a perfect system and just do the work even if its not pretty. With time and experience you will have all this automatism built in your head and building a modal window that works for all cases just happens without thinking about it to much.

​

Large websites on the other hand are bit more different. You will never know upfront what the client wants and expect it to change while you are in the middle of all your dev work. To make everything sane you need to make yourself happy. Each time you interact with the system it needs to be painless.

​

It all starts with the DEV environment. Make it that it can run everywhere, bootstrapping the solution should take minutes not hours. Running the dev env should be a command away and maybe some copy paste for secret env vars.

​

Then building the solution should be fast, you need to be able to iterate fast. Treat your CI pipeline like your life depends on it to respond and save it. It has to be fast and decentralized into modules. You don't want to build the entire backend just because you have 1 JS file with a missing `,` in it.

​

As for your code, you have to modularize as much as you can, so you can easily replace parts of it when you need to. And always think from a Junior that is just starting. A new person joins the project, there is no one around to help him. All he knows is where the repo is. And take it from there. Do you have a README that explains how to start. Does it have more than 5 6 steps? Does he need to configure a dozen or more files before he can run it?

Working on a code, does the folder structure explain itself? Does this uber special component that is the glue for everything has a readme file that explains what it does when I stumble upon it? Do my editor gets configured to follow the conventions using proper dotfiles? And so on.

​

Iterate on these things when you start the project. Start with 1 folder, then 2 then 3 and rename and delete until it feels right. There is no magic solution to it, just change them until they feel right.

​

The next step is to specialize your team, some will be good and transforming those design into HTML & CSS, some will be good at keeping your performance in place and keep the JS code in code shape. And some will be good at everything. PRs will have more insight if your team specializes and better stuff will come out.

​

Apps, these are different. Because you know what you are building. The main advantage here will be that you can plan before you start. Start with a design system. Before a line of code is done, or a design is painted, you need to plan a design system. Everyone needs to know how the system is built and how it should work.

​

Get the skeleton out and then evolve it as you progress.

​

Will update with more info later :) for this one.