Nakon dovoljno godina u softveru, počnete primjećivati obrazac: najskuplje greške ne događaju se u kodu. Ne rade ih ni juniori ni seniori zbog neznanja sintakse, lošeg frameworka ili premalo testova. Najveća greška koju rade gotovo svi developeri — uključujući i one najbolje — jest da počnu rješavati problem prije nego što su ga razumjeli.
Kako ta greška izgleda u praksi
Stigne zahtjev: "Treba nam mogućnost izvoza u Excel." Developer kima, otvara editor i tri dana kasnije isporučuje uredan, testiran modul za generiranje .xlsx datoteka. Tek tada se ispostavi da je korisnik htio poslati podatke računovođi — kojem bi CSV u privitku maila riješio stvar, a još bolje bi bilo da računovođa dobije izravan pristup. Tri dana posla za rješenje krivog problema, napisano besprijekorno.
Isti obrazac u manjim razmjerima: debugiranje simptoma umjesto uzroka ("dodao sam retry i sad radi"), optimiziranje koda koji nije usko grlo, refaktoriranje modula koji nitko ne dira, uvođenje mikroservisa jer "monolit ne skalira" — bez ijednog mjerenja koje bi to potvrdilo.
Zašto se to događa baš developerima
Postoji razlog zašto je ova greška profesionalna deformacija struke:
- Kodiranje je ugodno, razmišljanje je neugodno. Pisanje koda daje trenutan osjećaj napretka — nešto se događa na ekranu. Postavljanje pitanja "zašto ovo uopće radimo?" djeluje kao stajanje na mjestu.
- Nagrađivani smo za rješenja, ne za pitanja. Ticket zatvoren, PR mergean, feature isporučen — sve metrike mjere output. Nitko ne dobiva pohvalu za "otkrio sam da ovo ne trebamo graditi".
- Zahtjevi dolaze prerušeni u rješenja. Korisnici i menadžeri rijetko opisuju problem; opisuju rješenje koje su sami zamislili ("dodajte checkbox ovdje"). Prihvatiti to zdravo za gotovo znači graditi tuđu improvizaciju.
- AI je ovo pogoršao. Kad generiranje koda košta gotovo nula, iskušenje da se odmah krene "nešto raditi" veće je nego ikad. Sada možete krivo rješenje izgraditi deset puta brže.
Cijena koja se ne vidi odmah
Krivi kod se da popraviti. Krivo shvaćen problem proizvodi kaskadu: pogrešan feature → pogrešan API oko njega → korisnici koji se naviknu na zaobilazno rješenje → migracija koju nitko ne želi platiti. Studije o cijeni promjene zahtjeva stare su desetljećima i sve kažu isto — greška u razumijevanju problema košta višestruko više od greške u implementaciji, jer se otkrije kasnije.
Kako se ova greška izbjegava
Nekoliko navika koje razlikuju developere kojima se vjeruje od onih kojima se samo dodjeljuju zadaci:
- Pitajte "koji problem ovo rješava?" — naglas, svaki put. Ako odgovor ne postoji ili glasi "tako je traženo", stanite. To pitanje je neugodno točno onoliko koliko je korisno.
- Ponovite problem svojim riječima prije rješenja. "Ako sam dobro shvatio, računovođa svaki mjesec ručno prepisuje ove podatke i tu gubimo dva sata?" — pola nesporazuma umre na ovoj rečenici.
- Tražite najmanji test razumijevanja. Prije tri dana developmenta — skica, prototip, ručno odrađen proces, jedan SQL upit poslan mailom. Ako jeftina verzija ne pogađa potrebu, skupa ne bi bila bolja.
- Kod debugiranja: reproducirajte prije nego popravljate. Fix bez reprodukcije je pogodak u mraku koji povremeno slučajno uspije — i time ojača lošu naviku.
- Mjerite prije optimiziranja. Profiler, ne intuicija. Uska grla su gotovo uvijek tamo gdje ih ne očekujete.
Zaključak
Vještina pisanja koda nikad nije bila dostupnija — dijeli je svaki developer i svaki AI agent. Vještina koja ostaje rijetka je disciplina zadržati se u problemu dovoljno dugo da rješenje postane očito. Sljedeći put kad osjetite poriv da odmah otvorite editor, sjetite se: nitko se nikad nije požalio da je problem prerazumio.
