Amici devs, qualche giorno fa mi sono imbattuto in questo post:
https://www.radicalsimpli.city/
Se vi state annoiando sotto l’ombrellone (o in ufficio) vi consiglio di dedicargli 10 minuti del vostro tempo, perché tratta una tematica abbastanza trasversale e che ci riguarda un po’ tutti: la nostra fatale attrazione per la complessità.
Al posto che combattere la complessità, la cerchiamo. Al posto che concentrarci sul trovare la soluzione migliore per il domino del nostro problema, andiamo dritti sulla soluzione più complessa.
E allora quello che dovrebbe richiedere qualche minuto richiede ore, e succede che un progetto che dovrebbe richiedere mesi finisce per richiedere anni, e al posto che 2 risorse ne servono 8. Ma perché?
Perché siamo umani, e pensiamo di essere razionali al 100% in ogni nostra decisione ma in realtà ci lasciamo fuorviare da quello che fa più figo su LinkedIn, da quello di cui parlano gli youtuber del settore, da quello che suggerisce l’AI di turno, da quello che ci da maggiore senso di sfida. Più è complesso e altisonante, meglio è. Ma questo approccio difficilmente ci porterà a trovare la soluzione più adatta al nostro caso.
Ci diciamo sempre che “there’s no silver bullet”, però poi fatichiamo a metterlo in pratica e ci troviamo a realizzare un software ad uso interno con 200 utenti usando lo stesso stack di Netflix, con tutto ciò che consegue.
Sottovalutiamo infinitamente l’impatto che queste scelte avranno nel medio e lungo periodo, e infatti spesso queste scelte finiscono per soffocare i progetti ancor prima del go live (soprattutto se mescolate a cattivo management ecc).
Perché allora al posto di seguire la corrente non usiamo la nostra esperienza per trovare l’approccio migliore volta per volta? Perché ci dobbiamo sentire inferiori se scegliamo la semplicità?
Pochi giorni fa ascoltavo un podcast in cui DHH racconta che il loro ultimo progetto (Campfire, una alternativa a Slack/Teams) si basa su SQLite, perché fino a 10k utenti per istanza regge bene, e semplifica enormemente la portabilità e la distribuzione (fattori critici in questo caso) del software.
Boom.
Questo è essere 10x developer: fare SCELTE oculate, “controcorrente” se vogliamo, ma che si traducono in velocità, semplicità di manutenzione, riduzione dei costi, in altre parole, vantaggio competitivo.
In questo modo ci si può concentrare su “what moves the needle”, quello che fa la differenza, quello che genera un valore…e non sui vari ammennicoli che compongono il nostro stack e che si spaccano a turno.
Questo non significa realizzare soluzioni non scalabili o non dedicare il giusto tempo a colmare il debito tecnico, significa solo vedere la complessità per quello che, nel nostro lavoro, davvero è: un qualcosa da contenere in tutti i modi, e non qualcosa da ricercare.