Di recente è stata inviata questa email al nostro team tecnico. Ho pensato di condividerla senza modifiche.
la risoluzione dei problemi è il servizio principale che offriamo. nel corso degli anni ho sviluppato alcune idee di alto livello al riguardo che ho trovato costantemente portano a buone soluzioni, delle quali ce ne sono sempre molte. potresti trovare queste idee utili o meno, ma ho voluto condividerle comunque: - comprendere completamente il problema. se c'è anche una piccola mancanza di chiarezza, fai domande e approfondisci. in realtà, tutte le soluzioni ai problemi derivano dall'applicazione spietata di questo unico principio. quella piccola parola che il cliente o il manuale hanno menzionato e di cui ti vergognavi di chiedere - chiedila. quella piccola riga di codice che non hai capito del tutto è probabilmente la fonte del tuo problema, non ignorarla. - parla del problema *ad alta voce* con qualcun altro. è sorprendente quante volte formulare un problema in inglese, al di fuori delle costruzioni mentali, suggerirà automaticamente una soluzione. - non debuggare mai da solo. offri un caffè o una birra a qualcuno. chiama un membro del team. è quasi sempre uno spreco di tempo debuggare da solo. una corollaria: interrompi qualsiasi cosa tu stia facendo e aiuta se sembra che qualcun altro sia bloccato su un problema. - quando c'è un problema, controlla queste cose, in questo ordine, *ogni volta*: leggi il codice, leggi il manuale, googlalo. questo è l'opposto di quello che fa la maggior parte delle persone. in altre parole "controlla prima le fonti di migliore qualità" perché le fonti di bassa qualità portano a ulteriore confusione. non posso sottolineare abbastanza l'importanza di diventare un lettore religioso di codice. - non prendere mai la strada più facile. se pensi "questo è un trucco ma..." fermati e chiedi aiuto. - non combattere il futuro. una soluzione non deve essere completa, ma dovrebbe almeno fare un passo verso la completezza. traccia le soluzioni parziali con #FIXME, #TODO, una scheda in redmine o una conversazione con un collega. - lascia tracce. se il tuo lavoro non produce artefatti che le persone possono riutilizzare o modificare, probabilmente è una soluzione temporanea e non una soluzione. creare codice modificabile è molto più facile che creare codice riutilizzabile. evita soluzioni che non siano né l'una né l'altra come la peste. - non arrabbiarti. il tuo cervello si spegne se ti arrabbi con un problema. niente di quello che facciamo ha vite attaccate, quindi alleggerisci. hai cancellato i dati. fatti una risata e poi torna a recuperarli. - evita l'adozione precoce essendo un early adopter. il modo per comprendere il punto di equilibrio tra l'avanguardia e la stabilità consolidata, ironicamente, è esplorare e comprendere a fondo le nuove soluzioni. devi essere un early adopter per capire quando evitarlo. il FUD (paura, incertezza e dubbio) non dovrebbe mai essere un motivo per evitare nuove e luccicanti soluzioni, ma una profonda comprensione dei difetti tecnici *dovrebbe essere*.