Da eseguire task a possedere problemi

Per anni ho pensato che il lavoro di un buon engineer fosse fare bene ciò che ti chiedono: ticket chiusi, PR pulite, stima rispettata.

Poi, lavorando sull’intero prodotto — frontend, backend, pagamenti, supporto — ho capito che il pezzo difficile non è scrivere il codice. È capire quale problema stai risolvendo, e per chi.

Ownership non è fare tutto da soli

Possedere un problema significa:

• conoscere i vincoli reali (tempo, rischio, utenti, business);
• proporre trade-off invece di aspettare specifiche perfette;
• misurare se la soluzione funziona dopo il deploy.

Il codice resta centrale. Ma diventa uno strumento, non il fine.

Una domanda utile

Prima di aprire l’editor, oggi mi chiedo:

Se questa cosa non esistesse, quale decisione o comportamento umano cambierebbe?

Se non ho una risposta chiara, probabilmente sto costruendo infrastruttura per un bisogno ancora confuso.