10 frontend codebases. 10 different teams. Here are the mistakes I kept seeing in all of them. This year I had the chance to review a bunch of frontend codebases across different teams and different projects. No two were the same on the surface. But honestly under the hood it was the same story every time. Let me be real about what I found. The biggest one was state management chaos. useState absolutely everywhere. Lifting state up through five or six layers of components, passing props down to things that had no business caring about that state. At some point someone should have stopped and asked whether a proper state management approach was needed. But nobody did. And now the codebase is held together with props and hope. Then there was the folder structure situation. Or the lack of one. Every developer had just dropped files wherever made sense to them at the time. No consistency, no agreed conventions, nothing. You open the project and spend ten minutes just figuring out where anything lives. Prop drilling nightmares came up in almost every single one too. Components receiving five, six, seven props just to pass them straight through to a child. The component in the middle doesn't even use half of them. Context or a proper state solution would have sorted this out but nobody got around to it. And the hardcoded values. Magic numbers scattered everywhere. Pixel values, timeouts, API limits, colour codes. All just sitting raw in the code with no explanation. Good luck figuring out where that 1500 came from six months later. The thing is none of this happened because the developers were bad. It happened because there were no agreed coding standards. Everyone wrote code the way they individually thought made sense and over time it all piled up. That is the real mistake. Not the code. The missing alignment. Anyways that's my two cents. What is the most common thing you keep seeing in frontend codebases you have worked on? #Frontend #React #JavaScript #TypeScript #CodeReview #TechLead #WebDevelopment #CleanCode #SoftwareEngineering #Sydney
I can’t emphasize enough how crucial structure is. Too often we forget that someone else will inherit our code someday. Clear folder organization, consistent state management, and avoiding magic values make a huge difference. Proper code reviews are also essential, they catch these issues early and help maintain high standards across the team.
Been there. Sometimes the project is a quick spin up or POC. Once it gets mature to a 'real' future production codebase, it is really important to have those conversations in the team and agree on, document, and enforce coding standards.
Two things. First, I've said that if I ever write a book about React the title will be "Prop-Drilling Is The Enemy". Second, I've found that even when there are agreed upon standards, many devs just do what they want. To make it worse, most of the more engineering leadership I've seen will rubber stamp bad PRs and hide behind "I'm not a front-end engineer". These are the reasons I don't fear AI taking my job. They were all trained on garbage, so they produce garbage.