Nie optymalizuj wydajności bez powodu 😂 Właśnie zobaczyłem komentarz: > Gdy tylko osiągniesz skalę, nawet błędy, które napisałeś, będą miały użytkowników. Moja pierwsza praca po ukończeniu studiów była w firmie, gdzie na początku odbyło się wielkie szkolenie dla nowych pracowników. Pewnego dnia opowiedziano nam historię: to było w połowie lat 90-tych, zespół techniczny zoptymalizował czas ładowania oprogramowania z 5 minut do 30 sekund. W rezultacie negatywne opinie klientów wybuchły natychmiast. Ta optymalizacja czasu ładowania zniszczyła kulturę korporacyjną tej firmy. Okazało się, że przed optymalizacją, wszyscy przychodzili do biura, włączali komputery i wykorzystywali te 5 minut na rozmowy, picie kawy, rozpoczynając w ten sposób lekki dzień. A teraz, zanim zdążyli wstać od biurka, oprogramowanie już było gotowe, zmuszając ich do pracy! Przesłanie tej historii — oraz powyższy cytat — nie oznacza, że nie powinieneś poprawiać rzeczy. Wręcz przeciwnie, to przypomnienie: oprogramowanie, które tworzysz, nie istnieje tylko w PRD (dokumencie wymagań produktu) lub zestawie testów. To system, który w rzeczywistym świecie wchodzi w interakcje z ludźmi. Ludzie będą wokół niego tworzyć nawyki, opracowywać obejścia (Workarounds), a nawet polegać na niektórych błędach w rzeczywistych scenariuszach użytkowania. To jest niezwykle ważne dla Ciebie jako inżyniera oprogramowania: musisz zrozumieć prawdziwe zastosowanie oprogramowania i sposób jego użycia w rzeczywistym świecie. Twoja praca nie polega na realizacji zestawu zadań (Tickets) od menedżera produktu, Twoja praca polega na budowaniu oprogramowania, które rozwiązuje problemy użytkowników. Link: