Hey there 👋

We are Doctrine engineering team, we build Doctrine legal AI. 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 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 structures that will be common engineering knowledge for the entire team.

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 the 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 features: 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, and 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!