Aggiunge capitolo Cosa significa essere dev

[guizzo]

Ciao a tutti 👋

In questa PR trovate ciò che mi sono sentito di scrivere riguardo al cosa significa essere un dev per me.

Non sono uno scrittore, prendete dunque queste righe per quello che sono: parole scritte di getto.

Al momento non ho visto altre persone interessate a scrivere riguardo a questo topic, ma mi rendo ugualmente disponibile al confronto e alla revisione del testo, qualora non risultasse idoneo/di gradimento/fuori tema/qualsiasi altra cosa.

Ogni critica costruttiva, o qualsiasi semplice osservazione è ben accetta: fatevi sotto 🤗

[Cadienvan]

Ho lasciato qualche commento qua e là ma in linea generale a me piace veramente tanto!

[Cadienvan]

Al posto di "buona parte" proporrei un più modesto "parte". Sono d'accordo sul punto ma non necessariamente il proprio tempo dovrà essere "comandato" dallo sviluppo, quindi un "parte" più "moderato" mi suona meglio, che ne pensi?

[Cadienvan]

Toglierei "per l'intera durata di questo manoscritto". La frase mi piace molto, ma non sappiamo ancora in che punto del libro sarà questo contenuto. Inoltre, gli argomenti sono vari e disparati quindi non è detto vengano letti nell'ordine che ci aspettiamo. Se questo capitolo fosse, che ne so, il penultimo, la frase assumerebbe poco senso.

[serenasensini]

"caro lettore" sostituibile con "che leggi"

[GuidoPenta]

Io ho un dubbio sul termine "dev": nel senso, non potremmo parlare di "developer" oppure di "sviluppatore/sviluppatrice"?
E' più semplice, diretto (e poi fa keyword nei vari motori di ricerca, che male non fa 👀 )
Che ne dite?

[AngeloAvv]

Io ho un dubbio sul termine "dev": nel senso, non potremmo parlare di "developer" oppure di "sviluppatore/sviluppatrice"? E' più semplice, diretto (e poi fa keyword nei vari motori di ricerca, che male non fa 👀 ) Che ne dite?

Probabilmente fa più metrica "programmatore"

[GuidoPenta]

Io ho un dubbio sul termine "dev": nel senso, non potremmo parlare di "developer" oppure di "sviluppatore/sviluppatrice"? E' più semplice, diretto (e poi fa keyword nei vari motori di ricerca, che male non fa 👀 ) Che ne dite?

Probabilmente fa più metrica "programmatore"

Anche! Ricordiamoci però di essere inclusivi/e e quindi utilizzare sia programmatore che programmatrice :)

[Cadienvan]

"chi sviluppa" o "chi programma" reputo sia l'alternativa più coerente. @serenasensini sicuro ci tirerà fuori una perla.

[AngeloAvv]

Riflessioni molto interessanti e profonde, mi piace!

Ho aggiunto un po' di grammar nit qua e la 😿

[serenasensini]

"chi sviluppa" o "chi programma" reputo sia l'alternativa più coerente. @serenasensini sicuro ci tirerà fuori una perla.

Concordo pienamente, e questo è un aspetto che andrò a sottolineare nelle linee guida. Essendo un libro open source, e quindi letto da tutte le persone che vogliono o lavorano già nel contesto IT, adottare un linguaggio neutrale è sicuramente una delle cose a cui prestare attenzione.

Entrambe le forme riportate da @GuidoPenta sono corrette -a mio avviso- e preferibili anche a "*" o alternative varie. "Developer", "chi fa sviluppo", "chi vuole approcciarsi al mondo dev", o l'uso della parola "persona" sono tutte opzioni valide!

[serenasensini]

metterei in grassetto, per evidenziare l'importanza del concetto

[guizzo]

@serenasensini Intendi tutto il paragrafo?

[Cadienvan]

I typo indicati li ho proposti direttamente come commit da poter fare, così da semplificare il lavoro a @guizzo

[halfpass25]

Ola, sono finalmente riuscito a leggere tutto ed al netto di eventuali altri punti da considerare oltre a passione, perseveranza, spirito di gruppo/collaborazione, mentalità open-source, etica a me suona abbastanza bene tutto.
Voglio dire, se fossi uno che si sta avvicinando alla professione, senza saperne molto, già avrei trovato delle indicazioni utili.
Detto questo e sapendo che ognuno di noi ha un proprio stile di scrittura, credo che l'intervento successivo che si possa attuare su questo testo sia una "asciugatura", senza farlo diventare una RegExp, ovviamente! :)
Dico questo perché anche io, quando scrivo, tendo ad essere prolisso, però ho imparato a rileggermi e a limare a destra e a sinistra, lasciando inalterato il senso del testo ed anzi, spesso migliorandone la leggibilità.
Non è una critica a questo specifico testo sul "cosa significa essere un dev": ho paura che se scriviamo tutti in maniera troppo "lunga", il risultato finale potrebbe essere un "mattone" che scoraggerebbe chiunque, anche dotandolo di un indice analitico.
Beninteso, non intendo stravolgere lo stile di nessuno, dico solo, facciamo lo sforzo di usare meno parole possibili, possibilmente le più appropriate.
Per il contenuto, ripeto, mi sembra che dia un'idea sufficientemente chiara di cosa aspettarsi dall'intraprendere la carriera da dev ;)

[guizzo]

Ciao @halfpass25 👋

L'ho letta tutta (la versione che mi hai mandato per mail intendo) ed ho capito il tuo discorso.

Tuttavia, a mio personalissimo gusto, preferisco in questo caso la "lungaggine" del mio testo, ma semplicemente perché non sto parlando di un'argomento tecnico, in cui magari andare dritto al punto senza troppi fronzoli può rivelarsi un approccio migliore.

Quello che ho cercato di creare con questo mio contributo è un racconto "romanzato", ed in questo caso preferisco di gran lunga utilizzare qualche parola in più ma rendere il tutto più raccontato e romanzato, anziché risparmiare sulle parole e rischiare di risultare telegrafico o comunque in generale meno romanzato.

Tutto questo, ci tengo a dirlo e a ribadirlo, è un mio gusto personale; sottolineo inoltre che NON sono uno scrittore, per cui mi aspetto anche che il mio gusto possa non essere in linea con le best-practices riguardo la scrittura di un libro.

Per cui direi che:

Per quanto concerne il "come si scrive correttamente un libro" potremmo chiedere un parere a chi è più esperto/al nostro gruppo preposto @Il-Libro-Open-Source/drafting-group

Per quanto concerne invece la tua proposta di "asciugatura", direi che sia il caso di abbracciare in toto lo spirito open source che tanto sbandieriamo di avere, per cui chiederei a te di rendere pubblica la tua versione (quella inviata a me via email) e inviterei tutto il team @Il-Libro-Open-Source/ambassadors a leggerla, fare un paragone tra le due e a dire la loro.

[halfpass25]

Al momento non sono davanti al PC, più tardi pubblico il file che ti ho inviato ma non c'è da fare nessun paragone "meglio"-"peggio".
Era ed è solo una possibile asciugatura facendo salva la sostanza che hai esposto nel testo.
Ho già esposto perché penso che essere più brevi possa essere di beneficio ai lettori ed anche a noi tutti, a fronte di eventuali editing/aggiornamenti ma certamente non ci sono obblighi, in questo senso. A più tardi!

[guizzo]

Al momento non sono davanti al PC, più tardi pubblico il file che ti ho inviato ma non c'è da fare nessun paragone "meglio"-"peggio".
Era ed è solo una possibile asciugatura facendo salva la sostanza che hai esposto nel testo.
Ho già esposto perché penso che essere più brevi possa essere di beneficio ai lettori ed anche a noi tutti, a fronte di eventuali editing/aggiornamenti ma certamente non ci sono obblighi, in questo senso. A più tardi!

Giusto per chiarire: non intendo "fare un paragone meglio-peggio", bensì un paragone al fine di capire quale sia la forma più idonea da proporre al lettore finale

[halfpass25]

Per Simone e tutt*, ecco il suo testo "Cosa significa essere un dev" dopo la mia "asciugatura".

Cosa significa essere un dev
Cosa significa "essere un dev"?
La domanda è semplice, non altrettanto la –anzi le- risposte.

Una prima definizione potrebbe essere:
"Essere un dev significa ricoprire una figura professionale dedita alla stesura del codice e con il fine ultimo di creare prodotti digitali"... ma si tratta di una definizione formale che non racconta tutta la storia.
Altra definizione:
"Essere un dev significa essere persone altamente competenti nel campo informatico; figure prettamente tecniche e verticalizzate in uno o più linguaggi di programmazione"...ma anche qui, sarebbe come indossare un maglione troppo stretto: dopo un po' pizzica.

Oltre ad altre possibili definizioni più o meno omnicomprensive e soddisfacenti, c’è anche la chiave “etica”:
“Essere un dev significa abbracciare il movimento Open Source, apportando il proprio contributo senza pretendere nulla in cambio e contribuendo così a far crescere la community stessa, oltre che il proprio know-how".
Premesso che non ci sono verità assolute, resta il fatto che la professione del “dev” è molto sfaccettata ed implica indossare molti cappelli, spesso contemporaneamente.

Sarete però d’accordo che alla base di qualunque definizione, più o meno formale, più o meno romantica, i pilastri costituiti da passione, curiosità, empatia e contaminazione fanno da fondamenta e sono i principi su cui, peraltro, nasce questo libro.
Si tratta di caratteristiche del tutto slegate dallo scrivere codice o dal possedere competenze tecniche, ma che sono fondamentali per intraprendere questa carriera col piede giusto, lasciarsi coinvolgere in essa e aggiungere valore nel settore.
La passione: il combustibile per eccellenza
Diventare “dev" significa "sacrificare" parte del proprio tempo per il conseguimento di un obiettivo; non è un percorso ne’ facile ne’ breve; eccitazione e sconforto si alterneranno senza soluzione di continuità, almeno agli inizi.
Un giorno vi funzionerà tutto e quello dopo la più insignificante difficoltà vi sembrerà insormontabile. Ci saranno concetti che domeremo con estrema facilità, ed altri da cui ne usciremo sconfitti e con la coda tra le gambe.
Il segreto? Abbracciare questi momenti di stop, lasciarli sedimentare e farli tuoi: magari ci vorrà più di una buona notte di sonno ma se perseveri, prima o poi riuscirai dove prima hai fallito.
Quando ci appassioniamo a qualcosa, pur di impadronirci dei suoi segreti, dedichiamo ad essa molto tempo (perseveriamo, appunto): studiamo con cura ogni suo aspetto, e tutto questo per renderla veramente “nostra”.

Ricapitolando: fin qui abbiamo avuto di passione e perseveranza in dosi massicce e faremo bene a tenere questo allenamento; senza di esso, presto perderemmo l’entusiasmo, la voglia e la forza di studiare e… non è questo, il risultato che ci aspettiamo, vero?
Attenzione comunque a non confondere la perseveranza con l’intestardimento!
La prima ci porterà al successo nonostante i mille tentativi andati a vuoto, il secondo, non produrrà altro che ulteriore frustrazione.
Persevera con passione: a quel punto l'unico limite che avrai, sarai tu.
La curiosità: il potere della scoperta
Se cerchiamo la definizione di "curiosità" su Wikipedia scopriamo che:
“La curiosità è un aspetto emozionale che descrive un numero di meccanismi e comportamenti che hanno come fine il placare l'impulso degli esseri viventi a trarre informazioni ed interagire con l'ambiente.”

Il percorso che stai intraprendendo pullula di informazioni che non attendono altro che essere scoperte, studiate e messe in pratica ma occhio: alcune nozioni le troverai di semplicità disarmante, mentre altre potranno risultarti piuttosto complesse.
Non scoraggiarti; non vogliamo spaventarti ma consigliarti e guidarti nel migliore dei modi; proprio per questo, ti invitiamo a riflettere su un aspetto tanto scontato quanto potente: il potere dell'informazione libera.
La rete offre miliardi di informazioni a cui puoi avere accesso: aspettano solo di essere ricercate! Queste pagine che stai leggendo sono presenti sul web, e molto probabilmente ne sei a conoscenza perché ti sei imbattuto in esse navigando per la rete, o perché chi ti ha consigliato questo libro lo ha cercato a sua volta.
La buona notizia è che in rete puoi trovare ed accedere ad informazioni preziose per il tuo scopo e che ciò che ti separa da esse, indovina un po', sei tu!
Purtroppo, i dati da soli non servono a molto e per diventare “informazione” devono essere elaborati e questo puoi farlo solo tu, attrezzato della tua curiosità (oltre alle già citate e onnipresenti passione e perseveranza).
Essa sarà la scintilla in grado di innescare in te una forma mentis vincente, prona all'apprendimento e alla crescita professionale; fintanto che questa scintilla resterà accesa, non avrai limiti nell'apprendimento: anche qui, l'unico limite che avrai, sarai tu.
L'empatia: la capacità di impersonare il prossimo
Se ti stai domandando cosa c'entri l'empatia in un percorso di apprendimento e crescita professionale in un settore come quello della programmazione, sappi che –in questo contesto-, gioca un ruolo fondamentale.
Durante il tuo percorso, presto o tardi ti capiterà di imbatterti in un problema a cui non saprai far fronte; a quel punto, molto probabilmente il tuo primo impulso sarà quello di cercare in rete una soluzione e –hai di nuovo indovinato-, la troverai!
Penserai "Che fortuna che ho avuto!", ed è qui che... sbaglieresti di grosso.
Quella soluzione, che molto probabilmente ti aiuterà a risolvere il tuo problema, è lì per un motivo ben preciso: qualcuno, prima di te, ha avuto il tuo stesso problema; al contrario di te però, quel qualcuno non è stato "così fortunato" da trovare una soluzione online, ma è stato abbastanza empatico da mettersi nei panni di chi, come te, quel problema prima o poi lo avrebbe avuto; una volta trovata la soluzione quindi, si è adoperato per metterla a disposizione di tutti, gratuitamente e in maniera del tutto spontanea.
Questo, a te che leggi, è uno dei principi fondamentali su cui verte questo libro: la condivisione libera del sapere (in questo caso collettivo) con chiunque ne abbia bisogno.
Per questo ti parliamo di empatia: durante il tuo percorso, chiediti grazie a chi stai apprendendo sempre di più e domandati se le nozioni da te apprese potranno in futuro essere utili a chi muoverà i primi passi in questo settore, proprio come stai facendo tu ora leggendo questo libro.

Supera la timidezza, buttati ed inizia ad essere empatico anche tu ed a pubblicare i tuoi interventi dove puoi: per quanto banale possa sembrarti ciò che hai appreso, ci sarà sempre qualcuno che avrà bisogno di quella imbeccata e perché privarti del piacere e dell’orgoglio di essere stato proprio tu ad avergliela servita su un piatto d’argento?
Chiunque fruirà dei tuoi contenuti te ne sarà grato e sarà propenso a diventare un membro della tua community, ma sopra ogni cosa sarà ispirato a condividere a sua volta le nozioni che imparerà lungo il suo percorso...proprio come hai fatto tu prima di lui.
Ciò che vogliamo trasmetterti è la propensione ad adottare uno spirito di condivisione: oltre ad essere il cuore pulsante del movimento Open Source, e quindi del libro che stai leggendo, è anche un principio nobile e al contempo stesso utile; qualora non ne comprenderai subito il senso ed il potenziale, o magari ti sembrerà una perdita di tempo, tieni a mente quanto segue: arriverà il giorno in cui ringrazierai chi, prima di te, ha seguito il nostro consiglio.
Fidati di noi: fidati di chi, prima di te, è stato aiutato e che oggi è qui a condividere il suo sapere con te.
La contaminazione: fare squadra nel modo giusto
Indossare i panni da “dev", tra le tante altre cose, significa essere parte di una comunità.
Una comunità composta da altri professionisti, persone che come te hanno scelto di lavorare in questo settore.
Con il tempo, magari collaborando ad un progetto Open Source o lavorando in qualche azienda, ti troverai a dover collaborare a stretto contatto (che sia esso virtuale o fisico) con altri sviluppatori.
Scenario ben diverso da ciò che magari sei stato abituato a fare fino a quel momento; d'altro canto, un conto è scrivere codice in solitudine per un progetto a cui stiamo lavorando, e un conto è scrivere codice collaborativo con un numero indefinito di altre persone, tutte con lo stesso obiettivo.
Ciò che solitamente fa la differenza è lo spirito con cui si affrontano queste situazioni; parti dall’assunto che ognuno di noi può insegnarci qualcosa, e dunque, possiamo sempre imparare qualcosa, anche da chi è meno esperto di noi, significa lasciarsi contaminare.
La contaminazione, in un gruppo di persone aventi lo stesso obiettivi è un modo sano di fare gruppo, contribuendo alla sua crescita e apprendendo da esso, il tutto senza pregiudizi di genere o di altro tipo.
Open Source significa anche questo: contribuire condividendo il proprio sapere, ed apprendere da chi a sua volta condivide il suo sapere con noi.

[Cadienvan]

Credo che la cosa migliore sia chiedere il parere di @passasooz a riguardo visto che è il secondo assegnatario dell'argomento, come la vedete?

Mi sembra uno dei classici casi di "gusto personale" che è giusto vengano diramati da una terza parte senza protrarre il tutto troppo a lungo.

[guizzo]

Credo che la cosa migliore sia chiedere il parere di @passasooz a riguardo visto che è il secondo assegnatario dell'argomento, come la vedete?

Mi sembra uno dei classici casi di "gusto personale" che è giusto vengano diramati da una terza parte senza protrarre il tutto troppo a lungo.

Make sense 👍

Sono d'accordo sul trovare una quadra e portare dentro il capitolo, in modo da averlo tra quelli disponibili e andare avanti

[Cadienvan]

Ho corretto, viste le linee guida, l'utilizzo del termine "dev"

[AngeloAvv]

LGTM!! Ho aggiunto giusto qualche suggerimento ma direi che ci siamo!