Non ottimizzare le prestazioni a caso, sia che ci sia qualcosa da fare o meno 😂 Ho appena visto un commento: > Una volta scalato, anche i bug che scrivi avranno utenti. Il mio primo lavoro dopo la laurea è stato in un'azienda, e all'inizio c'era un grande seminario di formazione per i nuovi assunti. Un giorno, ci hanno raccontato una storia: era a metà degli anni '90, il team tecnico aveva ottimizzato il tempo di caricamento del software da 5 minuti a 30 secondi. Il risultato è stato un'immediata esplosione di feedback negativi da parte dei clienti. Questa ottimizzazione del tempo di caricamento ha addirittura distrutto la cultura aziendale di quella compagnia. Infatti, prima dell'ottimizzazione, quando tutti arrivavano in ufficio, accendevano il computer e utilizzavano quei 5 minuti di caricamento per chiacchierare, bere caffè e iniziare la giornata in modo rilassato. Ora, non avevano nemmeno il tempo di alzarsi dalla scrivania che il software era già pronto, costringendoli a lavorare! Il significato di questa storia — e quella citazione sopra — non è di dirti di non migliorare le cose. Al contrario, è un promemoria: il software che costruisci non esiste solo nel PRD (documento di requisiti del prodotto) o nel pacchetto di test. È un sistema che interagisce con le persone nel mondo reale. Le persone svilupperanno abitudini attorno ad esso, troveranno soluzioni alternative (Workarounds) e persino dipenderanno da alcuni bug per scenari di utilizzo pratico. Questo è fondamentale per te come ingegnere del software: devi comprendere il vero scopo del software e come viene utilizzato nel mondo reale. Il tuo lavoro non è solo completare un mucchio di ticket forniti dal product manager, il tuo lavoro è costruire software che risolva i problemi degli utenti. Link: