Hey there 👋

We are Doctrine engineering team, we build the first legal intelligence platform. You can learn more about us in this README!

Nothing that is committed today is necessarily committed forever, and not everything has to be perfect at first. For that reason, when coming up with a technical solution, it is important to propose something we can easily build on and that will let us move forward in all circumstances. This also means, as an engineer, you have the responsibility to question current choices and implementation.

You are the owner of the change you want to see in the code or in Doctrine processes. We encourage engineers to take initiatives to make our infrastructure, architecture and code base better by proposing and pushing forward new ideas. However with liberty comes responsibility and in order for initiatives to not act as reaction forces against the other principles, we understand that adopting a new language, a structuring 3rd party library or a new piece of architecture must not be something done in isolation but as a team. Responsibility is also about taking responsibility for your choices and making sure you support them once done.

Share info broadly and systemically internally and in a public manner. Avoid taking decisions on private Slack channels or offline discussions. When this happens write down your choices and the reasons behind them so it can be shared. Additionally, effective knowledge sharing that really empowers engineers goes beyond sharing ideas or suggestions of personal practices and for that we should strive for common practices, APIs and data structure that will be a common engineering knowledge for the entire team.

In order to support Doctrine business and objectives we must have a steady delivery pace. However we should not compromise on developer experience, ability to iterate later or Service Level Objectives (SLO) in order to release early. For that we need to find the pragmatic balance between the following Do and Don’t:

• Iterate on features: We strive for early delivery and ability to iterate rapidly by releasing often.
• Listen to feedback: As we listen to our customers we understand that we should focus the technical effort where it will ultimately have the most long term customer impact.

• Release buggy and untested feature: We understand that releasing early & often does not mean releasing fast and dirty.
• Release weak, inconsistent and/or undocumented code: we know that releasing early & often especially on the long run requires having a solid, consistent, documented and ready to evolve infrastructure, architecture and code base which in itself takes time and effort.

You can learn more about how those principles derive from our values in Doctrine Engineering Principles & Practices.

This is not an exhaustive list, but we mainly work with:

• Node.js / NestJS
• React / Next.js
• TypeScript
• Jest, Cypress
• Elasticsearch
• PostgreSQL
• Snowflake
• Python
• Pytest
• Airflow
• Pytorch

We host our code on Github, deploy on AWS on Kubernetes and Lambdas leveraging Terraform & CircleCI. We monitor our production with Datadog and Rollbar.

You can learn more about what we build and how we build it on our blog.

You can also meet us at the Paris NLP Meetup that we regularly organize.

And if you feel like joining us, don't hesitate to look at our job offers!