Pair debugging e ruoli

In parole semplici

Due cervelli su un bug, se ben coordinati, valgono molto più del doppio. Ma “fare debug in due” senza ruoli si trasforma in una persona che digita e una che guarda. Il pair debugging struttura la sessione con ruoli che ruotano, timer e un taccuino condiviso.

Parole nuove

• driver: chi tiene tastiera e mouse.
• navigator: chi osserva, suggerisce, tiene il quadro generale.
• scriba: chi tiene il taccuino di sessione.
• rotazione: cambio dei ruoli a intervalli definiti.

Cosa impari

• Strutturare una sessione di pair debugging.
• Distinguere driver e navigator (e perché lo scriba aiuta).
• Usare timer e rotazione per evitare squilibri.

I tre ruoli

Driver

Tiene tastiera e mouse. Esegue. Scrive codice, lancia comandi, naviga DevTools. Non decide da solo: ascolta il navigator, propone, esegue le prove decise insieme.

Trappola: il driver “in flusso” che dimentica il navigator. Antidoto: parla mentre fa, anche solo “ora apro Network”, “questo log dice X”.

Navigator

Non tocca tastiera. Osserva lo schermo, tiene il quadro generale, formula la prossima ipotesi. Sussurra il taccuino: “abbiamo provato A e B, non C”. Domanda dirette: “perché stai aprendo questo file?”.

Trappola: il navigator passivo che guarda senza intervenire. Antidoto: il driver chiede esplicitamente conferma ad ogni passo.

Scriba (opzionale, ma utile in sessioni lunghe)

Tiene il taccuino. Annota ipotesi, prove, esiti. Cattura screenshot. Senza scriba, dopo 40 minuti la sessione perde memoria.

In coppie di due, lo scriba è il navigator stesso. In gruppi di tre o quattro, è un ruolo separato.

Rotazione con timer

Pomodoro è ottimo: 25 min driver + 5 min pausa + scambio.

Schema 90 minuti:

1. 25 min: A driver, B navigator. Pausa 5 min.
2. 25 min: B driver, A navigator. Pausa 5 min.
3. 25 min: rotazione + retrospettiva 5 min.

Senza rotazione, il driver si stanca e il navigator si annoia. Con rotazione, entrambi rimangono freschi.

Apertura di sessione

Cinque minuti per allinearsi:

1. Stato attuale del bug: cosa sappiamo, cosa non sappiamo.
2. Obiettivo della sessione: cosa vogliamo decidere/scoprire.
3. Tempi: durata e rotazione.
4. Taccuino: dove scriviamo.
5. Decisioni di fix: chi decide cosa committare.

Senza apertura, due persone con due idee diverse perdono i primi 30 minuti a discutere implicitamente.

Chiusura di sessione

Cinque minuti per chiudere:

1. Riassumere cosa abbiamo scoperto.
2. Aggiornare ticket / taccuino con stato finale.
3. Pianificare il prossimo passo (sessione, commit, review).
4. Note di processo: come è andata la collaborazione?

Quando il pair NON funziona

• Bug troppo banale: una persona basta, l’altra si annoia.
• Squilibrio competenze estremo: rischio che diventi insegnamento, non debug. Se è insegnamento, dichiaralo apertamente.
• Conflitto di stile: due driver impongono cambi reciproci → caos.
• Stanchezza: dopo 3 ore, due cervelli stanchi peggiorano la sessione.

Pair remoto

Strumenti:

• VS Code Live Share o JetBrains Code With Me: editor condiviso.
• tmate o tmux + ssh: terminale condiviso.
• Zoom/Meet con screen share: minimo indispensabile.

Regole extra in remoto:

• Audio sempre acceso.
• Cambio driver: chi prende tastiera lo dice esplicitamente.
• Chat per appunti veloci.
• Connessione stabile: una sessione interrotta è pari distruttiva.

Mob debugging (3+ persone)

Variante con 3-5 persone:

• Un driver, più navigator, uno scriba.
• Rotazione del driver ogni 10-15 min.
• Il driver dichiara cosa fa, i navigator approvano o propongono alternativa.

Utile per bug critici che coinvolgono più componenti del sistema (frontend + backend + infra).

Esercizio guidato

Con un compagno (o due) di corso:

1. Scegliete un bug riproducibile.
2. Aprite sessione: stato, obiettivo, timer (25 min).
3. Iniziate: A driver, B navigator. Scrivete tutto nel taccuino.
4. Rotazione: 25 min B driver, A navigator.
5. Chiudete sessione: 5 min riassunto + retrospettiva.

Misurate: avete progredito più che da soli? Cosa ha funzionato? Cosa cambiereste?

Errori frequenti del principiante

• Driver “egoista”: corre senza spiegare. Navigator inutile.
• Navigator “passivo”: guarda. Tanto vale stare da solo.
• Saltare il timer: una persona resta driver 3 ore.
• Saltare il taccuino: a fine sessione, niente memoria.