Wrapping my head around the monolith: my first months at Doctolib

Published in

Doctolib

5 min readJan 24, 2020

After two months at Doctolib, I wrote a short piece to share my new joiner perspective on the company. It was the end of December so it was pretty calm in the office and I wanted to share some feedback with the team. I was contacted by the team that runs the blog and they encouraged me to share my feedback with the world, so here it is. Here are my thoughts on what it is like as a new developer joining Doctolib in 2020.

Organization

#PeopleOverProcesses

This isn’t easy to uphold in a thousand-people company, but the spirit really is here. I get help whenever I need it, and the rest of the time, I enjoy autonomy, engagement, and a freedom to take initiatives. Safeguards feel barely there (even though they are), which is encouraging.

As a corollary, however, I can tell that this balance is fragile. It’s easy to dip into either bureaucracy or chaos.

In this regard, the private StackOverflow we have is a good example of something that works well. It’s not an attempt to hoard every single piece of information in the company, and yet it comes in very handy for specific questions. I will try to use it more systematically.

#Onboarding

I thought the DA (editor’s note, DA is what we call our Doctolib Academy that all our team do in their first few weeks) and the DA tech were an excellent onboarding experience. Again, knowledge management is critical in any company, and it just felt right to begin my job with an intense crash course on everything at Doctolib.

If I have a minor quibble, though, I wish the tech modules of the DA had been packed right behind the general DA, instead of stretched over weeks, because:

It got in the way of a lot of things when I was taking up my first tasks in my team,
By coming in later, it inevitably covered some topics which I had found out about on the job.

I can only imagine the logistics gauntlet it is to make the DA happen, but I feel like it could have an even larger impact if it came earlier.

Starsky&Hutch is also a fantastic thing, and a bit like the DA tech, I only wished it had come even sooner. To those of you who may not know this, Starsky&Hutch is the technical mentoring system at Doctolib, where you go through Rails and React 101 and are bootstrapped by a mentor to learn the stack. I really enjoyed it!

As a very minor last remark, I noticed that new joiners (myself included) have had to make quite a bunch of requests, even though they are the same for everyone. For straightforward things like access to the GitHub repo and particular mailing lists, I’m sure there is a fix for this.

Code

I had never worked on a codebase this large, by far, so I was surprised by a lot of things.

#Rails

Everyone told me, but I had to experience it to believe it: learning Rails is difficult, frustrating even, for about a month, and then it starts paying off very, very quickly. I don’t know why I couldn’t quite come around to trusting “you’ll see, give it a month and it gets much better” — likely my imposter syndrome at work but it turned out I was dead wrong.

I think there are two main reasons for this steep learning curve. One is obviously “Convention over Configuration”. The other is a concrete manifestation of it: there simply is a ton of implicit code in Rails. The first time you bump into, say, a <controller_action>_path or <attribute>_was -type helper, you just can’t find an explicit definition for it, and Google will likely prove unhelpful. Yet, in retrospect, what these methods do is both painfully obvious and devilishly helpful. The first times, this can lead to difficult code exploration sessions, and even yield some negative feelings (“Was I supposed to just guess this?”).

But that’s where perseverance and, above all, mentoring by teammates help get through. Again, on the other side of the tunnel, the payoff is massive.

#TDD

I thought that TDD (that’s Test-Driven Development), which I was also new too, would be one those good practices which, though I fully support in the abstract, are too demanding to observe in practice, like journaling, or giving up saucisson.

In fact, I found that TDD is stunningly easy to take up, and astonishingly satisfying. It actually makes a lot of sense: TDD comes with its built-in reward mechanism. I write a test, implement, pass the test, and iterate. It’s like a build-your-own-hero’s-journey. In addition to this being riotously motivating, the comprehensive test suite we have makes this applicable to almost any use case.

Even for early code fiddling, where I used to practice a savage form of console-driven-development or Chrome-dev-tools-driven-development, I can now say that in 90% of cases, I find myself using tests.

Two caveats:

The only part of TDD that requires an effort on my part is writing tests before jumping to an implementation. I’m getting better at this though.
For front-end stuff, I wish Capybara were set-up to spin Chromes with the React dev tools. It would be so helpful when I need to pick apart the components on a page and figure out which does what. (Editor’s note, we have now updated our React dev tools to include this)

#Monolith

The monolith is impressively robust. You can actually go ahead and make changes without knowing 100% of how everything works, and with little risk of breaking everything…

…and yet, it feels kind of inevitable that you get flakies on a regular basis. I got a lot of them on my first PRs (by chance I think), and they feel pretty destabilizing when you don’t know what’s normal and what’s not. They get much, much less annoying after a while.

In conclusion,

The first few months have been really challenging, lots of learning, lots of new people... A moment of information overload which had me frustrated at the time. However, with hindsight, it was incredibly rewarding. I have learned so much and the team here has done a great job of helping me get settled in and I now really feel part of the team.

Now I feel like a true Doctoliber and I can’t wait to change healthcare for good.