DIMITRI BOURREAU

What kind of developer I am: my work preferences and habits

This document explores what kind of developer I am, how I collaborate with teams, detailing in particular my work preferences.

I have made sure that every fact written here is true and confirmed by my peers. My goal is not to please but to make it easier for me to connect with teams looking for someone with my personality and habits. ☝️

TLDR: I organize my days with discipline, few meetings, precise time tracking, and daily reviews. I love refactoring, debugging, and supporting junior devs. I aim for clear, lean, and lasting code. In reviews, I seek to share knowledge and improve the project without ego or frills.

Code reviews

  • I do my reviews with only two goals: sharing our knowledge and ensuring that each merge has a positive impact on the project.
  • In my reviews, I explicitly mark non-blocking comments for the merge. These invite discussion but are entirely optional and can be ignored.
  • I show strong kindness and I don't dwell on frills.
  • I accompany my PRs with clear objectives, instructions for functional review, screenshots, a comprehensive list of changes, and optionally automated tests.

Software design

  • I prefer many small commits with clear and thorough messages rather than a few large commits.
  • I prefer keeping commits after merges rather than squashing them.
  • I make sure my branches don't linger past the end of the day, when the team's workflow allows it.
  • I separate the UI from the business logic.
  • I like TypeScript, automated tests, and hexagonal architecture (separation of UI - business logic - API).
  • I believe it is very important to have documentation that is regularly updated, accessible to non-tech colleagues, written in the end users' language, and kept in a single place.
  • I recently changed my mind about end-to-end tests -- I enjoy using Playwright now. However, I think testing the back-end through these tests is a mistake.

Communication within the team

  • I am careful to avoid any display of personal pride or ego: my goal is the team's success. As such, I communicate quickly when I'm stuck, and I flag issues without considering the impact on the continuity of our collaboration.
  • I make a point of responding very quickly.
  • I don't know everything, and I fully embrace this quote from Kent Beck: "I'm not a great programmer; I'm just a good programmer with great habits".
  • I favor direct and factual communication.

Planning

  • I like to work between 9:30 AM and 5:30 PM.
  • I use a tool to track my working time and note my progress.
  • I protect my focus by limiting notifications.
  • I'm used to working on public holidays.
  • If a task takes less than 10 minutes, I can tackle it immediately. Otherwise, I make a note of it.
  • At the end of each day, I write myself a summary of what happened along with a few suggestions for the next working day. At the start of each day, I read the most recent summary.

What I love!

  • Refactoring.
  • Debugging.
  • Writing code reviews for junior devs.