Uh… it’s my first day
It’s a beautiful day, birds are singing, and as you’re walking through a park, someone runs up and says, “Hey, help out with this frontend project, will ya?” Such is the life of a software consultant (kinda).
As a consultant, projects may involve a tech stack you’ve never used before or a codebase you’ve never touched before. And although very few projects at Giant Machines are spontaneously introduced by a stranger at the park, any decent consultant, or developer for that matter, should know how to hit the ground running.
An unfamiliar codebase is a new land, an unexplored environment, and there are lots of things you won’t understand. But there are plenty of housekeeping tasks any developer can do to contribute on the first day.

Let’s go over these tasks, which will help you become familiar with the main business logic of the app while making the codebase more robust.
Codebase Conventions
Typography

A typography file is a huge step in standardizing a major styling aspect of a frontend app. Its purpose is to act as a sole export location for text styles, including their font families, sizes, and weights, allowing them to be imported wherever they’re needed.
The designer of the project should have a collection of styles specifically meant to be used throughout the application for every kind of text. As the developer, these text styles should be properly standardized into the application. This way, if designs or the overall app were to change, fonts and sizes can be easily changed in a single place rather than in numerous places throughout the codebase.
export const Text = {
HeadingOne: css`
font-size: 30px;
font-style: normal;
font-weight: 700;
line-height: 37px;
`,
HeadingTwo: css`
font-size: 24px;
font-style: normal;
font-weight: 700;
line-height: 29px;
`
}
Colors

Similar to the typography file, a colors file provides access to the entire color palette the application uses. Every gray, off-white, or specific hex code of the company’s brand colors should be standardized here so there are no mixups, enforcing uniformity. Ask the designer for the color palette they intend to use.
But, what if the designer doesn’t have typography or a color palette ready yet? What if there is no designer? No need to fret. Have a typography and color file set up and ready for exporting, and add the fonts and colors when they’re ready. Look through the codebase to see what colors or font style sets are currently being reused, and see what can be consolidated.
export const Colors = {
CoreBlue50: '#E6E8F4',
CoreBlue100: '#CCD0E8',
CoreBlue200: '#99A1D1',
}
If you need to set up initial colors to get things rolling, take a look at coolors.co to generate some possible color palettes!
SVGs

SVGs are incredible. They’re simple, fast, and can be implemented in a million ways, which is part of the problem. In any new or even old codebase, there might be several variations of SVG implementation throughout the project. It can be helpful in any codebase to standardize the method, especially since there are pros and cons to each one. Speak with the tech lead or open a conversation with the team as a whole, and determine which method works best for everyone.
Check out these articles for various SVG implementations!
The Best Way to Import SVGs in React
Testing
Jest, React Testing Library, Mock Service Worker (MSW)
Not only do tests ensure a robust codebase, but writing them allows the developer to get familiar with existing components and their business logic. Add some simple Jest and React Testing Library tests to check that UI components are rendering properly and user actions are firing correctly.
Adding Mock Service Worker can also be a great addition not only for current or future testing, but for a proof-of-concept or MVP with a backend that is not quite ready. MSW intercepts fetch requests and allows insertion of mock sample data, allowing a complete imitation of API capabilities. With this, all tests and even the prototype of your application can be presented with full functionality without needing to hit a backend API.
Testing is by far the most expedient way of understanding a component’s business logic, so if that’s the priority, make sure to start with testing!
Complete Guide to Unit Tests with React
A Comprehensive Guide to Mock Service Worker
Using Mock Service Worker to Improve Jest Unit Tests
Development Environment
ESLint & Prettier

If the project currently doesn’t have any linting rules or Prettier formatting, speak with the tech lead and offer to set it up! Add ESLint and Prettier config files, and decide what rules work for the team. Is everyone fine with Airbnb linting rules, or maybe just some proven favorites like no-unused-vars
or exhaustive deps
? Semicolons or none? Make sure the team comes to a consensus.
Something else to consider is applying linting and formatting before every git commit. A package like Lint-staged only lints and formats on staged items, ensuring all pushed code follows the standards in the repo. This allows developers to have their own formatting preferences when developing, while the code homogenizes on push. Linting pre-commit also avoids strict rules like no-console
or no-unused-vars
restricting a developer when writing code, when it should only apply in production. Imagine not being able to console log anything during development!
Config ESLint and Prettier in Visual Studio Code for React.js Development
Setup ESLint and Prettier in Your React Project
Husky

I’m sure you know Husky; it’s on basically every project. Pre-commit hooks are important for the development process of any codebase and ensure code meets a standard before being pushed up. This is the perfect time to perform certain actions, like running unit and integration tests, to make sure your latest code changes don’t break anything. It’s also a good time for running linting and formatting to match the standards of the repo. If Husky isn’t there, add it!
Check out this blog, Releases the Easy Way, for other pre-commit methods to try!
Set up ESLint, Prettier and Husky in a React project | a step by step guide
PR Notifications
Your pull request is ready but you’re not sure if anyone has noticed. A very common practice is to have a channel on the team chat platform set up specifically for GitHub or Jira messages. If there isn’t one already, suggest it to the tech lead and start hooking it up with GitHub to drop a notification for new PRs or merges. Adding a Slack or Microsoft Teams GitHub integration is pretty straightforward, but often just overlooked when the team is on crunch time. Similar integrations exist for other version control providers like GitLab and Azure DevOps.
Codebase Housekeeping
Frameworks & Libraries
A lot of proof-of-concept and MVP projects start out with a number of libraries meant to be temporary. Maybe the app was using Chakra UI for its modal and custom buttons, while the rest of the imported library is just dead weight. Perhaps developers have been spending more time adjusting Semantic UI’s styling to match the designs than it’s worth.
Before these libraries become too embedded in the app, speak with the tech lead and the team and hear everyone’s opinion on the app’s eventual goal. If some libraries can be dropped, you can be a great help in slowly refactoring these components. Start stripping out the library’s usage piece by piece to carefully avoiding any breaking changes, and you’ll also gain exposure and insight to vital components.
Reduce Clutter

You’re looking through the codebase to get acclimated, and you stumble upon a glorious 500+ line component. It has everything it needs to succeed, but it’s horrible to read and a bit convoluted for anyone’s taste. Examine all the functions, variables, types, and hooks, and see what you can pull out and relocate. If there’s one too many helpers, put them into a utils
folder. Toss types and interfaces into a types
folder, and put all hooks and states that work exclusively with one another into a custom hook.
Reusing Logic with Custom Hooks [React Docs]
Conclusion
It’s perfectly normal to feel overwhelmed by a new project, but part of being an experienced developer is knowing how to hit the ground running. Any of these tasks can be a great first step to learning the ins and outs of the codebase, while contributing to the team’s vision. So get out there and make some changes!
