Overview

Currently, there are nine engineers in the frontend team: One principal, three senior, four mid-level, and two junior. Most of us live in Japan, and some in Europe.

For large frontend projects, there will be multiple engineers assigned to a project (more details on our squad structure can be found here). We have a few smaller projects that are typically maintained by one person, however. Juniors will never be assigned to a project alone and will receive mentorship from senior and mid-level engineers, but the expectation is that juniors could quickly level up to become fully autonomous.

We have a weekly frontend meeting where anyone on the team is free to propose an agenda. We talk about new tech to investigate, our strategic vision for the team, documentation that needs to be updated, etc. Larger proposals can also be raised as Request for Comments documents (RFCs), and of course, anyone is free to open one.

Tech Stack & Open Source

Most of our projects are written in React and Typescript. As with any company we have legacy tech, though we are planning to migrate these projects to our current stack in 2023.

Core Stack

• Typescript

• React

• Emotion

• XState (we have one app on redux but none of our projects currently use jotai, zustand, rxjs, recoil, etc.)

• Express (for server-side rendering)

• Storybook

We also use react-use and immer across many projects.

None of our projects use css frameworks or batteries-included kits like tailwind, bulma, ant, material-ui, chakra, react-bootstrap, etc.

Legacy Stack

No startup would be complete without some legacy tech.

We have one project on ember.js and are in the initial phases of refactoring it to React. There is also another traditional server-side rendered app in Ruby on Rails that we currently migrating to React.

Theming & UI

We have another open-source lerna monorepo, tablekit, which consolidates our reusable react components. For the next version of Tablekit we autogenerate our semantic theming from Figma which allows our in-house designers to be the authoritative single source of truth for our themes and branding. As all our spacing values come from a single place we have extremely few issues with pixel-perfect design at TableCheck; everything is pixel-perfect from the start by default.

Tooling

We maintain our own open-source tooling package, tablecheck-react-system. This lerna monorepo consolidates all our webpack, babel, tsconfig, eslint, jest, cypres, prettier, commitlint, husky, etc., configs into a single source of truth for all our react projects. We err on the strict side of our tools to ensure high standards, consistency, and rigorous type safety across all our projects.

Testing

Currently, we use jest and cypress (e2e and component) for all our testing. We promote test-driven development for bug fixing and adhere religiously to the Test Trophy model (described by Kent C. Dodds here) to ensure that our products are stable. We've tried to use Gherkin in the past but found it to not be suitable for our needs. We also have a small team of QA automation engineers using Playwright and collaborate with them closely.

Collaboration

Code Review

Code review is an integral part of the frontend team at TableCheck. We aim to have two reviewers on every pull request. We have codified code review guidelines for both reviewers and submitters to ensure that code review is, foremost, never taken personally. Our automated tooling takes care of the majority of nitpicky issues so arguing about whitespace or tabs vs spaces is a non-issue for us.

Pair programming

We do not require pair programming, but we use slack huddles quite frequently to debug issues together.

Collaboration and planning

There are no strict rules or procedure guidelines for how each squad operates. The only expectation is that products are delivered. Team members in each squad are free to determine their own processes to optimize their collaboration.

We use Jira and Confluence for everything. Each squad is generally free to determine how their boards and spaces are organized and run and automated.

With that said, feature planning is a squad-wide exercise that involves designers, frontend and backend engineers, QA, designers, and product managers, and sometimes there's input from specialists in consulting or operations. We value casting a wide net by broadcasting communications (we typically prefer slack discussions in public channels over DMs) and letting channel members optionally participate in discussions if they think their input is not critical.

If any of this interests you please take a look at our open jobs and reach out to us!