Ho passato un pomeriggio a decidere se chiamarla `userData` o `user_data`. Ecco il trauma.
Una riflessione non richiesta sul bikeshedding, il naming delle variabili, e perché le decisioni piccole sono quelle che ci deragliano di più.
Il task era stimato due ore: aggiungere un campo a un oggetto. L'ho consegnato il giorno dopo. Non per il campo. Per il nome del campo. `userData` o `user_data`? Il file era JavaScript, quindi camelCase era la scelta ovvia. Poi ho ricordato che il backend usa snake_case, e l'ho aperto di nuovo.
La legge di Parkinson applicata a una variabile
C'è una versione informale della legge di Parkinson per cui il tempo speso a discutere una decisione è inversamente proporzionale alla sua importanza reale. Il refactor dell'architettura dei permessi l'ho approvato in una call di dodici minuti. Il nome di questo campo mi ha tenuto sveglio fino all'una. Il cervello, messo davanti a un problema veramente complesso, si arrende e delega. Messo davanti a un problema stupido e ben definito, ci si butta a capofitto — perché lì, finalmente, una risposta giusta esiste.
Ho aperto tre repository per vedere cosa avevo fatto in passato
Non ero coerente nemmeno con me stesso di sei mesi fa. In un repository c'era `userData`, in un altro `user_data`, nel terzo — inspiegabilmente — `userdata` tutto attaccato, senza nessuna separazione, come se in quel momento avessi semplicemente smesso di credere nei confini tra le parole. Non ho trovato una risposta. Ho trovato la prova che il problema non è mai stato scegliere, ma accettare che qualsiasi scelta sarebbe stata ugualmente arbitraria e ugualmente difendibile per i prossimi dieci minuti di dibattito interiore.
Alla fine ho scelto `userData`. Non perché fosse meglio. Perché era le 18:47 e volevo andare a fare la spesa. Il codice funziona. Nessuno, in produzione, si è mai accorto della differenza. Io me la ricorderò per sempre.