Idee sui capitoli del libro

[Cadienvan]

Come dimostrato dal sondaggio, il Manuale del buon dev vince con il 51% di preferenze, seguito al 42% dal Manuale sull'Open Source.
Ecco perché oggi vorrei aprire una discussione riguardo ai capitoli che vedete come fondanti per il libro.

Direi che come fatto in passato raccoglieremo le idee di tutti quanti e poi le metteremo in un sondaggio.

Reputo inoltre fondamentale che questi capitoli siano visti come compartimenti stagni, altrimenti come fatto notare da molti altri si rischia di non ottenere mai un filo conduttore, cosa che per natura stessa dei contenuti che vogliamo creare non credo sia fondamentale.

Porto quindi le mie idee al quale spero seguiranno le vostre:

• Cosa significa essere un dev: Cosa fa lo sviluppatore e perché dovrei decidere di entrare in questo mondo.
• Formazione: Come scelgo gli argomenti sul quale formarmi e come dovrei approcciare lo studio?
• Carriera - Junior: Cosa fare per i primi X anni? Come inizio la mia carriera? Come accresco le mie skill per andare allo step successivo?
• Carriera - Mid: Ho un po' di esperienza, ma come so di essere un Mid? ma come faccio il salto di seniority?
• Carriera - Senior: Sono riconosciuto come senior nel mio campo / nella mia disciplina, e ora come miglioro la mia condizione di carriera?
• CV: Quanto è importante il curriculum e il modo in cui lo compilo / lo rendo disponibile?
• Open Source: Contribuire e/o mantenere dei progetti può avere un effetto sul mio modo di sviluppare e/o sulla mia carriera?
• Version Control: Quanto è importante padroneggiare lo strumento di version control che uso?
• Refactoring: Come approcciarlo e come trarne i maggiori benefici
• Data Structures & Algorithms: Quanto sono importanti nel day-by-day?
• Design Patterns: Quanto sono importanti nel day-by-day?
• Code Structure & Organization: Avere un codice pulito e ben organizzato, sì, ma come?
• Managing Dependencies: Quando scelgo di reinventare la ruota, e quando invece mi posso affidare ad una dipendenza? Che cos'è il vendor lock-in e come posso evitarlo?
• Conferenze: Per essere un buon dev, devo partecipare? Devo diventare uno speaker?
• Etica: Come approccio il tema etica nello sviluppo? Il mio codice è sostenibile? Devo preoccuparmene, oppure un dev non dovrebbe preoccuparsene?
• Sicurezza: Quali tecniche posso adottare per rendere il mio codice sicuro?
• Performance: Sono davvero così importanti? Devo veramente spremere il mio codice per ogni millesimo guadagnabile?
• Burnout: Quando troppo è veramente troppo? Come posso evitarlo?
• AI: Cambierà il nostro modo di intendere il lavoro dello sviluppatore?
• Leadership (Suggerito da EMCestari)
• Engineering (Suggerito da EMCestari)
• DevOps (Suggerito da francescobianco)
• CI/CD (Suggerito da francescobianco)
• Developer Experience (Suggerito da francescobianco)
• Quality Assurance (Suggerito da francescobianco)

[serenasensini]

Sulla struttura generale, direi che ci siamo. Non so quanto il capitolo sulle performance e sul burnout possano essere capitoli a sé, ma magari li metterei in un capitolo come quello della formazione, a cui potremmo trovare un altro nome.

Inoltre, visto che lavoriamo nello spirito dell'open source e della condivisione all'interno della community, è importante utilizzare un linguaggio supergeneris (i.e.: "chi sviluppa", "le persone che sviluppano").

L'evoluzione si fa una parola alla volta ed è importante prestare attenzione a queste cose!

[davideimola]

Concordo con @serenasensini! Qualcosa sulle Community lo metterei!

[akelity]

Mi aggancio qui, aggiungerei anche un capitolo "Community" con consigli generali sul mondo community, sulla partecipazione attiva e benefici di farne parte.

[GuidoPenta]

Assolutamente d'accordo. Fare community è fondamentale!

[Saleiux]

Secondo me potrebbe essere utile un capitolo su quanto siano importanti le community di dev o il networking in generale in questo mondo e magari nella parte sul CV secondo me ci starebbe ampliare l'argomento anche a quanto sia importante Linkedin! Non so, sono le prime cose che mi sono venute in mente leggendo le tue idee!

[Cadienvan]

Grazie mille! Sicuramente tutto vero e interessante!

[Cadienvan]

@Saleiux se vuoi proporti come ambassador ti aspettiamo in #5 !

[mfvitale]

Innanzitutto, bel progetto! Oltre al CV aggiungerei qualche parola su come leggere un annuncio per farsi un'idea del genere di azienda. In questo stesso capitolo direi due parole sulle tipologie di aziende in cui poter lavorare con pro e contro.

[Cadienvan]

Si avvicina molto a quello che accenna anche @guizzo , non trovi? Quindi un capitolo sul "Mondo delle aziende".

[guizzo]

Si avvicina molto a quello che accenna anche @guizzo , non trovi? Quindi un capitolo sul "Mondo delle aziende".

Si esatto, ma estenderei il discorso anche a smart-working/remote-working/digital nomads e, in generale, al lavoro asincrono.

Secondo me sono topics piuttosto rilevanti, sia per il periodo in cui ci troviamo, sia perché il nostro lavoro si presta enormemente a queste tipologie di approccio al lavoro.

[Cadienvan]

@mfvitale l'invito è esteso anche a te, se ti va di candidarti come ambassador sei il benvenuto! #5

[guizzo]

La butto lì: non so se possa uscire un intero capitolo, ma penso possa essere interessante affrontare anche il topic aziende di consulenza VS aziende di prodotto, affrontando quindi pro e contro di ognuna di esse, ma anche cosa ci si deve aspettare lavorando per una o per l’altra.

Altro topic secondo me importante è tutto ciò che ruota attorno alla filosofia del lavoro da remoto; digital nomads, remote worker e via discorrendo; gli strumenti indispensabili per svolgere un lavoro a distanza e asincrono…framework come Kanban e Scrum…insomma, sta roba qui 😅

Cosa ne pensate?

[Cadienvan]

Remote working è un'ottima idea, sì!

[Cadienvan]

@guizzo vorresti proporti come ambassador? Se sì, ti aspettiamo nella #5 !

[guizzo]

Dici che un wannabe-ambassador può tornarvi utile? 😄

Ma si dai, buttiamoci 😃

[SimoncelloCT]

Aziende di consulenza vs di prodotto sarebbe molto interessante secondo me. Ci sono tante paure, falsi miti e verità non alla portata di tutti a riguardo!

[eppak]

Concordo soprattutto sulla parte dei framework forse non da descrivere nel dettaglio ma come "organizzazione del lavoro" (come indicato più avanti anche), il manifesto agile; aggiungerei anche una descrizione del processo iterativo in sé a confronto con i classici come statistico e definito (in base la grado di incertezza).

[JLadybug]

Ciao a tutti, secondo me, ci starebbe bene anche un accenno al ciclo di vita del software, all'organizzazione del lavoro, perché spesso un dev lavora in un gruppo, quindi entrare nel merito delle principali metodologie usate nel mondo del lavoro e/o figure con cui si potrebbe interfacciare. Come comunicare, gestire lo stress, il problem solving, autonomia, insomma si potrebbe parlare anche di come costruire buone skill trasversali, unendo anche il discorso sul burnout. Accenni magari alla stesura della documentazione (che spesso è odiata). Poi visto che si parla di open source, si potrebbe mettere anche qualche riferimento storico su come si è arrivati appunto al concetto, prendendo spunto dal famoso "La cattedrale e il bazaar" per descrivere le modalità di sviluppo del software.

Ho detto la mia, sperando possa essere utile. Grazie a tutti.

[Cadienvan]

Tutti ottimi spunti @JLadybug , posso chiederti magari di commentare con una lista di capitoli per punti? Così evito di perdermeli quando apriamo il sondaggio e perlomeno rendi più chiaro l'intento! Anche solo al volo come titoli ipotetici eh

[JLadybug]

Ecco a te.

1. Ciclo di vita del software
   Definizione e spiegazione delle fasi tipiche nel ciclo di vita del software
   Importanza della comprensione del ciclo di vita del progetto

2. Stesura della documentazione
   Importanza della documentazione nel processo di sviluppo
   Suggerimenti per creare documentazione chiara e utile
   Come rendere la documentazione una risorsa per il team e la comunità

3. Organizzazione del lavoro e metodologie
   Lavoro di squadra nel contesto dello sviluppo software
   Metodologie agili e tradizionali: vantaggi e differenze
   Figure professionali coinvolte nello sviluppo software e il loro ruolo

4. Competenze trasversali
   Comunicazione efficace nello sviluppo software
   Gestione dello stress e del burnout nella professione di sviluppatore
   Tecniche di problem-solving e approcci al troubleshooting
   Sviluppo di una mentalità aperta e collaborativa

5. Open source. Prospettive per gli sviluppatori
   Origini e concetto di software open source
   Analisi del saggio "La cattedrale e il bazaar" di Eric S. Raymond
   Lo sviluppo di software Open Source e la comunità

Edit: chiaramente è tutto molto indicativo. Si può restringere il campo eh...

[Cadienvan]

Spettacolo, grazie! Ti potrebbe interessare far parte degli ambassador per anche solo uno di questi punti? O non credi di poter avere il tempo? Se sì, ti aspetto nella #5

[JLadybug]

Sì, potrebbe essere interessante occoparsi di qualche capitolo. Ti farò sapere. Grazie mille!

[Cadienvan]

Ho aggiunto alcuni capitoli arrivati dal post sugli ambassador!

[corradopetrelli]

Non so se è incluso in altri capitoli ma consiglio di aggiungere: Testing

[Cadienvan]

Bravissimo, me l'ero perso!

[JLadybug]

Scusate, ma nel capitolo relativo al ciclo di vita del software verrebbe inclusa anche la fase di collaudo o testing, così come anche quella di analisi, progettazione, sviluppo e manutenzione. In realtà, anche la documentazione potrebbe ricadere dentro al ciclo di vita del software ma ho preferito trattarla come capitolo a sè perché mi sembrava più utile fare approfondimenti. Secondo me, alcune cose potrebbero includersi in quel capitolo con dei paragrafi più dettagliati oppure potrebbe essere un capitolo che dà una visione d'insieme della fasi e poi si potrebbe procedere a capitoli a sè per ulteriori approfondimenti. Non saprei. Che ne dite?

[Cadienvan]

Sicuramente sì, diciamo che al momento raccogliamo una lista di "topic", da lì poi struttureremo assieme la composizione dei capitoli, quindi sì, potrebbe andare esattamente così!

[corradopetrelli]

Dipende tutto quanto si vuole si vuole parlare di ogni fase, se si fa tutto su un capitolo si rischia di avere un mega capitolo molto prolisso.
Forse è meglio mettere nella lista dei topic le varie fasi del ciclo di vita e vedere quanti ambassador ci sono per ogni topic.

[passasooz]

mi piacerebbe supportare i primi 6 capitoli, in aggiunta proporrei anche diversi capitoli ad es:

• come scegliere l'azienda in cui lavorare (in base ai propri obiettivi di carriera o prospettive di vita),
• come intrattenere dei colloqui lavorativi su diversi livelli (quindi sia per junior che per mid che per senior, ma affrontando entrambi i punti di vista - ovvero sia dal punto del dev che dal punto del recruiter o azienda che ricerca persolane),
• come trovare i dev adatti (questo perchè ho notato che spesso le aziende si basano sulle tecnologie - mutevoli - piuttosto che sulle persone e i team - che dovrebbero essere meno mutevoli per mantenere un ambiente solido e proficuo),
• come non odiare il lavoro dello sviluppatore (questo perchè spesso chi fa lo sviluppatore ha una passione e/o un interesse verso la professione, ma ciò può portarlo ad entrare in una specie di circolo vizioso dal quale poi diventa difficile uscirne)

inoltre come controlliamo la qualità ortografica e grammaticale dei capitoli e delle scritture?
Serviranno dei relatori o moderatori (o qualcosa di più tecnologico..)

PS. questi spunti e la mia scelta sui capitoli già presenti è data dall'esperienza maturata come formatore in alcune academy online, ho notato pregi e difetti sia sui metodi di insegnamento ma anche eventuali aspettative degli alunni, difficoltà, ostacoli, e seguo da vicino anche molti ex alunni con cui ad oggi ho contatti quindi vorrei portare questa esperienza come contributo specialmente a chi vorrà approcciarsi al mondo dev ma anche a chi cerca dei dev per la propria azienda e/o startup

[Cadienvan]

Ottimi suggerimenti!!

[mcicolella]

Ciao,
visto che in un precedente commento si parlava di un capitolo dedicato all'open source si potrebbe valutare come la partecipazione a questo genere di progetti o la realizzazione di propri progetti open possa incidere positivamente sul proprio CV.
Ovvero come possa fungere da biglietto da visita per attirare le aziende, visto che ormai i CV "tradizionali" non sono più sufficienti per questo scopo.
Spesso i side project si affiancano all'attività principale e potrebbero costituire anche un'ulteriore fonte di reddito, quindi sarebbe interessante a mio parere poter illustrare i modelli di business basati sull'open source con riferimento alle Big Company e non solo.
Oltretutto in molti casi, purtroppo, progetti open anche validi vengono abbandonati per mancanza di supporto anche economico.
My two cents.

[Cadienvan]

Ottimo spunto @mcicolella , grazie!

[mcicolella]

Un'altro argomento potrebbe riguardare gli aspetti relativi ai contratti di fornitura del software, la proprietà dello stesso ecc. soprattutto se si affronta il tema del lavoro come freelance.
In questo caso:

• come stilare un contratto di fornitura (clausole, obblighi ecc.)
• di chi è la proprietà del sw se non specificato nero su bianco
• tutte le questioni relative alla NDA sia come dipendenti che come consulenti o fornitori esterni.

Spero di aver reso l'idea.

[Cadienvan]

Mmmmh.. Argomento molto specifico, ma perché no?! Potremmo parlarne!

[imD3v]

Ciao, mi piacerebbe partecipare.
Ho già pubblicato un mio libro su Amazon, il titolo Nati nel metaverso - come programmare un futuro migliore, dove l'obiettivo è appunto sensibilizzare all'utilizzo etico e sostenibile delle nuove ( e "vecchie" ) tecnologie le nuove generazioni dei "nati nel metaverso".

Mi piacerebbe contribuire al punto indicato in merito all'etica.

Grazie.
Marco.

[Cadienvan]

Ciao Marco,
grazie mille, sarebbe fantastico!

Intanto mi salvo in lista il tuo libro, nel frattempo se ti va di contribuire sono aperte le candidature ad Ambassador qui -> #5

Spero ci farai un pensiero, nel caso proponiti!

[msciabarra]

Posso suggerire di aggiungere il testing? Che è fondamentale, dovrebbe essere insegnato sempre e comnque.

[Cadienvan]

Ciao Michele, piacere di averti con noi!
sìsì, è stato già messo in lizza, @JLadybug e @corradopetrelli l'avevano già accennato in un paio di commenti, ma grazie per il reminder, rende ancor più evidente l'importanza della questione!

E se ti va, fai un giro sulla #5 ;)

[msciabarra]

Ho visto il progetto, mi piace molto e darò una mano.

[JeyDi]

Ciao! Mi piacerebbe un sacco poter partecipare, bellissima idea!!! Come PythonBiellaGroup stiamo già scrivendo guide simili, abbiamo moltissimo materiale già pronto e partiremo con tutta una track dedicata all'open source a settembre.

Suggerisco alcuni concetti che forse non sono stati menzionati:

1. Quali sono i requisiti minimi, consigliati e comuni per poter lavorare nel mondo del tech? (es: conoscenza base linux, conoscenza version control, docker, ...)
2. Un'introduzione al licensing del software e al trattamento dei dati privati (quantomeno in Europa)
3. Cos'è un NDA e perchè può essere importante
4. Aggiungerei anche delle roadmap per guidare le persone verso alcuni carrier path, descrivendo alcuni concetti base (prese ad esempio da qui e spiegate: https://roadmap.sh/)
5. Come ha suggerito @corradopetrelli e @msciabarra aggiungerei anche una parte sul testing
6. Metterei anche un capitolo un po' più nerd su tech indipendence, come essere indipendenti ed evitare il più possibile il vendor lock-in: https://sive.rs/ti

[Cadienvan]

Grazie @JeyDi , tutti ottimi spunti, grazie mille!

[achiarini]

Ciao, sono super d'accordo con i punti che sollevi, più che parlare di "vendor lock-in" che è un concetto molto commerciale e relativo io dedicherei una sezione (o capitolo) al debito tecnico con tutte le implicazioni che ne conseguono (tra cui il blindarsi ad una tecnologia proprietaria).

[elgorditosalsero]

👋🏾

Non mi sembra di averlo visto in lista, ma credo che ci vorrebbe un capitolo sulla documentazione.

Fin troppo spesso se ne parla e poche volte c'è una cultura dietro...

Ovviamente si potrà fare distinzione tra documentazione tecnica, documentazione per gli utenti etc; come scriverla, come organizzarla, come gestirla, come aggiornarla etc.

[Cadienvan]

Ottima idea. In un modo o nell'altro era già citata e le riprese servono a far comprendere l'importanza dei concetti quindi grazie!

[Zavy86]

un capitolo relativo ai diversi ruoli in un team di sviluppo? non so se era previsto già nel capito della carriera ma elencare magari anche le diverse figure, relative mansioni e requisiti in termini di competenze?

[elgorditosalsero]

Mhhh, che intendi per "ruoli all'interno del team"?

Ho paura che è difficile stilare una guida, in quanto ogni azienda ha ladder, team e responsabilità diverse

[Zavy86]

si hai ragione più che altro intendevo giusto un accenno alle possibili figure come ad esempio project manager, team lead, scrum master, product owner, software architect ecc..

[elgorditosalsero]

Ci può stare, ma tocca stilare bene prima la lista dei ruoli ed arrivare ad una decisione prima di raccontarli, anche perché, son sicuro, alcuni ruoli han nomi diversi in contesti diversi 😛

[passasooz]

ho visto il primo capitolo proposto da @guizzo ovvero "cosa significa essere un dev", mi piace molto, però vorrei integrare anche una specie di sotto capitolo o in parallelo parlare del fatto "chiunque può diventare un dev?", perchè penso che a causa del marketing possa passare erroneamente questo messaggio, e noto anche che molti quando arrivano all'inizio di un percorso di formazione possibilmente sono curiosi di capire se è la strada giusta o meno.
Cioè immaginiamo di essere noi al posto loro, ed essere incuriositi dalla programmazione, sui social bombardati dalle scuole di formazione, una ti propone 3 mesi, una 6 mesi, ecc ecc... chi ti propone il linguaggio X chi ti propone il linguaggio Y.
Quindi secondo me due parole spese nel dire: ALT! Ti ispira la programmazione? Vuoi sapere se è una strada adatta a tutti?
Smonterei questa cosa che "tutti possono diventare programmatori" ma sottolineerei anche che "tutti possono imparare a programmare"
Oppure si può integrare nel secondo capitolo "formazione", anzi quasi quasi lo tratterei lì dentro...
Che ne pensate?

[Cadienvan]

Credo abbia più senso come dici tu inizialmente nel "cosa significa essere un dev", come sezione all'inizio o alla fine, "formazione" la vedo già come qualcosa che tratti una volta che entri..

[passasooz]

ok quindi dici si accenna nel primo si approfondisce nel secondo?

[Cadienvan]

No no io intendo che "cosa significa essere un dev" è lo spazio perfetto per questo tema, perché quando si parla di formazione sei già DENTRO al mondo dev

[manuelricci]

Ciao! Bellissima iniziativa.

Mi permetto di consigliare anche un capitolo sull'accessibilità, argomento di serie B come la sicurezza, ma essenziale. Soprattutto in vista del 2025 con l'European Accessibility Act.

Penso che potrebbe essere utile spiegare i vari tipi di disabilità, i mezzi con la quale un dispositivo può essere usato e cose da tenere a mente quando si sviluppa software, app o web. Argomenti evergreen che possono deprecarsi solo nel caso inventino dei cyberware in stile Cyberpunk 2077.

Sarei felicissimo di occuparmene.

Fatemi sapere ✨

[Cadienvan]

Bellissima idea. Non l'avevamo trattata fino ad ora in mancanza di una figura che ne potesse parlare con coscienza!

[frnmjn]

Non so se rientra nel capitolo "Carriera", ma si potrebbero creare delle sorte di percorsi basate su libri "Must Read".
Con una piccola descrizione, finalita' e commenti dei lettori.

Tipo: BE Dev: GOF -> Clean Code -> Domain Driven Design ecc...

[Cadienvan]

L'idea è interessante ma il libro vuole essere quanto più imparziale possibile, quindi c'è da gestire bene i contenuti e l'esposizione da quel punto di vista.

Credo comunque che possa andare nel capitolo "Formazione"

[sensorario]

Non so se la discussione si è fermata qui o se ha senso commentare dopo due settimane. Però ci sono libri che sono fondamentali e sono più che d'accordo con l'idea di parlare

[Cadienvan]

No problem, bisogna solo rendere chiaro che si tratti di opinioni personali e non di verità assolute, per il resto si potrebbe fare! Magari nel capitolo sulla formazione che si sta già trattando in #124 ?

[sistella]

Ciao a tutti! Io proporrei un capitolo sul Cloud, con l'intento di declinare la figura del dev anche nelle architetture cloud. Penso si possano descrivere le possibilità di deployare infrastrutture di test ad hoc, i servizi di containerizzazione, le architetture serverless, i servizi di code whispering, i servizi che permettono di creare una infrastruttura adeguata a partire dal solo codice, e i servizi di patching delle dipendenze. Insomma, cosa significa essere uno sviluppatore Cloud native.
Il Cloud è il mio mondo, e mi propongo volentieri per coordinare un capitolo del genere: io per primo avrei bisogno di una visione completa della questione :)

[Cadienvan]

Ciao Simone!
#133 leggi qui, ti aspetto su Telegram per aggiungerti al gruppo, nel frattempo apro la proposta di argomento così potrai assegnartela non appena accetti l'invito che ti ho appena mandato per far parte degli ambassador :)

[sistella]

Ciao @Cadienvan ! Non trovo la issue relativa all'argomento Cloud nel repo del libro... magari vedo nel posto sbagliato? 😅 o forse c'è bisogno che prima venga approvato in qualche meeting?

[Cadienvan]

Sorry, me l'ero perso! #140

[allevo]

Ciao a tutti!
Vorrei proporre un nuovo argomento: "Protocolli di comunicazione". Argomento noiosetto ma estremamente importante. Perché si sa, il JSON su HTTP non è l'unica opzione.
Penso possa essere interessante fare un "breve" excursus sul tema per affrontare:

• Network:
  • TCP/UDP
  • HTTP (1, 2, 3)
  • RPC
  • gRPC
  • DNS
• formati
  • JSON
  • XML
  • binario
    • msgpack
    • avro
• altro
  Il ToC qui sopra può essere rivisto in ogni sua forma chiaramente, ridotto o aumentato.

Che ne pensate?

[corradopetrelli]

Io approvo. Magari sulla parte Networking aggiungerei una sezione sullo stack TCP/IP oppure si preferisce darlo per assodato?
Magari da valutare se formati si può inserire sulla parte di Strutture Dati del capitolo Algoritmi e Strutture dati

[Cadienvan]

mmmmh.. Ci sta, starei "asciutto" sulla parte di networking non perché non sia importante ma perché sono argomenti veramente molto tecnici che varrebbe la pena trattare in altri manuali sul tema, come la vedete?

Penso che i formati siano un'ottima idea, non so @corradopetrelli , metterli in "strutture dati" mi sa di forzatura..

[corradopetrelli]

Per me va benissimo come ha proposto @allevo era più per dare un po' di contesto. Non vorrei che il lettore non abbia le basi tecniche quando legge un capitolo.
Per il resto ci sta farlo su un capitolo a sé

[halfpass25]

@Cadienvan e a tutt*: qualcuno ha intenzione di scrivere contributi per il capitolo "Formazione"?
Domando perchè nell'ambito di "Formazione" a tutto tondo, potrei contribuire per un sotto-capitolo "Auto-formazione" o "Autodidatti" discorso sul quale ho esperienza personale e anche riscontri di terzi.
Fatemi sapere, eventualmente se qualcun altro è interessato facciamo gruppo ;)

[corradopetrelli]

Prova a contattare coloro che si sono assegnali #101 e #70 magari riuscite insieme a creare un Table of Contents per ambedue i capitoli (cercando di non essere ridondanti) e dividervi il lavoro per bene, che ne dici? 😄

[halfpass25]

Grazie @corradopetrelli, cercando in questa sezione non ero riuscito a trovare riferimenti, vado e chiedo!

[corradopetrelli]

Non c'è di che!

[BrianAtzori]

Buongiorno Gente!
In fase di candidatura avevo proposto dei capitoli, non mi è chiaro se devo aprire la issue oppure partire da questa discussione e quando prende forma la cosa o viene approvata, devo aprire la issue... in caso inizio a buttare giù le mie proposte per punti:

Queste sono quelle che avevo ipotizzato in fase di candidatura:

• Contenuti e Community, ovvero quali contenuti tra podcast, articoli, newsletter ecc ecc posso consumare per valorizzare la mia carriera o aumentare le mie conoscenze?
• Dialogo e collaborazione, un insieme di regole, best practices e indicazioni per collaborare con altre figure aziendali, dai designer ai capi fino al marketing, utile credo soprattutto per ambienti più "startuppari" ma credo sia significativo per ogni genere di azienda.
• Open Source dal punto di vista etico, magari privacy oriented e inteso in ottica """politica""", a livello di libertà, valore delle contirbuzioni ecc ecc

Queste sono quelle che mi sono venute in mente ora invece:

• Freelanceria, in ottica di consulenza, prodotti e servizi da offrire, best practices ecc ecc, magari può c'entrare anche con l'argomento soldi
• Falsi miti sullo sviluppo
• Un bel "da dove iniziare questa carriera" anche per marcare come sempre che un bootcamp non ti rende uno sviluppatore
• Argomento tecnologie, un po' ostico forse ma sarebbe interessante infilare da qualche parte una bella tabellina con una colonna per le tecnologie e una collonna con qualche statistica, tipo % di utilizzo oppure l'ambito, giusto per orientare meglio chi sta scegliendo cosa studiare

Ho letto il resto delle discussioni e credo che ci siano diversi capitoli che possano combaciare con queste tematiche, quindi credo possano fare da Tie-In

[corradopetrelli]

Ciao Brian,

Le issue per i capitoli sono già presenti (1 per capitolo). Se trovi la issue desiderata assegnati l'issue altrimenti crea la issue tu stesso (utilizza il template Nuovo Capitolo) e poi assegnati la issue (ti genererà automaticamente un branch add/nome-capitolo) in snake-case.
Se hai già in mente un ToC per quel capitolo scrivilo nella descrizione potrebbe essere utile anche ad altri.

Prima di aprire una issue se trovi qualche capitolo che senti possa essere affine alle tue proposte, chiedi nei commenti se si può aggiungere quel tema su quel capitolo. Non abbiamo vincoli specifici, l'unica cosa è: se reputi di scrivere molto su quel tema allora direi di affrontarlo a parte per evitare capitoli immensi.

Se vuoi cominciare a scrivere qualcosa ti chiedo gentilmente di leggere prima:

• CONTRIBUTING.md
• CODE_OF_CONDUCT.md
• GUIDELINES.md

[BrianAtzori]

Grazie Corrado, come sempre mi dai tutte le riposte che mi servono 🤓

Ho già letto regolamente e il file per le contribuzioni ma ti ringrazio lo stesso!
Avevo letto dell'automatismo (Geniale tra l'altro e pura magia per me), quello che mi mancava e se ci fosse una procedura di approvazione capitoli tutti insieme, avevo visto le issue degli argomenti ma non sapevo se ci fosse stata un'approvazione delle varie proposte!

Ora mi è tutto chiaro comunque e ti ringrazio come sempre!

[corradopetrelli]

Figurati, per qualunque cosa non esitare a chiedere 😄

[Cadienvan]

@BrianAtzori essendo tu ambassador, è intrinseco che tu ti prenda la responsabilità dell'argomento che apri, quindi vai pure!

[giuseppesorce]

Non trovo esattamente la parola ma da Dev mi occupo di cercare sviluppatori per la mia azienda. Non è solo cercare via internet ma organizzo colloqui, parlo con i candidati sia tecnicamente sia quasi uno delle risorse umane. Devo capire lo sviluppatore e inquadrarlo, filtrarlo permettemi...la parola.
Ho fondato 2 community e l' aspetto delle.communty è molto importante.

[Cadienvan]

Ciao @giuseppesorce la cosa migliore credo sia dare un occhio agli argomenti aperti (Se vai nelle issue li vedrai subito!) e da lì magari cercare il tuo posto proponendo qualche punto, che ne pensi?

[giuseppesorce]

@Cadienvan si sicuramente mi piacerebbe dare il mio contributo. Vediamo cosa posso fare.
Un po' di esperienza ce l' ho 😉

[olprofesur]

Ciao a tutti, nella struttura attuale del libro mancano a mio avviso 2 macro-temi.

Requisiti del software & analisi: chi e come definisce le features che devo implementare? che metodi uso per capire meglio quello che concettualmente devo realizzare? nel concreto significa tirare in ballo un po' di user stories (se la vediamo in modalità agile) o use cases (in modalità old school UML & OOP). Ricordiamoci l'esempio dell'altalena...cosa vorrebbe l'utente (un'altalena) e cosa riusciamo a dargli quando ci va bene (un copertone/gomma di auto con un corda legata ad un albero che si può usare come altalena ma non è proprio quello che l'utente voleva)

organizzazione del lavoro e processo di sviluppo: le attività di sviluppo come procedono/sono organizzate? modelli informali (PMI italiana style) vs. waterfall vs. metodologie agili

Per il resto idea fantastica e gli argomenti proposti assolutamente centrati

[Cadienvan]

Sono ottimi argomenti, vediamo se qualcuno dei nostri @Il-Libro-Open-Source/ambassadors vuole prendersi l'onere di questo capitolo, almeno a livello di ownership. Dopodiché, una volta partito, sarebbe per me, e per noi tutti, un enorme piacere averti a bordo di questa avventura con una PR su quel tema!

Grazie per i complimenti e la review degli argomenti!

[eppak]

Ciao @olprofesur,
è un campitolo che passa vicino come tematiche è la issue #106 dove si passava ad accennare alle storie/personas come ausilio alle stime; nella seconda parte invece mi pare di capire che intendi in generale i processi aziendali, sbaglio?

Grazie!

[olprofesur]

mi sono candidato per eventuale ambassador..

[olprofesur]

secondo me è ben diverso da issue #106 e anche dall'aspetto metodologico. Oltre tutta la parte di orientamento, formazione, tecnologica (il come realizzo una soluzione software) una parte sul "cosa": sia che sia un Dev che ha più o meno direttamente a che fare con l'utente finale, sia che il tutto sia ben mediato capire il "cosa" e soprattutto fare analisi sul cosa è fondamentale...ed è a mio avviso un capitolo a sé stante "first class citizen" come gli altrii @Cadienvan

per i processi aziendali intendevo il modo di organizzar il lavoro in cui è inserito un dev; magari assumere un approccio agile (e magari SCRUM), però in manuale da zero ci andrebbe anche questa parte (di cui però non mi sento degno di fungere da eventuale ambassador, sulla parte di analisi eventualmente sì)

[Cadienvan]

@olprofesur purtroppo come ti dicevo nell'altra discussion attualmente le candidature ad Ambassador sono chiuse.
Possono essere argomenti interessanti, rinnovo l'invito ad eventuali Ambassador di prendere in carico l'ownership del tema qualora sia reputato di interesse trattato a parte.

Se così non fosse, abbiamo #106 , #107 , #95 e #100 nel quale i temi potrebbero essere trattati in un modo o nell'altro, reputo valga la pena inserirli a prescindere dalla forma che assumeranno.

[tdifiori]

Salve a tutti,se può essere utile la mia esperienza provengo da un contesto dolente di questo paese ovvero (la povera pubblica amministrazione 🥸) … diciamo che potrei raccontare 20 anni di battaglie , dai lenti cambiamenti , ai vecchi sviluppatori incollati alle sedie , finì alle attuali battaglie sulle nuove tecnologie… l’impatto che hanno avuto, e come uno sviluppatore moderno deve approcciare in quei contesti senza farsi male … insomma un bel quadro sugli approcci da adottare in alcuni contesti giurassici in cui il nostro paese purtroppo ancora assiste.
Un abbraccio a tutti 💪

[Cadienvan]

Credo che forse possa valere la pena valutare una aggiunta in #95 .
@fulgido cosa ne pensi?

[tdifiori]

Preciso che nn sono un consulente esterno, ma un dipendente da ormai molti anni per averne viste e vissute 🥸

[Cadienvan]

Ciao @tdifiori ti ricordo che il capitolo è andato online qualche giorno fa e che se vuoi proporre una modifica puoi farlo seguendo questa guida: https://github.com/Il-Libro-Open-Source/book/blob/main/CONTRIBUTING.md

[pietrantonio91]

Ciao a tutte e tutti!
Intanto complimenti perché l'idea mi piace un sacco e trovo che ci sia veramente bisogno di qualcosa del genere. Detto questo, proprio perché apprezzo tantissimo l'idea, mi piacerebbe contribuire al progetto e per farlo avevo pensato di scrivere qualcosa sulla mia esperienza. Sono uno sviluppatore ormai da 10 anni ma sono cresciuto con un background più che altro umanistico (liceo classico e laurea in sociologia). Ho pensato che la mia esperienza potesse ispirare qualche neofita che si avvicina alla programmazione ma ha paura di non essere adeguato per via del suo background.
Volevo quindi capire se la mia esperienza potesse essere interessante e, nel caso, in che capitolo potrebbe rientrare.

[Cadienvan]

CIao @pietrantonio91 ,
non so se questo possa rientrare nel "Cosa significa essere dev" già scritto da @guizzo , cosa ne pensi? Hai avuto modo di leggerlo? https://il-libro-open-source.github.io/book/

[Livio74]

Ciao a tutti
scrivo qua perché non so quale sia il posto giusto.
Nel capitolo formazione manca una parte secondo me significativa sulla formazione scolastica
Che ne dite? L'avevate già considerata ma va ancora inserita?

[Livio74]

Ciao @eppak , posso anche se non sono un ambassador?

[eppak]

Ciao @Livio74, possiamo procedere in che modi, se é nuovo creo una issue io così si crea il branch nuovo. Se invece vuoi procedere con una pr del capitolo in stesura puoi fare un fork del bramch. Fammi sapere!

[Livio74]

Ciao @eppak , procedo con la pr , spero non abbiate fretta perché sono un po' preso , ma nei ritagli di tempo provo ad impostarla.
Naturalmente se qualcun'altro vuole fare basta saperlo così ci sincronizziamo. Ad ogni modo la mia sarà una bozza d'altronde usiamo Github anche per quello 😀

[Livio74]

Ciao a tutti,
Mi confermate che ora non va più su add/formazione ma questa parte va fatta su add/università-vs-self-made?

[Cadienvan]

Ciao @Livio74 , direi proprio di sì! Poi se a un certo punto decidessimo di unire i capitoli, potremo farlo senza problemi!

[mariomontella]

Ciao @Cadienvan e ciao ragazzi, come lo vedreste un capitolo incentrato sul "Codice pulito"? Quindi tutto quello che riguarda i criteri di sicurezza lato sviluppo.

[corradopetrelli]

Ciao @mariomontella, penso che quell'argomento possa essere incluso nel seguente capitolo: #80. Che ne pensi?

[Cadienvan]

Ciao @mariomontella , se parliamo di codice pulito, sì, sono d'accordo con @corradopetrelli , altrimenti se parliamo di sicurezza c'è #84 !

[mariomontella]

Si ci può stare, magari introducendo anche i tool più utilizzati, tipo: synk, sonarqube ecc...

[Jean85]

Ciao a tutti, e complimenti per l'idea di questo libro! Atterro qui dopo averne sentito parlare in passato, e dopo averlo ri-sentito al GitBar podcast...

Già la prima volta che avevo visto questo repo mi frullava un'idea in testa, che non vedo cristallizzata in un solo capitolo: il ciclo del feedback.

Col tempo sono arrivato a capire che è un elemento vitale del nostro lavoro, e che restringerlo è un mantra da ripetere in tutti gli approcci. Se ci pensate, tantissime metodologie si basano su questo ciclo e sul fatto che sia il più rapido possibile: TDD, la Continuous Integration e la Continuous Delivery, il Devops...

Non so se ha più senso che sia un capitolo a se stante o se è più un "cappello" per un gruppo di capitoli... che ne dite?

[Cadienvan]

@Jean85 l'idea mi piace, come la svilupperesti? Te lo chiedo per capire se potrebbe essere un capitolo a se stante o meno!

[Jean85]

Me la immagino come una parte abbastanza di alto livello, in cui sì sottolinea come l'avvento del settore IT e la cosiddetta "digital transformation" ha portato una accelerazione mostruosa nei ritmi di lavoro e di evoluzione dei processi, e che ci si è accorti che il "soft" in software ha una proprietà di malleabilità talmente forte che non sfruttarla è uno spreco. Da qui l'adozione delle varie pratiche (dal lean al continuous improvement, dal TDD alla CI) e come queste cose si trasformano in strumenti vitali nella vita di ogni giorno dello sviluppatore e, in modo più allargato, nella vita di qualunque azienda abbia un briciolo di reparto IT al suo interno.

Visto che cita troppi argomenti, mi sembra una introduzione a capitoli successivi che poi potrebbero approfondire le varie tematiche. O, alternativamente, un capitolo "finale" di sintesi che raccorda questi temi per sottolineare il filone unico, quasi come una morale.

[Cadienvan]

Credo possa valere la pena, cosa ne pensi di proporre un nuovo capitolo e occupartene in prima persona con un ambassador a supporto? Ti basta aprire una issue e seguire il template! Fammi sapere!

[Jean85]

#210 👍

[sensorario]

Mi piacerebbe ragionare con qualcuno sul capitolo #80 perché che si faccia una app from scratch o che si usi un framework l'architettura che viene fuori è bene o male sempre quella. Anche di DDD si potrebbe parlare. Chi ha voglia di fare due chiacchiere?

[Cadienvan]

Ciao @sensorario, un contributor vorrebbe parlare di qualcosa di simile (#219, appena chiusa proponendogli di aprire apposita issue), che ne dici di contribuire lì?

[sensorario]

Si ho letto. Solo che lui parla di testing e di metodologie di sviluppo. Mentre e #80 è struttura del codice ed organizzazione.

[Cadienvan]

Mmmh, ok, ci può stare..
Io sai bene che difficilmente posso avere tempo di co-autorare, però volentieri se vuoi provarci io ti do tutto il supporto che riesco a dare!

[BrianAtzori]

Ciao @sensorario dal basso della mia esperienza anche io posso provare a darti una mano, anche solo per feedback o review varie... oltre ad esempio al DDD avevi in mente altri punti?
Se dovessi provare a buttare giù gli argomenti quali sarebbero? Perchè secondo me può essere interessante come argomento da snocciolare!