Não brinque e otimize o desempenho 😂 Acabei de ver um comentário: > Uma vez escalados, até os bugs que você escreveu terão usuários. Meu primeiro emprego depois da faculdade foi em uma empresa onde havia um grande seminário de integração para novos funcionários. Um dia, eles nos contaram uma história sobre meados dos anos 90, quando a equipe técnica otimizou o tempo de carregamento do software de 5 minutos para 30 segundos. Como resultado, o feedback negativo dos clientes explode instantaneamente. Essa otimização do tempo de carregamento acabou destruindo a cultura corporativa daquela empresa. Acontece que, antes da otimização, todos iam ao escritório, ligavam o computador e usavam os 5 minutos de carregamento para conversar, tomar café e começar um dia relaxante. E agora, antes que possam se levantar das mesas, o software está pronto para funcionar neles! A moral da história — e da citação acima — não é dizer para você não melhorar as coisas. Em vez disso, é um lembrete de que o software que você constrói não existe apenas em um PRD (Documento de Requisitos do Produto) ou suíte de testes. É um sistema que interage com pessoas no mundo real. As pessoas criam hábitos em torno disso, desenvolvem soluções alternativas e até dependem de certos bugs para cenários práticos. Isso é crucial para você como engenheiro de software: você deve entender para que o software realmente é usado e como ele é usado no mundo real. Seu trabalho não é preencher um monte de tickets do gerente de produto, seu trabalho é construir softwares que resolvam problemas de usuários. Links: