Career Change · Rust Engineer

Richard Lavoura

Python/SQL data engineering · 8 yrs · CHANEL, Kering

“The turning point was a real systems project. We shipped a git TUI in phases, not another analytics demo.”

Richard came into the engagement an 8-year data and analytics engineer, currently at CHANEL and previously embedded at Kering supporting Saint Laurent, Balenciaga, and Bottega Veneta, with missions at Carrefour, Stellantis, and Française des Jeux behind him. Rather than toy exercises, we scoped a real tool from day one: a lazygit-style terminal UI for git, built on ratatui and crossterm, with a keyboard-first workflow covering staging, commits, branches, the reflog, and interactive rebase. The goal was a public, installable tool, not a tutorial repo.

In under three weeks and 50 commits, the project grew through 12 build phases, from a bare TUI shell to full staging, committing, branch and stash management, interactive rebase, and a themeable config system. The habits from 8 years of data-quality discipline showed up directly in the build: a correctness pass mid-project caught a real data-corruption bug before it ever shipped.

8 yrs

Data and analytics engineering

CHANEL

Analytics Engineer, now shipping a Rust CLI in prod

Kering, Carrefour, Stellantis

Freelance missions for Saint Laurent, Balenciaga, Bottega Veneta and more

First

Open source Rust project

LinkedIn rebranding

The challenge

A tool other engineers would actually trust

A git TUI lives or dies on trust: every action touches the user's repo history, so a wrong keystroke can't silently corrupt state. Getting that right in Rust meant deciding, action by action, what's safe to run instantly versus what needs a confirmation first, and catching the cases where an operation looks harmless in the UI but isn't underneath.

That same discipline is what a data engineer brings by default: never trust an operation you haven't verified, which is exactly what caught the conflicted-file staging bug before it reached a real user.

•Staging a conflicted file with markers inside, now refused
•Destructive actions always ask first, by design
•Clippy and rustdoc clean, no lint overrides taken as shortcuts

The outcome

A public tool, shipping daily

Twelve build phases in, Richard has a working lazygit-style git TUI: staging, committing, branch and stash management, interactive rebase, mouse support, and a fully remappable, themeable config, all public on GitHub.

He's already shipping Rust in production too, a Rust CLI for Microsoft Fabric built at CHANEL to automate authentication, workspace discovery, and partition refreshes, alongside 8 years of production data engineering habits proven in Rust.

✓Interactive rebase, stash management, and conflict resolution shipped
✓A Rust CLI already running in production at CHANEL
✓A public repo he can point to, not a private tutorial exercise

Foundations

8 years of data engineering, redirected into systems Rust

Richard spent 8 years as a data and analytics engineer, most recently at CHANEL, before that embedded at Kering supporting Saint Laurent, Balenciaga, and Bottega Veneta. The instincts around data modeling discipline, CI-enforced quality gates, and reading an undocumented system before touching it carried straight into Rust. Rather than a toy CLI, we scoped a real tool from day one: a lazygit-style terminal UI for git, the kind of tool other engineers would actually install.

✓ratatui + crossterm TUI: staging, committing, branches, reflog, all keyboard-first
✓Structured, phase-based build plan, each phase reviewed and closed before the next
✓Already shipping a Rust CLI in production at CHANEL for Microsoft Fabric automation

Terminal product

Git workflows, kept inside one keyboard-first surface

ratatui · crossterm · git

Keyboard

commands + hints

ratatui

panes + popups

Git backend

read + write ops

Daily flow

stage · commit · log

Hard flows

branches · stash · rebase

no runtimereadable diffssafe actions

Deep dive

The bug a data engineer's instincts caught

Mid-build we hit a real correctness bug in the staging flow: pressing space (or a) on a conflicted file ran git add on an unmerged path, silently marking it resolved while the conflict markers were still sitting inside the file. The kind of bug that looks fine in the TUI and then corrupts a commit. Richard's fix refuses the stage and names the file, while still letting everything else get staged via an exclude pathspec, and it's careful enough to not false-positive on a lone =======, which is also a valid Markdown heading underline.

✓Staging a conflicted file with markers still inside is now refused, not silently accepted
✓Only real conflict marker pairs trigger the block, not incidental Markdown syntax
✓Everything else in the index still stages cleanly via an exclude pathspec

Correctness guard

A conflicted file cannot look resolved by accident

status · markers · pathspec

Conflict

unmerged path

Detect

marker pairs

Refuse stage

name the file

Signal over convenience

Real conflict marker pairs block only the unsafe file. A lone Markdown underline stays valid, and clean files still stage through an exclude pathspec.

TUI shipped

A public terminal tool with twelve phases behind it

Twelve build phases in and the tool already covers the workflows an engineer reaches for daily: interactive rebase, stash management, conflict resolution, mouse and keyboard-driven navigation, and a fully remappable, themeable config. The build is public and still shipping, with commits landing daily.

✓Interactive rebase: reword, drop, squash, fixup, edit, all from the TUI
✓Configurable theme system: dark/light base, named palette overrides
✓Clippy and rustdoc clean, replay-tested against real repo scenarios

Workflow surface

The next phase stays visible without hiding the current one

phases · config · replay tests

Branches

checkout + merge

Rebase

reword + squash

Stash

save + restore

Config

theme + keys

Public, phase-based build

Every workflow lands as a focused slice with replay fixtures, integration tests, and a documented boundary for what comes next.

The journey

One clear path through the build

Step 011 / 5

Week 1

Repo scaffolded: lazygit-style TUI for git, ratatui-based rendering.

Step 022 / 5

Weeks 1-2

Core git operations: staging, committing, branches, the reflog.

Step 033 / 5

Mid-build

Safety pass: refused to let a conflicted file be silently marked resolved.

Step 044 / 5

Weeks 2-3

Interactive rebase, stash management, mouse support, theming.

Step 055 / 5

Public build

12 build phases shipped, 50 commits, still active daily.

Drag to explore · Select a milestone to read the full story

Mentor perspective

Richard Lavoura had strong data and analytics experience and wanted to move closer to systems work. He applied the advice to build in visible phases, test assumptions against real workflows, and treat the TUI as a product rather than a demo. Twelve phases later, he had a public git tool with a clear path from idea to shipped software.

Max Wells

Rustify mentor