Here’s a summary about the technical philosophy at Figures and how we approach problems. Please use those as an honest basis of discussions for code reviews & architecture discussions.

<aside> ℹ️ None of these guidelines are absolute (well, except this one). Always apply your judgment and feel free to argue about them as they will most likely evolve in the long run.

</aside>

<aside> 🗣️ Build publicly, Be transparent

Communication and transparency are key to short feedback loops and collective ownership. It allows for the team to jump-in whenever needed, and for the company to easily and quickly know the state of things.

</aside>

<aside> ✅ Prefer simple solutions first

Do not obsess over “clean code” and DRY principles. Premature abstractions are often wrong. Do not be afraid of repetitive code & manual operations as a first production-ready version. Only time & actual usage will tell if an abstraction is needed, and it’s always easier to build one than having to undo/improve a broken one. [inspiration]

</aside>

<aside> 🎀 Care for your code

Struggle to write abundant, explicit and readable code. Your Pull Requests, taken in isolation, should display a clear intent to other team members with minimal context. A simple guideline here would be : you should be concise with your thoughts, and verbose with your code. If your logic is refined enough, the extra lines of code won’t hurt its readability - on the contrary, the explicitness will help later on with debugging.

</aside>

<aside> 🚴‍♂️ Converge fast — execute and iterate later

Avoid bikeshedding. It's always better to make decisions and fail fast than try to be perfect (on product or endless discussions/meetings) and take all the time in the world.

</aside>

<aside> ☎️ Over-communicate on your work

Write documentation whenever you implement a meaningful feature, update your teammates whenever you can.

</aside>

<aside> 🔥 Feel the pain

As a generalisation of the previous rule for non-tech related problems, avoid preempting solutions when you’re not certain there’s a problem in the first place.

</aside>

<aside> 🐞 Do not tolerate bugs

This does not mean that every minor bug should be fixed immediately, but that all known bugs should be resolved within a week. Accumulating huge backlogs of bug-fixes ends up being demotivating to the team and is an open admission of being semi-broken all the time.

</aside>

<aside> ☝️ Be reactive with external input

As the team & clients base grows, the tech team will receive more and more feedback (ideas, bug fixes, support request). Such feedback is extremely valuable and we want to ensure to answer clearly and quickly. [see give a shit].

However, don’t take external input at face value. Users identify pains and you can't ignore that, but they can easily be wrong about the actual remedy. Gently challenge feedback to get to the bottom of it and present a solution that you know solves the issue durably and sustainably. Be the hero they need, not the one they deserve.

</aside>

<aside> 🚧 Design systems that are secure from the ground up

Our clients trust us with their data, and they are right to do so.

</aside>