Scrivo codice per lavoro da 20 anni… Ecco 256 cose che ho imparato

Sono passati solo 20 anni. Ho cominciato in una piccola web agency della Brianza grazie ad Alessandro e Livio, con cui ho condiviso diversi anni di lavoro. In questi 20 anni ho lavorato per una big della Silicon Valley, il più grande sito di annunci d’Italia, ho girato il mondo, e ancora oggi mi sto divertendo parecchio.

Qualcosa di buono in questi 20 anni di sicuro l’ho combinato.

Di quel buono che ho imparato, ti regalo 256 consigli: molti sono ovvietà, altri sono meno ovvi, altri sono semplicemente constatazioni personali. Magari a volte mi ripeterò un po’ e non sempre applico questi consigli nel mio lavoro di tutti i giorni, ma il titolo clickbait doveva fartelo capire, no?

Magari in futuro approfondirò qualcuno dei temi proposti… Se hai tempo leggi anche questo articolo, che mi ha ispirato nel creare il mio.

Cose che ho imparato scrivendo codice…

1. Meno codice scrivi, meglio è
2. Il miglior codice è quello che non devi scrivere (o che hai dovuto cancellare)
3. Se hai capito come risolvere un problema, il codice che scriverai sarà banale
4. Leggere i test è il miglior modo che hai per capire il codice scritto da un’altra persona
5. Se devi lavorare con codice scritto da qualcun altro e i test non ci sono, una sessione di pairing dove scrivete dei test sarà essere utile a entrambi
6. Se i test non ti hanno ancora salvato il culo, lo faranno presto
7. Visto che i test ti salveranno il culo, devono farlo nel minor tempo possibile
8. Coverage al 100%? Una cazzata
9. La piramide dei test non è una cazzata
10. Come lo testi un cronjob? Ecco.
11. Testa i casi limite, sono quelli che ti faranno perdere il sonno
12. Se un bug si ripresenta più volte, scrivi un test per evitarlo
13. Piuttosto che avere un test “flaky” meglio non averlo del tutto quel test
14. Code review, tempo “alla lavagna” e pairing sono momenti importantissimi
15. Il tempo che spendi scrivendo la descrizione di un ticket o di una PR non è sprecato: ti aiuta a suddividere il problema (prima) e a rifletterci un’ultima volta (poi)
16. Quando scrivi il testo di un ticket o di una PR fatti aiutare dagli LLM, ma rileggiti sempre almeno una volta
17. A volte fissare il muro per un po’, fare una doccia, portare fuori il cane (o simili) saranno gli unici modi che hai per risolvere un problema
18. Impara il prima possibile a fare stime precise dei tuoi task (su questo sono diventato bravo solo di recente)
19. Task piccoli sono più facili da stimare: divide et impera
20. Impara a dare nomi precisi alle “cose” (variabili, classi, tipi, funzioni, interfacce…)
21. I log non mentono mai
22. Impara a leggere, a greppare, e a filtrare i log e gli stacktrace: è obbligatorio
23. Non sottovalutare mai un warning
24. Un log rotto è peggio di un log mancante
25. “A/B testing tutta la vita”: che parlino i numeri
26. “Feature toggling tutta la vita”: almeno dormi sereno
27. Ok le feature flag, ma se per attivare una funzionalità ti servono 3 feature flag, beh…
    Hai sbagliato tutto
28. “Finito è meglio che perfetto”
29. Sarà anche finito, ma devi farlo diventare quasi perfetto il prima possibile
30. Rilasciare spesso è un must
31. Ogni deploy senza monitoring è un atto di fede
32. Pipeline di CI/CD infinite? Red flag
33. Test troppo instabili? Red flag
34. Build in locale di durata infinita? Red flag
35. Codice prolisso senza motivo? Red flag
36. Tooling lento e troppo complesso? Red flag
37. L’onboarding di un nuovo sviluppatore sul progetto è complesso e lungo? Red flag
38. Automatizza il più possibile (salvataggi, linting, ecc…)
39. Se una cosa va fatta più di 2 volte, rendila uno script
40. Quando fai review di una PR, leggi anche quello che non è cambiato
41. Se una variabile cambia troppe volte, hai un problema
42. Le PR minuscole/quickwin danno molta soddisfazione e si sommano nel tempo migliorando la qualità generale della codebase. Non farti scappare l’occasione di un fix veloce…
43. La banda, la CPU e la memoria infinita non esistono, anche se a volte sembra sia così
44. La latenza di rete esiste. Crea il tuo software come se il backend fosse dall’altra parte del mondo
45. La ricorsione è talmente affascinante che, per descriverla, finisci per usare la ricorsione
46. Quella funzione ricorsiva così figa… Beh, meglio riscriverla con un for. I tuoi colleghi ti ringrazieranno
47. Piccolo è bello: i file che crei devono essere piccoli, le funzioni che scrivi devono essere piccole, le PR devono essere piccole
48. Le immagini in una PR aiutano più di mille parole. Un video in una PR aiuta più di 1000 immagini
49. Un codice sicuro è spesso un codice noioso. Meglio noioso che bucato
50. Scrivi codice che capirai anche tra 6 mesi, dopo una nottata di merda
51. Il tuo codice deve essere leggibile come un racconto breve: deve avere un inizio, raccontare la storia di quello che fa e finire in modo chiaro
52. La documentazione automatica è importante, ma non deve diventare un’ossessione
53. Lavora con linguaggi fortemente tipizzati, ma divertiti con linguaggi dalla tipizzazione debole (se sai quel che stai facendo)
54. Cerca di scrivere funzioni pure
55. Evita le dipendenze circolari
56. Ogni tanto misura cronometro alla mano le performance del tuo codice
57. Se un’operazione richiede più di mezzo secondo, sappi che l’utente che l’aspetta si è già rotto le scatole
58. Se crei pagine web, devono essere responsive
59. La dependency injection è una bella cosa
60. I commenti nel codice, anche quelli “banali”, servono sempre a qualcosa, non mi convincerai del contrario
61. Vedi sopra. A volte i commenti banali mi servono come “ancore”
62. Non ti fidare al 100% dei commenti che trovi nel codice, se non li hai scritti tu
63. Le variabili o costanti che indicano un’unità di misura devono contenere un riferimento all’unità usata. const DOG_WEIGHT_KG = 5;
64. Se usi una reduce() (o un suo equivalente) la devi spiegare a chi verrà dopo di te, non me ne frega nulla di quanto sia semplice
65. Forse (in realtà senza forse) quella reduce() può diventare un for
66. “Simplicity is the ultimate sophistication” (cit.), scrivi codice semplice. Sempre.
67. Vedi sopra. DRY/KISS/YAGNI/SRP/PENGY. Dovrebbero essere il tuo mantra
68. Evita acronimi inventati. Non stai scrivendo codice per i militari
69. Le eccezioni vanno gestite. Sempre
70. Mettere tutto il codice dentro un try/catch non è gestire le eccezioni
71. Un bugfix senza test è solo una teoria
72. Chi misura il tuo lavoro in righe di codice, quadratini verdi su github o altre cose simili è un coglione
73. Se proprio devi, misura il tuo lavoro in righe di codice eliminate
74. Nel 2030 probabilmente non scriveremo molto codice, spiegheremo alle macchine come tradurre requisiti in codice, faremo code review e “pairing” con le macchine. Impara ad usare gli strumenti AI oggi.
75. C’è una libreria per quasi tutto. Non reinventare la ruota, se puoi
76. L’autenticazione è difficile. Se puoi non scriverla da zero
77. Prima di usare una libreria assicurati di aver capito quello che fa e come lo fa. Assicurati che l’ultimo commit sul repo non sia stato fatto 10 anni fa
78. Se una libreria ha 10K stelle ma 200 issue aperte da 2 anni… passa oltre
79. A fine mese incassa lo stipendio e paga un po’ di debito tecnico se puoi
80. Google e StackOverflow erano i tuoi migliori amici. Ora ci sono gli LLM
81. Puoi usare tutti gli LLM del mondo, ma senza basi forti non vai da nessuna parte
82. Il codice evolve, migliora (o peggiora) con il tempo. Il codice che peggiora col tempo è codice morto. Chiedete a Charles Darwin cosa ne pensa…
83. 2 spazi (al massimo 4), nessuna tab
84. Quelli che “no if”… Boh. Vedi https://www.defusetheifstrategy.com/
85. “Talk is cheap, show me the code” (cit.)
86. Un font “per programmatori”, con le legature se possibile, ti cambia la vita, vedi https://www.programmingfonts.org/
87. Cloud bello, ma il ferro spesso costa meno
88. Non sottovalutare mai SQLite
89. Non sottovalutare mai Redis
90. Usa un ORM, ma…
91. Usa un ORM solo quando conosci SQL
92. Se una query è lenta, chiediti se il problema è negli indici o nella query stessa
93. I bug più gravi non sono quelli che fanno crashare il software, ma quelli che fanno perdere soldi
94. Il codice che dipende dal fuso orario, dall’i18n o dalle date prima o poi ti tradirà
95. Se una PR contiene più di 15 file cambiati, spezzala in più PR
96. Impara almeno un linguaggio funzionale
97. Fai qualche leetcode ogni tanto. Rinfresca le tue basi…
98. Forza i conventional commits sui tuoi repo
99. Impara bene almeno un paio dei framework più utilizzati nel tuo ambito
100. Monoliti VS Microservizi: meglio un monolite fatto bene che microservizi fatti “perché fa figo”, meglio un monolite quasi decente che microservizi quasi decenti. E la maggior parte delle volte i microservizi non ti servono davvero
101. Ogni microservizio deve poter fallire senza compromettere nient’altro che se stesso
102. Se non hai bisogno di un message broker, non usarlo. Aggiunge complessità, latenza e problemi che prima non avevi
103. Se usi un message broker, ogni consumer deve poter crashare senza far crollare tutto
104. Blockchain? No
105. Se annidi 4 for ti serve un ripasso di questo
106. Le cose si spaccano nei modi più imprevedibili
107. A meno di lavorare in ambiti specifici, se spacchi qualcosa non ammazzi nessuno, rimboccati le maniche e risolvi il tuo problema
108. Modali, finestre, sidepanel, ecc… nel browser? Fanno schifo. Prima te ne rendi conto, meglio è
109. Impara Docker, se non lo conosci
110. Impara a creare e gestire un cluster kubernetes, anche piccolo. Usa minikube
111. Fail Fast, Circuit Breaking… Se non sai cosa sono… Studiali
112. Prima o poi ti servirà un sistema di rate limiting. Meglio prima
113. Un software veloce e fluido vale più di mille funzionalità inutili
114. Il codice legacy spesso è codice noioso che funziona
115. Non scrivere codice per “farti notare” o per sembrare “smart”, scrivilo per essere utile
116. Il tuo ambiente di sviluppo locale deve essere facilmente riproducibile (ad esempio, usa docker-compose)
117. Una volta mergiato, il tuo codice diventa di tutti
118. Una volta mergiato, il codice di altri diventa anche tuo
119. Se una cosa è configurabile, qualcuno la configurerà male
120. I parametri di configurazione vanno documentati, non indovinati
121. Il codice non fixerà mai un problema a livello di prodotto o di business
122. L’accessibilità non è una feature: presto sarà un requisito legale
123. La privacy non è una feature: è un requisito legale
124. Se hai paura di deployare, hai sbagliato qualcosa prima
125. Non fare refactor se non hai test a supporto

Cose che ho imparato lavorando con le persone…

126. A volte i migliori sviluppatori sono arroganti sul lavoro, ma fuori dall’ufficio sono persone molto umili
127. Non sei pagato per scrivere codice. Sei pagato per risolvere problemi
128. Se ricevi notifiche slack ogni 5 minuti, non stai lavorando
129. Un buon mentore è qualcuno che ti fa domande, non che ti dà risposte
130. Se pensi di essere arrivato (o arrivata), ho una brutta notizia per te…
131. C’è sempre spazio per imparare meglio l’inglese
132. Se sai un’altra lingua oltre all’italiano e all’inglese… Meglio!
133. Le promozioni non vanno solo a chi le merita. Vanno a chi le sa chiedere
134. Se lavori da remoto, devi essere un eccellente scrittore
135. Non lavorare in pigiama. Il cervello lo capisce
136. Il micromanagement a distanza è ancora peggio di quello in ufficio. Non accettarlo
137. Un team pieno di “brillanti solisti” fa schifo
138. Dire: “non lo so” non è un peccato mortale
139. Ok la storia del rilascio di venerdì… Ma non rilasciare neanche di lunedì mattina. Tutti sono ancora mezzi rincoglioniti
140. Parla con le persone anche senza un motivo tecnico. Fa bene a te e a loro
141. Un buon manager protegge il team
142. Le pause vanno programmate. Altrimenti non le fai
143. Scrivere codice da solo è facile. Farlo con altri è il vero mestiere
144. Essere un/una manager anche solo decente è difficilissimo
145. Un cattivo manager può rovinare un ottimo team nel giro di qualche mese
146. C’è chi diventa manager solo perché è al posto giusto nel momento giusto, non pensare che il tuo manager abbia meriti particolari
147. Non usare lo stesso avatar per dieci anni. Aggiorna anche la tua immagine, ogni tanto
148. Più le aziende parlano di Diversity & Inclusion, meno la praticano davvero
149. Le “risorse umane” sono pagate dall’azienda: lavorano per l’azienda, non lavorano per te
150. Se hai delle questioni sul lavoro e pensi possa essere utile, non aver paura di chiedere un consiglio ad un legale esperto in diritto del lavoro
151. Stai attento al collega simpatico che racconta sempre barzellette. Le cose sono due: o è un coglione o vuole fregarti. A volte entrambe le cose.
152. Lavorare tanto non è lavorare bene
153. Lavorare bene non significa non sbagliare mai
154. Cambia qualcosa nel tuo CV una volta a settimana. Anche una cosa piccolisima
155. Essere puntuali e mantenere le promesse fatte è metà del lavoro
156. Fare domande scomode ti renderà antipatico
157. Fare domande scomode è necessario
158. Il gossip è imprescindibile: “sapere è potere”
159. Se fai gossip, sarai oggetto di gossip a tua volta. È un sacrificio necessario
160. Ci sono persone “chiave” in ogni azienda. Bisogna farsele amiche il prima possibile
161. Non dire sempre di sì
162. A volte devi dire di sì anche se non vuoi
163. Se ti tocca assumere qualcuno per lavorare con te, cerca di valutarne attentamente anche le soft skill, è un errore che ho fatto solo una volta, ma che sto pagando ancora oggi
164. Se lavori su web, non usare lo stesso browser che usano tutti i tuoi colleghi
165. Non fare “blaming” sulle persone, fallo sui processi
166. Non serve un ufficio per lavorare bene insieme
167. Andare in ufficio ti rende “visibile”
168. Se lavori da remoto, fai in modo che il team e l’azienda “ti vedano” e sappiano su cosa stai lavorando
169. Come rendersi visibile? Le piccole cose si sommano: sii educato/a, disponibile e anche un po’ strano/a se lo sei nella vita normale
170. Vai alle conferenze, ai meetup, agli eventi per sviluppatori, conosci e parla con le persone
171. Parlare alle conferenze è meno difficile di quel che sembra
172. I fullstack developer non esistono più, non ti definire tale
173. Alle aziende i fullstack piacciono perché hanno la sensazione di pagare uno sviluppatore per averne 2. In realtà ne hanno 0.90
174. Non ti definire mai “smanettone”: è svilente
175. Le interruzioni sono velenose. “Napo hai un momento?” e puff… È passata un’ora
176. Se lavori con persone in diversi fusi orari, sfrutta questa cosa a tuo vantaggio: apri le PR quando stacchi, ad esempio, così la mattina troverai commenti e/o approvazioni già pronte
177. Prima o poi, tutti si ritrovano un collega tossico. Impara a gestirlo
178. Se una discussione tecnica dura più di 10 messaggi in chat, organizza una riunione per parlarne
179. Rispetta gli standard e i processi del team, specie se sei nuovo
180. Chiedi aiuto quando serve
181. Riconosci il merito degli altri, ma pretendi che gli altri facciano altrettanto con te
182. Non prendere le critiche al codice come critiche personali
183. Se una call di 20 minuti può essere un’email, scrivila
184. Se un’email può essere una call di un paio di minuti, fai quella call
185. Le call senza agenda sono una perdita di tempo
186. Gli utenti non leggono, al massimo scansionano
187. Se l’utente non riesce a fare una cosa col tuo software, la colpa è tua
188. Gli utenti riusciranno a fare cose che non avevi previsto con il tuo software
189. Le dimissioni di un collega possono dirti molto sullo stato dell’azienda
190. Se uno standup dura più di 15 minuti… Protesta!
191. Se i meeting tecnici sono pieni di gente non tecnica… Protesta!
192. L’azienda per cui lavori è importante, ma il tuo network lo è di più
193. Se un collega viene lasciato solo a gestire una crisi, il team ha fallito
194. Il silenzio prolungato in un team è quasi sempre un segnale di problemi
195. Se tutti sono d’accordo, probabilmente nessuno ha detto quello che pensa davvero
196. Essere chiari è più importante che essere gentili
197. Se una regola la rompi ogni volta, è sbagliata. Cambiala o eliminala
198. Se una regola è lì “perché si è sempre fatto così”… Trova e risolvi il problema che l’ha introdotta.
199. Se una regola sembra assurda, c’è sicuramente una storia divertente dietro…
200. Il team non è la somma dei membri, ma la qualità delle relazioni tra loro
201. Le lamentele ripetute sono un problema di leadership
202. Non aspettare di “sentirti pronto” per cambiare lavoro. Non lo sarai mai al 100%
203. Quando fai una domanda tecnica, spiega anche cosa hai già provato. Le persone ti aiuteranno più volentieri
204. Molti usano scrum come scusa per non lavorare
205. Se proprio devi usare scrum, adattalo al tuo team, non adattare il tuo team a scrum
206. Uno scrum master è più utile di quello che pensi

Cose che ho imparato lavorando con i computer…

207. Usa più di uno schermo
208. Non usare più di due schermi
209. Se puoi, usa un monitor con refresh rate elevato. I tuoi occhi ringrazieranno
210. Usa una scrivania regolabile in altezza (manuale va bene, elettrica meglio)
211. Usa una sedia di qualità
212. Usa una tastiera di qualità, non è un vezzo
213. Non usare una tastiera meccanica 40%, quello sì che è un vezzo
214. Usa un mouse di qualità (e saluta il tunnel carpale)
215. Sulla macchina che usi per lavoro devi avere i pieni poteri (root o admin)
216. Pretendi hardware di un certo livello, se devi usarlo per lavoro
217. La RAM del tuo computer non è mai abbastanza
218. Le luci RGB non ti fanno scrivere codice migliore
219. SSD. Al massimo sugli HDD facci i backup
220. Meglio un editor semplice che un IDE con 11000 funzioni che non userai mai
221. Cerca di conoscere molto bene l’IDE o l’editor che stai usando… Soprattutto le scorciatoie da tastiera.
222. Meno usi il mouse, meglio è
223. Le cuffie? Le migliori che riesci a permetterti. Personalmente ho una preferenza per le Sony, con cavo.
224. Non puoi usare le cuffie?  Usa una soundbar!
225. Usa un microfono e una webcam di qualità: è un gesto di educazione e serve davvero!
226. Non dovresti usare il computer aziendale per cose personali (e viceversa), ma comunque succederà
227. Se l’azienda per cui lavori è minimamente strutturata, installerà uno spyware sul tuo computer aziendale, spacciandolo per “gestione remota”. Comportati di conseguenza
228. Schermo, browser e terminale devono essere “distraction free”
229. “È sempre colpa del DNS” (cit.)
230. Wireless è comodo, ma non ho mai dovuto ricaricare un cavo… 😂
231. Non salvare password nei browser. Fallo nel password manager
232. Se il tuo router ha più di 5 anni, probabilmente il vicino 70enne ha un Wi-Fi più veloce del tuo
233. Se ti sei organizzato bene non hai bisogno di un backup diretto del disco del tuo computer: tutto sarà a portata di NAS (o di Cloud) in caso di problemi
234. Devi avere sempre a disposizione una VPN, anche se non la usi mai
235. Usa una VPN quando ti connetti a reti pubbliche
236. Non sottovalutare mai il potere di un clipboard manager
237. Un computer ben tenuto dura anni. Uno incasinato è vecchio dopo 6 mesi
238. Se ti muovi spesso, compra un secondo alimentatore e lascialo fisso nello zaino
239. Se usi spesso solo un portatile, usa comunque almeno un mouse. Il touchpad ti rovina le mani

Constatazioni personali

240. Ci sono persone con cui non posso e non voglio lavorare, nonostante il mio massimo impegno. Una sono stato costretto ghostarla ovunque, anche sul posto di lavoro
241. Le aziende non sono fedeli a te, non esserlo nemmeno tu. Mai credere alla “grande famiglia”
242. Non saremo una grande famiglia, ma sono comunque un team player
243. Sindrome dell’impostore: ho lavorato con persone 10 volte migliori di me, ma ho lavorato anche con persone 10 volte più scarse di me. Serve concentrarsi solo sulle prime
244. Spesso ho opinioni forti sul progetto/prodotto per cui lavoro: non sono una “code monkey”
245. Spesso ho opinioni forti e basta, fattele andare bene, perché se ho un’opinione forte è solo perché me ne frega qualcosa, piuttosto preoccupati se sto zitto
246. Devo avere un sacco di cazzate sulla scrivania
247. Mi serve la musica per lavorare
248. Se ho le cuffie in testa non mi rompere le scatole
249. macOS mi piace
250. Linux mi piace, ma non come macOS
251. Tra altri 20 anni (O 10?) non farò più questo lavoro o lo farò in una maniera completamente diversa
252. Mi importa più del codice che del tooling
253. Scrivo ancora codice nel tempo libero, ma sempre meno con il passare degli anni
254. A volte mi piace andare in ufficio, ma di solito sono molto meno produttivo che a casa
255. La comfort zone è una merda
256. Un team che ride insieme lavora meglio e tendo a far ridere gli altri, ma non voglio essere il giullare del team