Side-side projects: quando ti costruisci l’attrezzatura per la missione 🧰

Hai presente quando inizi un side project “semplice” e, dopo tre sere, ti ritrovi a scrivere un tool per il tool che userai per costruire il progetto? Non è procrastinazione. O meglio: non sempre.

I side project sono quella palestra fuori orario dove fai cose che sul lavoro non puoi (o non vuoi) fare: provi tecniche nuove, ti prendi il lusso di sbagliare in pubblico, e ti alleni senza l’ansia di una deadline che ti respira sul collo.

Poi però succede una cosa curiosa: ti accorgi che la “palestra” non ha i pesi giusti. E allora li costruisci. Benvenuto nel mondo dei side-side project.

Un side project ti allena. Un side-side project ti costruisce l’allenamento.

La palestra fuori orario (e perché serve davvero) 🏋️‍♂️

Sul lavoro, anche quando ti va bene, c’è sempre un perimetro: stack, vincoli, processi, decisioni già prese (da te… o dal destino). Il side project invece è uno spazio morale prima che tecnico: puoi scegliere cosa imparare e perché.

E qui c’è un punto che secondo me vale più di mille roadmap: il side project non serve a “fare portfolio”. Serve a recuperare intenzionalità. A decidere tu dove mettere energia.

E sì: quando ti alleni da solo, la disciplina non arriva gratis.

Quando l’attrezzatura non esiste 🧰

Il problema dei side project è che, spesso, provano a simulare un pezzo di mondo reale. E il mondo reale è pieno di cose scomode:

• protocolli diversi che non si parlano
• formati di dati “creativi”
• eventi che arrivano fuori ordine, duplicati, in ritardo, quando sei già in pigiama
• logging e osservabilità che ovviamente diventano importanti solo dopo il primo disastro

Quando vuoi sperimentare seriamente, ti servono strumenti. E se gli strumenti non esistono (o esistono ma ti costringono a compromessi brutti), succede l’inevitabile: li costruisci.

Non perché sei un fan della ruota reinventata. Ma perché a volte reinventare una ruota è il modo più rapido per capire come frena una macchina.

Events Bridge: un ponte tra mondi 🌉

Tempo fa ho iniziato un progetto chiamato Events Bridge (che, sì, è anche il rifacimento di un progetto simile: la coerenza è sopravvalutata, la curiosità no 😄). L’obiettivo era molto concreto: creare un bridge/trasformatore di dati in sistemi di eventi distribuiti, con compatibilità verso sorgenti e destinazioni diverse.

Repository (così non resta un personaggio misterioso): https://github.com/sandrolain/events-bridge

In altre parole: prendere eventi da una parte (HTTP, SOAP, NATS, Kafka, stdin/stdout, e compagnia cantante), trasformarli in una pipeline dichiarativa (YAML), e spedirli altrove. Non per costruire “il prossimo prodotto”, ma per attraversare un terreno che sul lavoro non sempre puoi esplorare con calma.

Quella palestra mi ha fatto ripassare e approfondire una valanga di cose, tra cui:

• Go “vero” (non solo scrivere codice, ma ragionare con le sue convenzioni)
• best practices e strumenti di linting
• sistemi di plugin e modularità
• parallelismo, ordinamento e shutdown ordinato
• la natura dei sistemi event-driven (che sembra semplice finché non lo provi)
• protocolli, librerie, e quei dettagli che scopri solo quando li metti in produzione… anche se la produzione è il tuo portatile
• un po’ di sicurezza “pragmatica”: input strani, confini, responsabilità
• l’uso delle AI generative (Copilot) come acceleratore e come specchio

E qui c’è un dettaglio interessante: quando inizi a usare davvero un’assistente AI, scopri che il problema non è “scrivere più veloce”, ma dare contesto e criteri di validazione. Non serve un modello perfetto, serve un contesto che non tradisca.

La deriva naturale: i side-side project 🧪

Finché lavori su un progetto singolo, puoi barare: fai a mano, copi-incolli, e “per ora va bene”. Ma appena vuoi ripetere esperimenti, compare il vero nemico: l’attrito.

Quando ho avuto necessità di integrare piccoli tool per inviare e ricevere eventi su protocolli diversi, la soluzione “semplice” sarebbe stata usare dieci CLI differenti, dieci sintassi diverse, dieci modi diversi di gestire template e retry.

E la parte divertente è questa: all’inizio quei micro-tool erano dentro Events Bridge stesso. Era comodo, nel breve periodo: un solo repository, un solo binario, e via.

Poi però è arrivata la domanda che ti mette in crisi nel modo giusto: “Questo tool lo voglio solo per Events Bridge… o lo vorrei anche domani, in un altro progetto?”

Per renderli utili davvero (anche fuori dal loro “nido”) ho deciso di dargli dignità propria: documentazione, versioning, e un perimetro chiaro. Da lì sono nati i side-side project.

Ho scelto l’altra strada: costruire un set omogeneo di comandi. Ed è nato EventKit: una suite CLI per inviare/ascoltare eventi, ripetere test, usare template, e interagire con diversi protocolli senza cambiare cervello ogni volta.

Link (così, se vuoi curiosare): https://github.com/sandrolain/eventkit

Poi è arrivata la seconda necessità: quando fai integrazione a eventi, spesso non avvii “un processo”. Avvii una piccola orchestra: sorgente, servizio, target, magari un broker locale, magari un consumer di debug. E farlo a mano ogni volta è un ottimo modo per odiare il tuo stesso hobby.

Quindi ho fatto quello che fanno tutti gli esseri umani ragionevoli: ho scritto un altro tool.

È nato goncurrently, una versione Go di concurrently: esegue più comandi in parallelo, li supervisiona, li ferma in modo ordinato, e ti evita di avere un terminale che sembra una discarica.

Sì, avrei potuto usare direttamente concurrently da npm (questo: https://www.npmjs.com/package/concurrently) e chiuderla lì. Il problema è che non volevo trasformare il progetto in un “mischione” tra Node.js e Go.

E soprattutto, non volevo aprire l’ennesimo buco nero chiamato node_modules in un repo che voleva restare semplice, portabile e Go-first.

Link: https://github.com/sandrolain/goncurrently

Questi sono side-side project: non sono “il prodotto”, sono la macchina utensile che rende possibile (o almeno sostenibile) l’esperimento.

Non stai costruendo un castello: stai costruendo la cazzuola. E a volte è la scelta più sensata.

Il rischio: costruire la palestra e non allenarsi 🕳️

Qui però arriva la parte moralmente scivolosa.

Il tooling è una droga elegante: ti fa sentire produttivo, ti dà dopamina immediata, e spesso è più controllabile del problema reale. È molto più rassicurante scrivere “un wrapper pulito” che affrontare una decisione difficile di design.

Il confine tra side-side project utile e side-side project come alibi è sottile e personale. Però ci sono tre segnali pratici che, di solito, non mentono:

1. Non lo usi davvero. Se lo strumento non entra nel tuo workflow, è un esercizio (legittimo), non un investimento.

2. Non ha un done. Se non riesci a dire “basta, ora è sufficiente”, probabilmente stai inseguendo perfezione e non utilità.

3. Ti sostituisce il progetto principale. Se da settimane stai “migliorando la CLI” ma non hai più spedito nemmeno un evento… forse stai evitando qualcosa.

In questi casi aiuta una regola semplice: timebox aggressivo e scope brutalmente minimo.

Leverage: la metrica che conta (quando nessuno ti paga) 📈

Sul lavoro spesso misuriamo valore in output. Nei side project, se vuoi essere onesto con te stesso, la metrica migliore è un’altra:

quanto leverage stai costruendo?

Leverage significa che domani fai di più con meno fatica: strumenti riutilizzabili, abitudini migliori, criteri più chiari, automazioni che ti tolgono lavoro inutile. E anche: la capacità di far ragionare un’AI con te, invece che contro di te.

Su questo tema è utile ricordarsi che l’output non è il punto: il punto è la gestione del contesto (umano e non).

Conclusione: il progetto invisibile è la persona che diventi 🔥

I side project sono un campo d’addestramento. I side-side project sono l’attrezzatura che ti costruisci quando vuoi allenarti sul serio.

La parte bella è che non c’è una “versione corretta” di questo percorso: c’è solo la tua capacità di restare intenzionale. Ogni tanto ti perderai in una CLI troppo elegante (capita). Ogni tanto costruirai un tool che ti cambierà il modo di lavorare.

Se vuoi una call to action implicita, è questa: la prossima volta che stai per iniziare un side project, chiediti non solo cosa vuoi costruire, ma che tipo di attrito vuoi eliminare. Se la risposta è “mi serve un attrezzo”, benvenuto: hai appena trovato un side-side project.