(The English version of this article is provided after the Italian one. / La versione inglese di questo articolo si trova dopo quella in italiano)

I due demoni dello sviluppatore

Ogni sviluppatore convive con due demoni interiori.
E se cogliete il gioco di parole, siete probabilmente sviluppatori o almeno un po’ nerd: nei sistemi operativi i processi che lavorano silenziosi in background, invisibili ma indispensabili, si chiamano infatti daemon (o demoni in italiano).

Il demone della superbia

Il primo demone nasce nel momento in cui scriviamo il nostro primo programma funzionante.
Un “Hello World”, un disegno a schermo, un piccolo script che semplifica un compito noioso.
In quell’istante compare una sensazione potente: “Posso dare ordini a una macchina, e lei li eseguirà”. È un piccolo delirio di onnipotenza che accompagna quasi tutti gli sviluppatori per il resto della carriera.

Da quel momento in poi, la tentazione di piegare la realtà al proprio codice rimane sempre attiva, come un processo in background difficile da spegnere.

Il demone della pigrizia

Il secondo demone è la pigrizia, che in questo contesto assume un valore positivo.
Non parliamo della pigrizia sterile, ma di quella che si trasforma in creatività: la spinta a trovare soluzioni per lavorare di meno ottenendo di più.

Immaginiamoci in un minuscolo clan di cacciatori qualche decina di migliaia di anni fa.
Nel nostro clan ci sono tre cacciatori:

• Urok non caccia, non fa nulla e muore di fame.
• Grag affronta i cinghiali a mani nude e prima o poi soccombe.
• Lem, poco amante della caccia, costruisce arco e frecce per ridurre la fatica.

Chi sopravvive e prospera? Lem, perché trasforma la pigrizia in ingegno.
Lo stesso principio, migliaia di anni dopo, ha portato alla nascita dei computer: qualcuno non voleva più fare calcoli a mano e ha inventato macchine che li facessero al suo posto.

Pigrizia produttiva e superbia creativa

Per uno sviluppatore, la pigrizia non è mai fine a sé stessa. È un modo diverso di guardare al lavoro: invece di pensare “come faccio a portarlo a termine subito?”, lo sviluppatore si chiede “come faccio a non doverlo mai più ripetere?”.

È da qui che nascono strumenti e pratiche che cambiano il modo di scrivere codice:

• un tool che automatizza operazioni ripetitive;
• una libreria che potrà essere riutilizzata in decine di progetti;
• un sistema configurabile che si adatta da solo invece di costringere a continue modifiche manuali.

Tutto questo richiede spesso più fatica iniziale rispetto a fare la stessa operazione un paio di volte a mano. Ma a lungo termine significa risparmiare ore, giorni, persino mesi di lavoro. È la pigrizia che diventa investimento.

La superbia, a sua volta, non è un vizio sterile: è la convinzione che si possa sempre fare meglio, che valga la pena cercare soluzioni eleganti, potenti, durature. È quella voce che spinge lo sviluppatore a non accontentarsi di “codice che funziona”, ma a costruire qualcosa che possa resistere al tempo, crescere ed essere usato da altri.

Quando questi due demoni si parlano, accade la magia: la pigrizia spinge a ridurre gli sprechi, la superbia a puntare in alto. Il risultato è software più solido, più utile e – paradossalmente – frutto di meno lavoro ripetitivo.

Due daemon sempre attivi

Questi due demoni non si spengono mai. Sono come daemon in un sistema operativo: girano in background senza farsi notare, consumano energia, ma senza di loro il sistema non avrebbe senso di esistere.

Lo sviluppatore vive continuamente questa tensione:

• la pigrizia che suggerisce “trova un modo per liberarti di questa noiosa ripetizione”;
• la superbia che sussurra “puoi fare qualcosa di più grande, di più elegante, di più potente”.

Quando l’equilibrio è spezzato, i risultati sono deludenti:

• troppa superbia porta a progetti mastodontici e irrealizzabili, pieni di ambizione ma inutilizzabili;
• troppa pigrizia genera scorciatoie e soluzioni fragili, che crollano al primo utilizzo serio.

Ma quando i due demoni restano in armonia, lo sviluppatore raggiunge il suo stato migliore:
un ozio produttivo, in cui non si cerca di evitare il lavoro, ma di renderlo più intelligente, più umano, persino più divertente.

È in quell’equilibrio che fiorisce la vera arte dello sviluppo.

The Two Daemons of the Developer

Every developer lives with two inner daemons.
And if you catch the pun, you’re probably a developer or at least a bit of a nerd: in operating systems, those invisible background processes that keep everything running are called daemons.

The Daemon of Pride

The first daemon shows up the moment we write our first working program.
A “Hello World”, a shape on the screen, or maybe a tiny script that makes a boring task easier.
That’s when it hits us: “I can give orders to a machine, and it will actually do what I say”.
It’s a small rush of power that stays with most developers for the rest of their career.

From then on, the urge to bend reality with code never really goes away. It just keeps running in the background like a daemon you can’t kill.

The Daemon of Laziness

The second daemon is laziness, and here it’s not a bad thing.
We’re not talking about doing nothing, but about finding smarter ways to avoid doing the same thing twice. It’s laziness turned into creativity.

Picture a tiny hunter clan tens of thousands of years ago.
In our clan, there are three hunters:

• Urok doesn’t hunt, does nothing, and starves.
• Grag wrestles wild boars with his bare hands and eventually gets killed.
• Lem, not a big fan of hunting, builds a bow and arrows to make life easier.

Who survives and thrives? Lem, because he turns laziness into ingenuity.
Fast forward a few millennia, and the same principle gave us computers: someone was tired of doing math by hand and built machines to do it instead.

Productive Laziness and Creative Pride

For a developer, laziness is never the goal. It’s more of a mindset: instead of asking “how do I get this done quickly?”, the real question is “how do I make sure I never have to do this again?”.

That’s how tools and best practices are born:

• a script that takes care of repetitive work;
• a library you can reuse in project after project;
• a configurable system that adapts itself instead of needing endless tweaks.

Sure, it usually takes more effort up front than just doing the task a couple of times by hand. But in the long run, it saves hours, days, even months of work. That’s laziness as an investment.

Pride plays its part too: it’s the belief that things can always be improved, that “good enough” isn’t actually good enough. It’s the little voice that pushes you to make your code cleaner, more elegant, and more useful to others.

When these two daemons work together, the result is magic: laziness keeps waste in check, pride pushes for quality. The outcome is stronger, more reliable software – and ironically, less repetitive effort.

Two Daemons Always Running

These two daemons never really stop. They’re like system daemons: always running, using up a bit of energy, but without them nothing would work.

Every developer feels this tension:

• laziness whispering “find a way to stop doing this boring thing over and over”;
• pride saying “you can build something better, bigger, smarter”.

When the balance tips too far, the results aren’t great:

• too much pride leads to over-engineered monsters that no one can use;
• too much laziness creates flimsy shortcuts that fall apart under real use.

But when the two daemons are in sync, that’s when developers do their best work:
a kind of productive idleness, where the point isn’t to dodge work but to make it smarter, more human, maybe even more fun.

It is in that balance that the true art of development flourishes.