Ne pas optimiser les performances à tort et à travers 😂 Je viens de voir un commentaire : > Une fois que vous êtes à l'échelle, même les bugs que vous avez écrits auront des utilisateurs. Mon premier emploi après l'université était dans une entreprise où il y avait un grand séminaire de formation pour les nouveaux employés. Un jour, ils nous ont raconté une histoire : c'était au milieu des années 90, l'équipe technique avait optimisé le temps de chargement du logiciel de 5 minutes à 30 secondes. En conséquence, les retours négatifs des clients ont explosé instantanément. Cette optimisation du temps de chargement a en fait détruit la culture d'entreprise de cette société. Avant l'optimisation, tout le monde arrivait au bureau, allumait son ordinateur et profitait de ces 5 minutes de chargement pour discuter, prendre un café et commencer la journée de manière détendue. Et maintenant, avant même qu'ils aient eu le temps de se lever de leur bureau, le logiciel était déjà prêt, les pressant de se mettre au travail ! La signification de cette histoire — ainsi que la citation ci-dessus — n'est pas de vous dire de ne pas améliorer les choses. Au contraire, c'est un rappel : le logiciel que vous construisez n'existe pas seulement dans le PRD (document de spécifications produit) ou dans les suites de tests. C'est un système qui interagit avec les gens dans le monde réel. Les gens développeront des habitudes autour de lui, trouveront des solutions de contournement (Workarounds), et même dépendront de certains bugs pour des scénarios d'utilisation réels. C'est crucial pour vous en tant qu'ingénieur logiciel : vous devez comprendre la véritable utilisation du logiciel et comment il est utilisé dans le monde réel. Votre travail n'est pas de remplir une liste de tickets fournie par le chef de produit, votre travail est de construire un logiciel qui résout les problèmes des utilisateurs. Lien :