Capitolo Leadership#231
Conversation
|
Ha dato errore perchè non sono stati rispettati i livelli del markdown passando da un H1 direttamente ad un H3. |
Cadienvan
left a comment
There was a problem hiding this comment.
Mi piace moltissimo, e conoscendoti rispecchia molto la tua filosofia. Ho messo alcuni suggerimenti di forma o di chiarificazione di alcuni termini. Farei solo una cosa:
Introduzione relativa al fatto che parliamo di un capitolo "personale" e che come è giusto che sia deve essere paragonato e confrontato con la propria esperienza e il proprio modo di pensare. Creerebbe il giusto mood per la lettura.
Per il resto top! Come sempre, sentiti libero di accettare ciò che ti torna e di rifiutare ciò che non torna!
BrianAtzori
left a comment
There was a problem hiding this comment.
Che dire, questo è veramente un ottimo capito, fantastico, tra l'altro -cosa non scontata- molto scorrevole e ben scritto! Non ho trovato errori o ripetizioni ✅
AngeloAvv
left a comment
There was a problem hiding this comment.
Mi piace! Ho aggiunto qualche integrazione, spunto di riflessione e correzione! Nice work 💪
|
@EMCestari porto in bozza per darti il tempo di ri-lavorare i contenuti quando il tempo lo consentirà! |
Co-authored-by: Michael Di Prisco <Cadienvan@users.noreply.github.com> Co-authored-by: Angelo Cassano <angy.avv.94@hotmail.it>
sensorario
left a comment
There was a problem hiding this comment.
Ho più che altro lasciato dei commenti secondo il mio modesto punto di vista.
serenasensini
left a comment
There was a problem hiding this comment.
Ottimo capitolo (non che avessi dubbi). Ho sistemato un po' di generi, ed espresso qualche dubbio su alcune frasi che non mi tornano. Al netto di questo, è una buona partenza per comprendere meglio il ruolo della leadership, anche se sarebbe interessante aggiungere -in futuro- dei riferimenti "pratici" su come lavorare in quella direzione, per chi aspira a farlo. Magari errori comuni... ti ricorda qualcosa @EMCestari ? 🙄
|
|
||
| Partendo dai due concetti espressi si può arrivare ad un’altra distinzione chiave tra un ruolo tecnico ed uno manageriale: | ||
|
|
||
| - Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo considerando un _contesto sano_, no?) |
There was a problem hiding this comment.
Sai che questo va contro la linea di pensiero della maggior parte dei grandi nomi del settore? Per dirne una: https://nunoalexandre.com/2016/01/06/the-zone-and-interruptions
Bada bene, il mio è un commento puramente soggettivo, e la flow zone può far più male che bene. Ma poi, come in tutto, dipende...
There was a problem hiding this comment.
@serenasensini si, so che è un tema dibattuto e probabilmente nel mio testo non emerge sufficientemente il senso; quello a cui mi riferisco è un context switch sfrenato tra argomenti anche molto diversi, che è tipico del management.
Mentre se parliamo di pair programming, qui già il discorso cambia; non entri in uno stato di "flow" classico, ma hai comunque un focus su un task at hand di un certo tipo. Personalmente quando sviluppavo mi trovavo meravigliosamente quando riuscivo ad alternare stati di flow puro a stati di concentrazione diversa (tipo appunto pair o confronto con il resto del team su quanto elaborato), però di certo quelle distrazioni completamente avulse dal mio obiettivo primario mi lasciavano una percezione di performance ridotta.
Come potremmo rivederlo a livello testuale in modo che emerga meglio il concetto? (sempre ammesso che sia già riuscito a spiegarmi nel commento :D )
There was a problem hiding this comment.
Ecco, andrei a specificare che ci sono scenario diversi, come quello che hai descritto. Giusto per non incorrere nell'errore di pensare che un modo di ragionare sia più giusto di un altro....
|
|
||
| - Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo considerando un _contesto sano_, no?) | ||
|
|
||
| - Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma dovrebbe accettare sia un context switching frequente tra compiti anche molto diversi che una visione più ampia a livello di domini ed ambiti di azione |
There was a problem hiding this comment.
Questa frase non mi è chiarissima... Il context switch "aiuta" ad avere una visione più ampia? O è una condizione in cui il/la manager si trova di frequente?
There was a problem hiding this comment.
@serenasensini Per un manager, entrambe le cose - è conditio sine qua non, nel senso che un momento ti ritrovi a discutere col team di una scelta tecnologica, il momento dopo ad ascoltare col resto del management una decisione strategica a livello commerciale, quello dopo ancora a prestare attenzione alle dinamiche di team per assicurarti che non ci siano temi su cui intervenire, e così via... Questo da un lato ti impedisce di focalizzarti davvero su una singola cosa ma al tempo stesso ti garantisce una visione più trasversale. Ti torna? Lo riscriveresti in modo più chiaro?
Co-authored-by: Serena Sensini <serena.sensini@gmail.com>
Co-authored-by: Serena Sensini <serena.sensini@gmail.com> Co-authored-by: Simone Gentili <sensorario@gmail.com>
Co-authored-by: Serena Sensini <serena.sensini@gmail.com>
Co-authored-by: Serena Sensini <serena.sensini@gmail.com> Co-authored-by: Simone Gentili <sensorario@gmail.com>
serenasensini
left a comment
There was a problem hiding this comment.
Direi che al netto dei due commenti, ci siamo! 🚀
|
|
||
| Partendo dai due concetti espressi si può arrivare ad un’altra distinzione chiave tra un ruolo tecnico ed uno manageriale: | ||
|
|
||
| - Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo considerando un _contesto sano_, no?) |
There was a problem hiding this comment.
Ecco, andrei a specificare che ci sono scenario diversi, come quello che hai descritto. Giusto per non incorrere nell'errore di pensare che un modo di ragionare sia più giusto di un altro....
Modifiche sulla base dei suggerimenti di @serenasensini (GRAZIE!!! ❤️🙌)
|
@Cadienvan da sistemare elementi da layout non-IT prima del merge |
af7d17c
Ciao a tutti, ho creato un draft per il capitolo sulla Leadership.
In particolare @elgorditosalsero e @AngeloAvv visto che anche voi volevate lavorarci fatemi sapere se vi torna o se volete proporre cambiamenti/aggiungere qualcosa! :)