Newsgroup: it.lavoro.informatica
Titolo: Pair programming

http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business

CDO

 
http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business
chi viene "controllato" e' a rischio (a meno che non sia un novellino
o lavori su cose banali), perche' regala molti dei suoi skills pratici
e diventa altamente sostituibile. Mettiamo ad esempio che in un gruppo
c'e' uno (ed uno solo) che sa molto bene SAP, ha studiato tanto, s'e'
fatto tanta gavetta, etc, e c'e' un ruspante novellino che vuol far
carriera e costa poco. Il ruspante novellino impara SAP (e altro) in
meno che non si dica (vuoi mettere seguire minuto per minuto un
esperto a lavoro vs. fare anni di teoria ed esercizietti del
piffero?), e al pluridecennale con esperienza diminuisce il suo potere
contrattuale.
Ancora piu' inquietante: se si fa a ruota, tutti sanno un po' di
tutto, quindi son *tutti* piu' sostituibili. L'azienda puo' fare
manovre sul personale moooolto (ma mooolto) piu' facilmente.


che tristezza questo intervento :-(
Quelli come te sono i primi che faccio fuori in un team, se riesco
ce ne ho uno giusto adesso in team ma vedi che fine fa
Io insegno tutto quello che posso agli altri, non tanto perche' sono un
benefatttore, ma perche' il team si potenzia, arrivano risultati migliori,
si centrano i traguardi , chiedo molti piu' soldi .........
Se la gente capisse che non si combatte contro il collega, ma contro il
progetto stesso e i concorrenti ..
Avanti cosi' Tirzanello e speriamo per te che nessuno si accorga di che
pasta sei fatto, ma non contasrci , la gente non e' mica scema.
Inoltre cosi' facendo non  potrai mai coordinare un team e quindi fare
carriera
Nicola
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 tutto, quindi son *tutti* piu' sostituibili.
italiota.


Io qualche esperimento molto alla buona di pair programming l'ho fatto, con 
consulenti o stagisti, magari per superare rapidamente qualche scoglio 
ostico; la mia impressione � positiva: si lavora molto concentrati ed � 
molto pi� difficile perdere un sacco di tempo intorno a cose banali perch� 
non viene l'intuizione giusta, lavorando da soli. Per contro, un p� di tempo 
a volte � necessario per aggiornare l'altra persona se rimane indietro (e 
viceversa).
Invece questa tecnica "Pomodoro"
That schedule of working 25 minutes and then taking a 5-minute break is a 
time management technique called Pomodoro
mi lascia parecchio perplesso: per recuperare dopo un break ci vuole un bel 
p� di tempo e se i break avvengono ogni mezz'ora la produttivit� secondo me 
ne risente. Meglio break pi� lunghi ma pi� radi, secondo me. Avevo trovato 
degli articoli in cui si stimava il tempo di "context switching" in un 
quarto d'ora e mi pareva molto ragionevole 

 CDO
Erudiscici: hai fatto pair programming con uno che "sapea di vorpe" e sei 
rimasto sotto shock? 

 carriera
rileggi d) prima di sparare per preconcetti.

 
http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business
Mi capita spesso di lavorare in situazioni di pair programming, spesso
quando c'è da integrare un pezzo di applicazione che uno dei due
conosce molto di più dell'altro, e che all'altro costerebbe molto
tempo per arrivare al necessario livello di conoscenza, oppure quando
c'è qualcosa di particolarmente misterioso dove due cervelli hanno più
possibilità di arrivare ad una soluzione rispetto ad uno, e via di
questo passo.
BTW quella del pericolo di diventare tutti sostituibili, IMVHO è FUD.
In primis perchè alla fine siamo in ogni caso tutti sostituibili, ma
bisogna vedere a  che costo, e poi perchè non è che il pair
programming trasferisce il cervello di uno all'altro :))
--
ale
http://ale.riolo.co.uk

 e diventa altamente sostituibile.
Se ci riuscisse solo operando in pair programming, allora comunque la
persona ha un basso livello di conoscenze ed e' facilmente sotituibile.
Non per altro: non penso proprio che un'esperienza di anni venga
trasmessa facilmente in cotale guisa... E anche fosse possibile, facendo
pair programming per anni con la stessa persona, mi pare logico e giusto
che, visto che evidentemente opera nel tuo stesso ambito e forse con le
stesse mansioni, abbia alla fine perlomeno le stesse capacita'
dell'altro o di chiunque si occupi di quel settore.
Io non ho mai avuto problemi a trasmettere le mie conoscenze, anzi.
Eppure, nessuno, non dico neanche che sia mai riuscito, ma neppure ha
mai lontanamente tentato di "soffiarmi" lavoro o posto. :-)
E' sotteso anche un altro ragionamento: non so chi come tu sia e non
mi permetto di giudicare, ma se in una ditta dovessi avere la perenne
paura e stress che qualcuno mi soffi il posto (talvolta senza motivo), a
avere le (classiche e conosciute, ampiamente sperimentate dal
sottoscritto con tanto di tentativi di "forca"...) immaginabili e
conseguenti reazioni giorno per giorno, allora prima o poi cambierei
aria...
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 "quelli come te"?
tirzanello, hai fatto un intervento da manette!
poi magari è successo qualcosa: ti sei espresso male, un'ischemia
cerebrale, non si sa
ma il tuo intervento è stato terribile, greve, ignorante e francamente
considerando i tuoi precedenti ha lasciato a bocca aperta
sembrava leggere "la mia conoscenza me la tengo per me e non la vado
certo a spifferare al mio collega sennò mi fa le scarpe"

 manovre sul personale moooolto (ma mooolto) piu' facilmente.
ti do piena ragione , si va verso la socit� della conoscenza , diventa 
preziosa , altro che team !
I team che intendono loro sono questi " scusa come si fa questo ? Come si fa 
quello ? "  Tu rispondi , e secondo loro hanno fatto il team !  Hahahah !
Io metto in condivisione la mia conoscenza  solo se mi inquadrano come 
dirigente : allora s� che insegno a quelli che non sono pi� cos� miei pari , 
ma sottoposti , ci mancherebbe altro ! 

 progetto stesso e i concorrenti ..
In che mondo vivi? Guardati attorno: i reparti informatici di 
praticamente tutte le aziende vengono tagliati, in parte o 
completamente, e di fatto ciascuno lotta per rimanere, che � una lotta 
anche contro i colleghi (inutile chiudere gli occhi e fingere che non ci 
sia, questo � un fatto, che possa piacere a te o a me, o meno. Per la 
cronaca a me non piace, ma non lo sto giustificando. ma solo costatando).
Molte aziende falliscono, qualcuno cerca di nuovo di riavviare 
un'attivit� e di nuovo si contenderanno quelle reliquie reliquiorum del 
mercato ICT, cercando di essere, a parit� di tariffe (andare al di sotto 
delle attuali - gi� da fame - si muore. Di fame), migliori degli altri 
(ovvero concorrenti).
Di fatto si prospetta una selezione naturale (Darwin docet) e la cosa, 
personalmente, la auspico gi� dai tempi della bolla speculativa (prima 
dello scoppio del'2000 nel mondo e in Italia nel 2001), perch� sapevo 
che quella bolla e il periodo post-bolla avrebbe portato 
all'inquinamento del mercato del lavoro ICT, alla proliferazione di 
incompetenza, abassamento di qualit� e di conseguenza, abbassamento 
delle soglie di retribuzione che le aziende potrebbero riconoscere ai 
professionisti. E ditemi che non � successo e che non sta continuando a 
sucededere, di giorno in giorno, sempre peggio, sempre peggio...
Allora, io per anni ho fatto anche la formazione professionale (a 
pagamento, natturalmente) e so che se per padroneggiare i primi 
linguaggi che ho imparato ci ho messo mesi, e ora per imparare uno nuovo 
ci metto settimane o giorni, ma che comunque sono in grado di 
trasmettere la cosa in aula alle persone in giorni o al massimo 
settimane (se gli allunni sono proprio caproni). Dite che se io quando 
ero a "spasso" (dal punto di vista lavorativo) studiavo, e investivo nel 
mio futuro, ora la cosa la devo dare gratis a qualcuno che nello stesso 
periodo "se la spassava" e si godeva la vita? Scusate, mma io dico: COL 
CAZZO! Lo far� solo quando avr� l'azienda mia (work in progress) e 
quando avr� effettivamente l'utilit� economica di avere un team di 
sviluppatori stabile e competente, ma altrimenti picche. Ti insegno 
tutto quello che vuoi  ma mi paghi, perch� io voglio capitalizzare mesi 
e anni di ricerca e sviluppo che ho fatto sacrificando la mia vita 
privata prevedendo (passatemi il termine) questo che ora chiamano 
"crisi". Ed � per questo che le aziende (dove ci sono persone sane di 
mente) quando vi danno accesso alle loro competenze vi fanno firmare i 
vari NDA, patti di riservatezza, di non divulgazione, di non concorrenza 
e tutte quelle scartoffie che ci vengono chieste di firmare.
Per creare competenze adatte per trasmettere una materia uno deve 
leggere un sacco di libri, rileggerli, ririleggerli, e vai avanti con 
altri ririri, conforntare con altri libri perch� magari in quello � 
spiegato male. Provare, testare, fare progetti, crearsi un bagaglio 
notevole di sperienza in mesi e anni di duro lavoro e studio, e devo 
trasmettere gi� in forma distillata questa pappa pronta a qualcuno 
GRATIS? Di nuovo: COL CAZZO. Paghino e lo avranno.
Altrimenti perch� non chiedere alla Microsoft  alla IBM, alla Oracle, o 
a chiunque altro di rilasciare i loro prodotti software come open source 
perch� cos� l'umanit� "si potenzia, arrivano risultati migliori, si 
centrano i traguardi"?

P.S: Non mi riferivo al pair programming ne all'articolo all'inizio del 
thread (mi sono gi� espresso) ma alla questione del passaggio di 
competenze in generale (visto che il thread � deviato). Era giusto per 
chiarire.

 
Completamente d'accordo e lo ripeto da anni.
Chiaramente non sono il solo visto che � una delle regole dell'extreme 
programming (regole da me ampiamente condivise).
Uno dei motivi per cui mi piace (e non � il solo) � che secondo me due 
persone a coppia 40 ore la settimana rendono mediamente di pi� e meglio 
che 2 persone separate che lavorano le stesse ore a testa.
Chiaramente bisogna assortire bene la coppia e non mettere 2 persone 
qualunque insieme.
Se poi sono un uomo e una donna � meglio :-)  (non scherzo! c'� meno 
competizione e si lavora meglio)

 
http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business
Follia. Se uno è abbastanza bravo da starmi dietro è sprecato che stia
a guardare, c'è altro da fare... Che si metta sotto!
I test e le ulteriori idee devono arrivare da chi si occupa del
testing della daily build.
--
Luc

 certo a spifferare al mio collega sennò mi fa le scarpe"
assolutamente no.
Se l'azienda ti impone un collega che ti guarda mentre si lavora, sta
creando un'altra persona in grado di fare esattemente quello che sai
fare tu. Non e' trasferimento di conoscenza, e' trasferimento di "how
to"... che imposto a livello di HR come metodo per produrre, e' (come
direbbe ducalamberti) un bel cetriolone.
Visto che alle HR di solito non ne capiscono nulla di quello che fai,
ma sanno che ci sono 6 persone impiegate "intercambiabili", in momento
di crisi ne segano tranquillamente una o due.
Questo NON centra con quello che faccio io (la mia situazione
lavorativa e' strana, visto che ho il piede in almeno 3 scarpe), e'
come SECONDO ME le HR possono usare questo "pair programming".

 che tristezza questo intervento :-(
Quoto tutto!!

 ma sottoposti , ci mancherebbe altro ! 
peccato che il dirigente faccia un altro mestiere: prende decisioni non 
scrive codice.
Il valore di una persona di concetto ï¿œ dato da quello ceh puï¿œ ancora 
fare, non per quello che ha gia fatto! Se non si capisce questo ...!

 programming trasferisce il cervello di uno all'altro :))
premessa: non parlo di me, ma di una situazione che ho comunque visto
molto da vicino.
Supponiamo che c'e' un apparecchio che e' difficilissimo da usare, del
codice scritto da un fisico 10 anni fa, quasi incomprensibile.
Supponiamo che non trovano nessuno in grado di capirci una mazza.
Chiamano due MOOLTO bravi a lavorarci, sbrogliano la matassa, non
riscrivono il codice, si svenano per mesi e alla fine beccano due o
tre punti dove fare le modifiche che servono. Ogni modifica richiede 5
minuti di tempo, le modifiche non sono cosi' frequenti, e loro costano
un sacco di soldi. Se a questi due gli vai a dire: guarda ti mando
tizio, che "guarda mentre lavori" per il "pair programming" cosi' sei
piu' efficiente.... e poi dimmi dove secondo te questi due ti mandano
per direttissima (e senza passare dal via) :-)
Anzi, in periodi di tagli, uno disse all'altro: "voglio proprio vedere
dove lo trovano uno che sappia dove mettere le mani nelle librerie X",
e giustamente avevano ragione, perche' i cambiamenti che facevano
erano minuscoli, ma dietro c'era un lavoro da cani. Le HR fanno 2+2=4,
mica beneficienza.
Cio' non toglie, che non e' un discorso *personale*, io ripeto, sono
per le vie di mezzo (e non mi piace vivere di rendita), ma comprendo e
rispetto il loro punto di vista.

 fare, non per quello che ha gia fatto! Se non si capisce questo ...!
e se quello che puo' fare e' *fortemente* dipendente da quello che ha
fatto (e per cui si e' sbattuto notte e giorno)?
Ripeto, io personalmente son contrario a campare di rendita, pero'
rispetto chi lo fa, perche' per arrivare a quei risultati s'e'
sbattuto.
E' tanto difficile da capire?

 manovre sul personale moooolto (ma mooolto) piu' facilmente.
Ti tranquillizzo subito. Il genio in azienda non serve! Un team pi� 
giovane ed inesperto ma adeguatamente diretto e motivato � preferibile 
ad un altro con arcigne primedonne gelose del proprio sapere.
La formazione in azienda � una cultura (che in italia purtroppo manca) e 
va a vantaggio di tutti.
Sempre in azienda da noi funziona cosi�: arriva uno nuovo, viene gettato 
nella fossa dei leoni e si spera che in uno o due mesi, per 'osmosi' 
apprenda il 'fare' dell'azienda (che non si capisce neanche qual �). Se 
non ci riesce non � bravo e quindi lo si manda via. Chiaro che questo 
tipo in azienda ha vita difficile, nessuno ha tempo e voglia di 
occuparsi di lui, viene considerato un novellino e contemporaneamente un 
concorrente pericoloso, meno gli si dice meglio �.
Altro approccio �: uno arriva in azienda e un team ha il compito e la 
RESPONSABILITA' della sua formazione. Esiste un programma formativo con 
degli obiettivi chiari e verificabili. Si dedicano specifiche ore la 
settimana alla formazione del nuovo arrivato sia teoriche che di 
affiancamento e nelle periodiche verifiche si valuta sia il candidato 
che il TEAM formativo.
Tale metodologia comporta un investimento per l'azienda ma ha degli 
ottimi ritorni fin dal primo anno di lavoro del nuovo arrivato e non fa 
montare la testa a nessuno perch� il valore dell'azienda � dato dalla 
PROPRIA conoscenza che si esprime nel lavoro e la competenza della 
SQUADRA e non dei SINGOLI.
I geni e gli scienziati li lasciamo ad altri settori.

 persona ha un basso livello di conoscenze ed e' facilmente sotituibile.
Beh no, come dicevo in un altro post, alle volte dopo essersi sbattuti
su codice di terzi per fare alcune "operazioni misteriose", puo'
capitare che l'impiegato "campi di rendita", perche' per una serie di
motivi (leggi "tagli") viene rischiesto solo di mantenere e fare
piccole modifiche. Ma se solo quelle persone sono state in grado di
metterci mani dopo anni di duro lavoro, e per mantenerlo sono
necessarie modifiche in poche righe di codice in punti oscuri, una
volta svelati quei "punti oscuri", le HR non ci pensano due volte a
mandarli a casa e buonanotte al secchio.
Io non sono contro il "pair programming", ma quando e' imposto dalle
HR, beh.... non mi sembra una cosa pulita.
E permetti, che parlari di "pair programming" in questo periodo di
crisi...beh... mi suona di cetriolo, eh! Se poi vogliamo parlare di
liberalizzazione della cultura, quello e' *completamente* un altro
discorso!

 sbattuto.
sei nel settore e epoca sbagliata. Quello che l'anno prima si � fatto in 
un anno, l'anno dopo si fa in un giorno.
Non sono i trucchetti e le righe di codice nel bignami a fare la 
differenza di un buon programmatore (il codice prodotto in azienda 
infatti � accessibile a tutti quelli che ci lavorano e ad esempio il 
codice ABAP di SAP � aperto e puoi vedere i vari moduli come sono scritti).
La differenza � data dall'intelligenza intesa come capacit� di analisi e 
sintesi dei problemi da affrontare, e dalla motivazione e concentrazione 
  (necessarie per produrre il lavoro a volte estenuante).
Ripeto, se pensi che il tuo valore � dato solo dal tuo bignami segreto 
devi sperare che i nuovi assunti siano sempre personaggi mediocri perch� 
il sorpasso potrebbe avvenire comunque.

 carriera
IMHO ti e' partito un colpo mentre stavi pulendo la tastiera :-)
Hai centrato il bersaglio ... ma era quello sbagliato :-)
C'ya
 STeve

 manovre sul personale moooolto (ma mooolto) piu' facilmente.
mi sorprende che in tutto questo tu non abbia fatto alcun riferimento 
all'efficacia o meno della metodologia di lavorare in coppia ai fini del 
raggiungimento dei risultati. le critiche che muovi, piuttosto 
scomposte, si potrebbero applicare a qualsiasi modo di lavorare 
collaborativo: praticamente stai dicendo che secondo la tua concezione 
non esiste il lavoro in team, in azienda siamo tutti contro tutti e 
ognuno ha come priorit� preservare il proprio potere contrattuale. e in 
che modo? remando contro.
ti sembra intelligente?
puntare a far fallire gli obiettivi ti sembra un modo per mantenere il 
"potere contrattuale" nell'azienda?
direi che hai pi� di un motivo di riflessione.

  ho un bel po' di PhD che seguo...
brrrr poverelli....oltre il danno, la beffa :)
Scusa, ma stai scherzando, hai alzato un po' il po' il gomito o sei
veramente un ricercatore universitario?
No, perche' casomai credo sia il caso di inserirti nella prossima
puntata di Iacona sullo sfascio dell' universita' italiana..

 Nicola
Io ero come te.
Sono stato segato per uno che aveva lavorato di fianco a me per 6 mesi e
che costava la met�.
Ma la cosa comica era che io e lui dovevamo fare lo stesso lavoro, solo
che io dovevo andare ad occuparmi "anche di altro".
In realt� sono stato infilato in un gruppo dove ci sono stati i
licenziamenti.
Sar� pure triste quanto detto da tirzanello ma purtroppo � la verit�.
-- 
cambFORZAJ...@liVIVAMILANbero.it
togli le due bestemmie per scrivermi.


 direi che hai più di un motivo di riflessione.
si hanno sempre motivi di riflessione! Il NG serve anche a questo! ;-)

 e tutte quelle scartoffie che ci vengono chieste di firmare.
{Sfogo da frustrato OFF}

 competizione e si lavora meglio)
su questo "italian style extreme programming non sono d'accordo".
Si chiama "pair programming" non "couple programming"...

 testing della daily build.
peccato che sia un attimino tardi rispetto al momento in cui scrivi il
codice...

{plonk-di-un-coglione mode ON}

 I geni e gli scienziati li lasciamo ad altri settori.
straquoto da cima a fondo. Meno male che ogni tanto c'e' una boccata
di aria fresca...

 Sarà pure triste quanto detto da tirzanello ma purtroppo è la verità.
Una volta sono stato rapinato. Da quel giorno mi sono fatto furbo e
appena incontro qualcuno in un posto deserto gli piazzo una martellata
nella fronte, non si sa mai, a scopo preventivo....

 collaborazione piuttosto che di competizione, sarebbe meglio.
sacrosante parole!
cheers!

...mai visto ne' sentito.
Pero' ho conosciuto un programmatore di mainframe che aveva bisogno
di una "spalla"...una sorta di figura consolatoria che durante il lavoro
doveva incoraggiare, rincuorare, e nei momenti di pausa distrarre.
Non serviva capisse niente di programmazione, anzi meglio cosi'.
Altri tempi...:-)
ciao
fm
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4441 (20090919) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

certo a spifferare al mio collega senn� mi fa le scarpe"
io ho infatti l'ho letto proprio cosi'.
Comunque sono d'accordo con tirzanello.
Dipende molto dall'ambiente in cui lavori e dall'attivit� in questione, ma 
IMVVHO chi ha molta esperienza e conoscenze, difficilmente le condivide 
interamente e pienamente ... e  comunque mai  " a gratis".


 puntata di Iacona sullo sfascio dell' *universita' italiana*..
LOL :-) se per ogni c***** che spari ti allungassero due centesimi, a
breve potresti diventare un (troll?) milionario :-)

 fatto (e per cui si e' sbattuto notte e giorno)?
e questo secondo te � positivo per te e la tua professionalit�?
mi spiego meglio: trovi positivo e gratificante il fatto di avere il tuo 
orticello da zappettare in segreto e da difendere coi denti perch� 
ritieni sia tutto quello che ti lega all'azienda?
se la risposta � si, buona fortuna. ma se la risposta � no tieni conto 
che la pair programming come un po' tutte le metodologie "collaborative" 
vuole proprio evitare queste situazioni che sono deleterie per tutti, 
azienda e programmatore.
peraltro guarda, chiunque di noi abbia qualche capello bianco ha pensato 
almeno una volta di essere insostituibile nel proprio ruolo, salvo poi 
constatare che quando le strade si dividono sopravvivono tutti meglio di 
prima. adesso una situazione del genere la trovo non solo mortificante, 
ma anche pericolosa, perch� le aziende che mi hanno concesso il 
privilegio di sentirmi indispensabile sono guardacaso quelle che in un 
modo o nell'altro mi hanno fatto fuori.

 come SECONDO ME le HR possono usare questo "pair programming".
Ti ri-consiglio il libro di Kent Beck.
Ciao,
Marco
-- 


 che vuole segare questo mio amico :-D perche' non ci stanno fondi.
oops, messo una faccna di troppo :-(

 che io dovevo andare ad occuparmi "anche di altro".
:-(
e' purtroppo quello che dicevo anch'io... ci mancherebbe, sono per
collaborare coi colleghi, mai detto il contrario. Ma fare
*esattamente* le stesse cose, lavorando anche sullo stesso PC ed
avere qualcuno che (in tempi di crisi) ti *impone* di lavorare in
coppia sullo stesso PC, inventandosi il nomignolo di "pair
programming" la dicono lunga sulle buone intenzioni.
Inutile raccontarci le storie, le HR funzionano cosi', se non ci son
soldi tagliano, mica pagano i dipendenti ad aria. I primi interni che
perdono la sedia sono i ridondanti.
IMHO e' bene collaborare tra colleghi quando e' sul piano personale,
non imposto, tra colleghi, appunto. Quando viene imposto, mi dispiace,
ma son due cose completamente diverse.

 centrano i traguardi"?
A parte che potrebbe non essere una cattiva idea, ma se li rilasci come
"open source", chi ne viene a conoscenza potrebbe essere una persona non 
"coinvolta nell� attivit� (...) ".
E magari non e' detto che l'azienda voglia mettere tale persona a
conoscenza.


 chiarire.
Ah ecco.. allora cancella pure la mia risposta al tuo post (non avevo
visto questa precisazione)



Quoto e sottoscrivo.


 che la pair programming come un po' tutte le metodologie "collaborative"
[..]
ci sono metodologie collaborative e metodologie collaborative! ;-)
Una cosa molto interessante che facciamo noi, e' un seminario
bisettimanale dove ogni volta uno porta un suo argomento di
particolare interesse, lo spiega agli altri e si discute.
Ci si aiuta a vicenda, etc etc. Ma mai e poi mai mi sognerei di
piazzarmi dietro al PC di un collega! Va bene per due studenti, ma due
professionisti??? Due professionisti che stanno a dividersi il video
per voleri superiori.... boh?!? mi suona da incetriolata! Poi saro'
anche maligno, malpensante, trste, cafone, what else? ma la penso
cosi'.

 che costava la met�.
Mi meraviglio di te...
Lo sai vero perche' avvengono licenziamenti e quant'altro ?
Specialmente in posti come quello al quale immagino tu ti riferisca.
D'altra parte in un certo senso anch'� costavo parecchio. Solo che
non ero io a costare parecchio, bensi' le "bodyrentallerie riunite".
Io costavo meno della la meta'.
Ciao,
Marco
-- 



e' giusto quello che dici,
ma e' anche vero che in questo ng vengono riportate esperienze da situazioni
molto diverse fra loro.
Le tue considerazioni vanno bene in una sorta di mondo ideale, vivendo nelle 
aziende sembra invece che sia in vigore la legge della jungla ...


 anche maligno, malpensante, trste, cafone, what else?
direi piu' triste che altro...

 qualcosa in contrario? :-P
no, per carita', e' responsabilita' di chi ti ha reclutato...(parenti
e amici probabilmente...)
io provo solo immenso stupore....

 Marco
ufficialmente problemi di budget.In realt� se sono magnato i soldi.
Ma come ho sempre pensato, i "viscidi vigliacchi" (TM) che commettono tali
porcate prima o poi verranno prunati ;)
-- 
cambFORZAJ...@liVIVAMILANbero.it
togli le due bestemmie per scrivermi.
questo articolo e` stato inviato via web dal servizio gratuito 


 come SECONDO ME le HR possono usare questo "pair programming".
Imho hai sbagliato analisi. Le aziende con una mentalità come quella
che traspare dai ragionamenti che hai fatto neanche si mette in testa
di applicare il pair programming.
Ciao
Mattia

 Si chiama "pair programming" non "couple programming"...
Vabb� su questa ultima parte apriamo un 3d a parte ;-)

 peccato che il dirigente faccia un altro mestiere: prende decisioni
ma rotfl...ma dove vivi?

 ad un altro con arcigne primedonne gelose del proprio sapere.
fermati pure qui.
le aziende hanno scelto la via dei giovani ed inesperti ma si sono ben 
guardate dal dirigere adeguatamente e dal motivare.
i risultati sono sotto gli occhi dei clienti e dei consumatori.
ovviamente questa scusa permette alle aziende di risparmiare sul 
personale esperto e getta la generazione dei 40-50enni in una sorta di 
limbo (in caso di perdita del lavoro trovarne un altro diventa impresa da 
mission impossible...)

la piega che ha preso il thread mi ha fatto venire in mente un post
che ho letto proprio oggi in un forum in cui si parla (anche) di
informatica
http://www.gamesforum.it/board/showthread.php?p=7454216
"un altra cosa, non crederti tanto superiore a me xke io lavoro al
Media Wor*d al reparto assistenza tecnica pc quindi non ti consiglio
di fare il superbo. "
per sorridere ^__^

 CDO
Nella mia esperienza, su parti complesse, essere in due a decidere
come fare una funzione o come presentare all'utente i dati è molto
utile e produce ottimi risultati.
Poi qui la prendono tutti come "mi mettono uno accanto che mi ruba il
lavoro". Ma quello è affiancamento, non pair programming ! Il pair lo
fai con uno bravo che ti prende in giro mentre scrivi e sbagli
qualcosa, poi magari domani è lui alla tastiera e lo massacri te.


"le aziende" non esistono. Puoi dire che pensi che "molte aziende" o
"alcune aziende" sono cosi' o cosa' ma certo non "le aziende". Il
fatto che tu non abbia mai lavorato per una societa' seria e motivante
non significa che non ne esistano. Magari saranno una minoranza, ma
anche se fossero solo il 5% l'unico risultato del "pessimismo cosmico
italiota" e' contribuire all'estinzione di quel 5%.

 produttivi"... beh, questo mi puzza di bruciato!
si, ma che c'entra?
pair programming � una metodologia di lavoro, mica semplicemente 
prendere due persone e accoppiarle di punto in bianco senza ulteriori 
discussioni. � ovvio che un comportamento del genere insospettisce, anzi 
fa incazzare, ma proprio perch� � fuori dal contesto quindi inopportuno. 
se invece il gruppo lavorasse con quella metodologia non solo non ti 
insospettiresti, ma ti troveresti a lavorare in un ambiente dove tu non 
lo devi mettere in culo agli altri e gli altri non lo devono mettere in 
culo a te...

 qualcosa,
Ecco, � questo che mi fa girare le palle. Gi� avere qualcuno attorno mi 
fa girare le palle, figurati se apre bocca mentre sono conventrato.
 > poi magari domani � lui alla tastiera e lo massacri te.
Si, come no, lo lascio ai bambocci il discorso "chi ce l'ha pi� lungo".

 fossero solo il 5%
hai presente una gaussiana?
ecco, delle code me ne posso anche fregare, il 95% dell'area io continuo 
a chiamarlo "le aziende"

cosi'.
Niete di tutto ci�. Semplicemente, ignori completamente cosa sia il
pair programming. Che detto tra noi, per un professionista e
ricercatore nel 2009, � una cosa che trovo sconcertante. Soprattutto
se si insiste un intero thread a ricamarci sopra una posizione assurda
dopo che altri hanno fatto notare quanto le premesse che porti siano
campate in aria.
Ripetendo: Extreme Programming di Kent Beck, te l'ha suggerito Marco
prima e te lo ripeto cos� che potrai dopo averlo letto e
"sperimentato" parlare di pair programming con cognizione di causa.

per direttissima (e senza passare dal via) :-)
Guarda che ti stai rendendo davvero ridicolo eh... Perch� non la
smetti di chiamare "pair programming" quello che ti pare e inizi a
scoprire cosa significhi veramente? Non ci stai facendo una bella
figura per nulla a continuare cos�, davvero.

 manovre sul personale moooolto (ma mooolto) piu' facilmente.
Al di la del fatto che per un'azienda � sempre un male avere il
'potere' concentrato nelle mani di una sola persona (chiamalo
amministrativo, chiamalo tecnico, il discorso non cambia), per come
l'ho sempre inteso io il pair programming dovrebbe prevedere competenze
abbastanza simili nella coppia. Lo dico in altro modo: come fai a
controllarmi, se non sai cosa sto facendo e perch�? per converso,
perch� mi fai perdere tempo a guardare cose banali che, se le facessi
io, richiederebbero qualche minuto?
-- 
Ciao!
Luca

 competizione e si lavora meglio)
:-)
E poi cominci gia' a preparare il prossimo neoassunto nei momenti di
pausa? :-)
Ciao 

 codice...
Il codice non è scritto sulla pietra. C'è sempre il tempo di migliorarlo. 
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 in grado di starmi a fianco, soprattutto quando il laboratorio era dopo l'ora di ginnastica

 
http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business
asd ma e' roba old che notizia e'???
In italia come al solito e' quasi impossibile da attuare per il
fatto che sembra una perdita di tempo e soldi(conosco una sola azienda 
della mia  zona che la usa).
Imho in alcuni progetti (soprattutto quando sono molto
complessi)l'extreme programming � un ottima soluzione e riduce in
maniera significativa il numero bugs e permette di modellare il software 
esattamente come lo vuole il cliente evitando di fare modifiche 
costosissime a progetto finito! :-D
In usa e' roba degli anni '90, inutile dare giudizi, basta ricercare le 
varie esperienze di progetto di quelli che l'hanno utilizzata!! :-D
cya

 
http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business
La tipa è una mia amica, nonchè la attuale moglie di Obie Fernandez.
E' sicuramente una grande.
Tanto per rimarcare l'ignoranza di alcuni, basta andare su devchix per
vedere di che pasta sono fatte le donne con un computer in mano.
  ngw

 testing della daily build.
Luc, se uno è "abbastanza bravo da starti dietro", probabilmente non è
una persona ma la carmencita che tenete in ufficio.
Pensaci.
  ngw

 per direttissima (e senza passare dal via) :-)
Con questo esempio stai giustificando in toto le critiche che ti sono 
state fatte e alle quali hai risposto che non avevano capito cosa intendevi.
ciao, Soprano

 
http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business
Stano che nessuno l'abbia detto: questa tecnica riduce/ridurrebbe in 
modo sensibile il cazzeggiamento (chat, internet, social etc.). In 
questo senso la produttivit� aumenterebbe in modo considerevole, anche 
se adottata in una porzione della giornata lavorativa. Inoltre per 
esperienza in generale lavorare in coppia o in team porta sempre a 
cercare di migliorarsi o di produrre al meglio, visto che ci 
confrontiamo giornalmente con qualcuno che assiste al nostro lavoro.
ciao, Soprano

 Hai centrato il bersaglio ... ma era quello sbagliato :-)
Dalla mia esperienze, ben poche aziende hanno specialmente tra
sviluppatori questo genere di competizione, mi sa che è frutto del
solito "cavallette, cavallette !" tipico di chi pensa che l'Italia sia
una specie di prova della legge di Moore.
  ngw

 rendere i dipendenti piu' sostituibili.
Ah beh, altro par di palle.
Fosse così, spero l'HR sappia correre forte.
  ngw

Soprano (ex UC) ha scritto:

quoto in toto! :-D

 una persona ma la carmencita che tenete in ufficio.
Hai ragione.


 confrontiamo giornalmente con qualcuno che assiste al nostro lavoro.
Si, su questo sono d'accordissimo. E aggiungo che all'interno dello 
stesso team serve per poter avere una visione più ampia del codice scritto.
Ciao,
Giulio
--

 bene. :-)
e infatti c'e' la tecnica del pomodoro apposta! :-P

 bene. :-)
Sono d'accordo, infatti ho parlato di proporre il pair per parti della 
giornata lavorativa, ma sarebbe assolutamente controproducente se 
occupasse il 100% del tempo. Personalmente se dovessi condividere il mio 
spazio vitale con altri per tutta la giornata diventerei paranoico in un 
paio di settimane. Gi� lo devo fare a casa con la ragazza ;-)
Soprano

 cambiare.
quoto. Detto altrimenti il "cosi fan tutti" e' un aggravante non un
attenuante.

 Neanche finito il primo quadrimestre che già ero l'unico da solo.
Perche' non mi stupisce? :P

 Perche' non mi stupisce? :P
L'unico solo al terminale grafico a colori. Gli altri erano tutti su scatolotti 
text-based a fosfori verdi... :P


 quarto d'ora e mi pareva molto ragionevole
Ecco, lasciando perdere le beghe e le polemiche sui fraintendimenti,
questa è una cosa da notare sull'articolo, se non altro perchè almeno
io questo "pomodoro" non l'avevo mai sentito e così a primo acchito
sono più che perplesso anch'io: quando si programma la parte più
difficile è "entrare in zona" e dei ritmi con interruzioni così
frequenti apparentemente renderebbero impossibile essere produttivi. A
questo punto sorge la curiosità di capire se non sia proprio il fatto
di lavorare in coppia che rende possibile fare dei "context switch"
veloci.
Ciao!

 (cut)
Quanti sproloqui per quello che io ho definito con una sola parola. :-D
Pi� che altro mi sembra che un articolo sparato cos' per propinare 
un'altra pubblicit� occulta (quella di Apple). Orami la infilano ovunque 
nello stesso modo (non solo la Apple ma tutti): nei film, nei giornali,...

 
http://www.nytimes.com/2009/09/20/jobs/20pre.html?ref=business
Beh non è certo una novità, nè una cosa "scoperta" dall'XP, che per me
resta una raccolta di diverse tecniche derivanti dal buon senso e
dalla buona pratica di programmazione mescolate con un po' di verve
didascalica ;^). Personalmente ho avuto un'esperienza del genere tanti
anni fa, quando ancora principalmente di mestiere sviluppavo, e l'XP
era conosciuta forse solo dal gruppo di lavoro di Beck; è stata
estremamente gratificante, anche se molto estenuante. Concordo sul
fatto che non è probabilmente una cosa che conviene fare per il 100%
del tempo, ma con un "compagno" di pari abilità si riesce a essere
produttivi in maniera veramente esaltante, probabilmente molto di più
di quanto si riuscirebbe a fare stando ognuno al proprio PC e
confrontandosi ogni tanto.
Vero è che qui da noi si lavora sempre in logica "time&material" e
quindi è sempre difficilissimo organizzare questo genere di lavoro,
per colpa del fatto che viene letto come un tentativo di vendere due
risorse per un lavoro che può essere fatto da una :^(
bye!

 text-based a fosfori verdi... :P
gia' allora cercavi consolazione alla desolante solitudine con uno
schermo luccicante eh?
Comincio a capire come si sia sviluppata la tua ossessione per schermi
al plasma e gadget vari...


BTW, � stato scritto da un italiano.
-- 
MySQL and PHP are popular not because of their quality, but despite it.

 schermo luccicante eh?
Come si dice: meglio soli che...
Cmq la scelta di lasciarmi solo è stata fatta dal prof a garanzia del mio 
compagno. :P 


 nello stesso modo (non solo la Apple ma tutti): nei film, nei giornali,...
vabbè questo può anche darsi, anche perchè la PP non è certo "hot"
adesso, forse lo era nel 2001 :^)
bye!

 BTW, è stato scritto da un italiano.
grazie mille per il link... ma devo dire che visto il sito le mie
perplessità sono aumentate! Addirittura la propone come una tecnica
per "qualunque task"... un po' pretenziosetto, no?
bye!


Sembra uno di quei libri che sono sempre in vendita nelle edicole
degli aeroporti e che insegnano come avere successo in tutti i campi!

> ricercatore nel 2009, è una cosa che trovo sconcertante. Soprattutto
Però è interessante vedere come tutti filtrano l'articolo con la loro
esperienza.
Se lavori in un posto dove c'è tensione probabilmente ci vedrai un
tentativo del management di sostituirti.
Se campi su quelle 4 cose che sai fare ci vedrai la possibilità  che
ti rubino il mestiere. ecc..


che e' particolarmente sconcertante nel caso di un ricercatore...

 compagno. :P
dicendo cosi' peggiori le cose.. :)


Ragazzi,
da quel che ne sapevo io, il pair programming si fa con persone che
sono allo stesso livello di conoscenza (altrimenti e' qualcosa di
simile al metodo Montessori:)). C'e' da vedere se e' realmente una
pratica che porta ad aumentare la produttivita' dell'intero gruppo.
La condivisione della conoscenza in un team, inoltre, e' fondamentale
perche' la gente si ammala, ha bisogno di prendersi qualche giorno di
ferie etc., dato che non si puo' avere produttivita' da persone
stressate e sotto tono.
Il problema e' lato azienda, che non dovrebbe basarsi sul
trasferimento di conoscenza per far le scarpe ai senior che costano
tanto (anche perche' l'azienda fallirebbe in meno di 10 anni).

 per "qualunque task"... un po' pretenziosetto, no?
Direi di s�. Comunque c'� gente che usa questa tecnica con profitto. Io,
dopo aver letto velocemente il libro, ho deciso che non mi interessava
provarla, almeno per il momento.


 ufficialmente problemi di budget.In realt� se sono magnato i soldi.
Appunto. Se il problema e' "di budget", facendo un contratto direttamente
a me avrebbero potuto spendere la meta' (compresi anche i costi per il
versamento della r.a.)
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 dicendo cosi' peggiori le cose.. :)
Sincero sooono. :P 


 e infatti c'e' la tecnica del pomodoro apposta! :-P
uh?
Ciao,
Giulio
--

 uh?
:-D � applicabile anche allo studio esempio in poche parole:
Eseguo il lavoro per 25 minuti senza interruzioni(se si e' interrotti e' 
annullato), 5 minuti di pausa e cosi' via... no compromessi lo stop � 
obbligato... personalmente io riesco a stare concentrato molto di piu' 
di 25min pero' a volte cazzeggio un vallo! :-D
http://usabile.wordpress.com/2008/11/17/e-tu-quanti-pomodori-fai-in-un-giorno/
http://www.pomodorotechnique.com/
ciao

 nello stesso modo (non solo la Apple ma tutti): nei film, nei giornali,...
ROTFL !
Ma voi siete pazzi :D
Cioè fotografare l'autrice dell'articolo mentre fa pair programming
sarebbe "pubblicità occulta" alla Apple ?
Guarda che in HashRocket non trovi una macchina non apple neanche a
pagarla. Dovevano cambiare ufficio ?
Secondo me la malafede dovrebbe avere un limite.
  ngw

 una specie di prova della legge di Moore.
Sorry ma l'ho visto spesso e volentieri in Italia.
Magari appunto dipende dalla tipologia di lavoro. Ho sempre lavorato
in ditte che sviluppavano firmware, quindi con posizioni molto
specializzate.
Avere due persone che lavorano sulla stessa cosa e' totalmente
antieconomico.
In teoria piacerebbe anche a me lavorare in coppia con qualcuno.
Non nego le potenzialita' della cosa, ma appunto per essere produttivo
non puoi affiancare per il pair programming qualcuno che deve essere
formato.
Serve qualcuno con la stessa esperienza e non vai a pagare due persone
a meno di progetti ad altissima visibilita', l'1 per cento forse dei
normali progetti.
L'unico motivo per fare quello e' in previsione di una dipartita del
senior.
Questa la MIA esperienza che quindi non e' dissimile da quanto detto
da Tirzanello.
Magari per fare altri tipi di SW e' applicabile, non lo nego.
C'ya
  STeve

 e infatti c'e' la tecnica del pomodoro apposta! :-P
L'unica tecnica del pomodoro che uso e' quella di farmi due spaghetti
a mezzogiorno quando stacco :-)
Seriamente, per la mia esperienza il problema piu' grosso per chi
sviluppa e' proprio quello di non perdere la concentrazione !
L'ultima cosa che uno sviluppatore vuole in genere e' quella di essere
interrotto da un orologio !
C'ya
   STeve

 a guardare, c'� altro da fare... Che si metta sotto!
tu non fai testo, passi met� del tempo a sparare cazzate sui newsgroup e 
lavorando in coppia non potresti pi� farlo, quindi � ovvio che remi contro.


Come ho gi� scritto, a me fa girare le palle solo se ho qualcuno vicino 
quando sono concentrato, figurati se quello apre bocca come i 
sostenitori di PP vorrebbero. E poi, PP con chi? Non mi considero il top 
  coder assoluto, ma penso che discretamente il mio lavoro lo so fare 
(probabilmente lo pensano anche i vecchi clienti che di tanto in tanto 
mi richiamano per offrirmi qualche progetto), ma vedere quanta gente 
incompetente c'� in giro mi vengono i brividi (tanto di capello alle 
rare eccezioni)  Mi basta sentire i discorsi nell'open space, nel 
corridoio e davanti all'immancabile macchinetta del caff�, e vedere gli 
sguardi bovini quando mi chiedono cosa sto facendo e io spiego nei 
temini di scelte implementative (cheness�, hashtable con O(1), pattern 
lightweught o builder, applicazione web implementata come grafo e non 
come albero, ecc). E quelle rare eccezioni menzionate sopra di solito 
convengono con me sull'argomento (ne abbiamo gi� parlato un sacco di 
volte di queste mode del momento prese dal libro "Extreme Programming" 
di Ron Hubbard, cio� volevo dire di Kent Beck).

 lavorando in coppia non potresti più farlo, quindi è ovvio che remi contro.
Premessa: passo 4 ore sul NG e produco per 16 ore di un normo-dotato.
Domanda: quante volte sono più bravo di te?
:-P
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 ricercatore nel 2009, è una cosa che trovo sconcertante.
eccone un altro che va sul personale! Do I know you?
Bon, ho fatto un commento sull'articolo postato, molti che non sono
stati d'accordo son passati ad insulti personali e apprezzamenti
gratuti.
Quello che invece io trovo sconcertante e' che come molte persone
(presumibilmente professionisti) non riescano a vedere al di la' del
proprio orticello. Ti ripeto, do I know you? Prima di sconcertarti,
che ne sai di cosa mi occupo, quanto mi serva il "pair programming"
per il mio lavoro? Sentiamo!
Si stava discutendo, stavo commentando l'articolo, spiegami cos'e' che
ti/vi spinge a a fare attacchi personali, senza peraltro neanche
conoscere l'interlocutore? Bah! Che poi tra l'altro -LOL- ne aveste
azzeccato una :-) Uno che dice che sono restio a scambiare
informazioni, quando tra alcuni dei miei colleghi ci conosciamo
persino la password delle mail personali. St'altro che dice che senza
il pair programming nel 2009 non si  e' professionisti, chissa' i vari
plonkati quante ne hanno sparate :-)

 di un licenziamento (voluto o non voluto).
oggi il mio ex capo mi raccontava di un suo ex collega che anni fa
lavorava su un progetto militare, dopo aver finito il progetto il tipo
ha mantenuto il posto scrivendo del codice praticamente illegibile!
Nota buffa: e' venuto a dirmelo mentre scrivevo della documentazione,
per farmi mollare tutto e andare a pranzo! E' un genio :-)
[Onde evitare fraintendimenti e insulti vari (mi mancano solo le
minacce, e magari qualche testa di cavallo nel letto :D ) non credo
sia una bella pratica, ne' da imitare, ne' la adotto o la adotterei io
ne' il mio ex capo (il prossimo post lo faccio scrivere da un
avvocato, 'un si sa' mai)... pero' a quanto pare il tipo non solo ha
conservato il posto, ma ha anche avuto un sostanzioso aumento, dopo 15
giorni dalla fine del suo contratto, LOL :-) ]


Porta pazienza, ma tale "commento" dimostrava abbastanza chiaramente
che non sapevi cos'è il pair programming. Da quello che scrivi, pare
essere il tizio che ti deve sostituire e solo dio sa che altro.
Non è così, è una tecnica che fa affiancare due sviluppatori dalle
skill se non equivalenti molto simili per aumentarne la produttività e
riuscire a scrivere codice ben più corretto. Se a te non serve, per
ragioni tue, amen.
Ma non puoi pretendere di rispondere completamente alla cazzo e
parlando di un argomento random, senza probabilmente aver neppure
letto il sopracitato articolo, e pretendere che nessuno ti dica
niente. Sai, "gruppi di discussione", funzionano così.
Una discussione *seria* (o, se vuoi, professionale) potrebbe essere
che hai provato, e hai riscontrato determinati problemi. In quel
contesto si può discutere. Se quello che mi dici è "chi viene
"controllato" e' a rischio (a meno che non sia un novellino o lavori
su cose banali), perche' regala molti dei suoi skills pratici e
diventa altamente sostituibile." ti rendi conto che te le tiri dietro
- se poi con il pair programming non c'entra un cazzo io non lo posso
sapere, sapendo cos'è il pair programming, non posso che restare
stupito.
Fare un post alla cazzo capita a tutti, ma non è il caso di fare la
vittima.
  ngw

Nell'ultimo progettino di sviluppo a cui ho partecipato poich� eravamo 
in due, uno pi� addentro alla materia, l'altro pi� addentro al 
linguaggio, abbiamo sviluppato molto in pair, e devo dire che 
l'esperienza � stata molto proficua e interessante.
Molti errori stupidi, di digitazione o simili, vengono eliminati al 
volo, cos� come gli errori di logica. E' un code-review continuo, con un 
pizzico di refactoring. Ognuno di noi cercava di portare la propria 
esperienza nel codice.
L'importante � avere una dose di umilt�, saper accettare le critiche, 
riconoscere i propri errori... e soprattutto essere obiettivi nel 
giudicare le scelte progettuali...
Ad esempio io avevo una certa idea di come impostare il programma, il 
collega un'altra. Ne abbiamo discusso un po e ho deciso che, sebbene 
entrambe avrebbero raggiunto lo scopo, utilizzare l'impostazione del 
collega mi avrebbe dato l'occasione di imparare nuove tecniche...
Quindi, esperienza positivissima...
Devo dire pure che pi� volte ho chiesto a colleghi che sviluppano in 
.NET o che all'epoca sviluppavano in VB, di potermi mettere dietro di 
loro per vedere come sviluppavano... non c'� stato verso !
Eppure io faccio il sistemista... non gli avrei mica rubato il lavoro... 
ma � la mentalit�...

 ha mantenuto il posto *scrivendo* del codice praticamente illegibile!
errata corrige:
*il progetto*="di scrivere il codice"
*scrivendo*="per aver volutamente scritto"

 per farmi mollare tutto e andare a pranzo! E' un genio :-)
Beh io invece ricordo di un caso analogo in cui la societ� ha preferito
buttare tutto e pagare per farlo rifare pur di prendersi la soddisfazione
di cacciarlo a calci nel culo :)
(E' anche vero che questo l'aveva fatta veramente fuori dal vaso, non pago
di aver scritto roba in cui poteva mettere le mani solo lui pretendeva pure
di essere assunto con uno stipendio assolutamente folle. E quando � troppo
� troppo)

eccone un altro che va sul personale! Do I know you?
No, ma ti sei presentato a dovere. Non sai cos'� il pair programming:
lo confondi in pratica con il mentoring, di cui dai descrizione nei
tuoi posts.
In pratica, data una bottega dell'artigiano, per te quando
l'apprendista viene affiancato al maestro per guardare e imparare come
si lavora, si sta facendo pair. Ma sbagli: quello � semplicemente
insegnare qualcosa ad un altro, ossia mentoring.
Avresti del pair programming nel caso di due artigiani che lavorano
sullo stesso mobile, dandosi il cambio nelle attivit� manuali e in
quelle di supervisione: uno leviga una superfice mentre l'altro
controlla che tutto sia livellato a dovere. E poi change tra i due.
"Collaborazione", per intenderci.
Come vedi, non si tratta di esser daccordo o meno su qualcosa come non
si tratta di "andare sul personale": � che l'hai proprio buttata li
senza cognizione di causa e scusa ma non � "poco" per un
professionista...

 diventa altamente sostituibile."
mai detto questo!!! Anzi.. ho detto chiaramente che lo scambio di "how
to" potrebbe essere potenzialmente pericoloso (l'ho scritto in un paio
di post).
Ti racconto una storia (purtroppo non posso andare nei dettagli): ci
sono delle persone che conosco che lavorano su delle librerie
sviluppate da un fisico (M.H.), un genio, in 6 mesi per la compagnia
X. Questo qui in sei mesi (nel 2002) ha tirato fuori dal nulla una
cosa che era inimmaginabile per l'epoca. Poi X ha venduto tutto a Y,
ma Y non e' riuscita ad accaparrarsi M.H. e ha assoldato un'intera
equippe di gente con le OO per sbrogliare la matassa. Dopo 2 anni (2
anni!!!!) L'equippe e' finalmente riuscita a *capire* cosa quel genio
avesse combinato in 6 mesi. L'equippe ora *sa* come mettere mani, ma
se un pincopallo qualsiasi *capisce* quali sono i punti critici del SW
(per i quali ci son voluti 2 anni, e per i quali un'azienda Z e'
*fallita* perche' non e' riuscita a far funzionare l'accrocchio, dopo
averci messo dentro una barca di soldi) l'equippe ritorna a casa.
Il passaggio di Skills e' spiegare la teoria che c'e' dietro. Il
passaggio di "how to" e' spiegare "come fare a".
Per spiegare/capire la teoria ci vogliono anni, pazienza e sacrifici.
L'"how to" lo capirebbe anche un ragazzetto di terza media, e
manderebbe a casa un'intera equippe di gente con le OO (che ha
famigghia). Ora, non dico che e' sempre cosi', o e' cosi' in tutte le
realta'... ma a cucirci sopra tutto sto popo' di flame.... :-)

 di cacciarlo a calci nel culo :)
Si, ma li' non si parla di gente comune (m'ha nominato il tipo e lo
conoscevo di nome). Quelle son persone che non trovi dietro l'angolo o
alla fermata del tram ;-)

 tuoi posts.
nope, I know exactly what they are.
La lezioncina la insegnano a scuola, quello che dicevo io e' che
(spesso) nella vita pratica le HR ne conoscono una piu' del diavolo.
Punto.

 realta'... ma a cucirci sopra tutto sto popo' di flame.... :-)
Non per voler continuare o alimentare il flame, ma quello che dici non
mi torna manco per un po'.
Se questa libreria è un oggetto così ostico da utilizzare, non capisco
come possa essere sfruttata da programmatori imberbi; e se è stata
scritta da una persona geniale, perchè è così complicata? :^)
Il punto è che non è chiaro cosa intendi quando parli di lavorare "su"
o "con" questa libreria: l'oggetto del lavoro è lo sviluppo e
l'evoluzione della libreria stessa, o il semplice sfruttamento della
libreria tramite chiamate alla relativa API dall'interno di altri
programmi?
Nel primo caso non vedo proprio come l'esperienza e lo skill di
sviluppatori esperti possano essere allegramente sostituiti da
programmatori imberbi. Nel secondo caso, è *desiderabile* che anche
dei programmatori imberbi possano lavorarci dopo una semplice
formazione (in genere basta per l'appunto la documentazione delle API)
e non si capisce perchè dovrebbe essere mantenuto l'incarico e lo
stipendio ai "guru" che hanno domato la bestia.
Senza polemica, e senza allusioni personali - quindi non sto parlando
ne' di te ne' di nessuno dei partecipanti al thread, ok? - nella mia
esperienza ho sempre visto che chi sostiene la tesi della ritenzione
della conoscenza come strumento di job security sopravvalutava sempre
tanto, ma tanto, la propria conoscenza in questione. Perchè solo se è
una conoscenza limitata e molto puntuale può assumere una rilevanza in
tal senso: una conoscenza profonda e ben sfruttabile non la passi
spifferando tre concetti, per comunicarla ci vogliono in pratica
esattamente tutti gli anni che ci hai messo a formarla, perchè chi la
riceve dovrà impegnare esattamente lo stesso sforzo che ci hai messo
te per digerirla. TANSTAAFL.
Personalmente non ho mai avuto problemi a comunicare conoscenze a
colleghi, anche della concorrenza. Tanto, se non hanno il background
giusto per capirle, non saranno mai in grado nè di ritenere le
informazioni nè di generalizzare per reimpiegarle. E se hanno invece
già il grado di conoscenza necessario per farlo, non ci rimetto nulla
comunque, quindi tanto vale evitare di fare la fava, che dal punto di
vita umano premia sempre :^)
bye!

 bel gran mal di fegato
e magari non ti fai schifo quando ti guardi allo specchio...

 volte di queste mode del momento prese dal libro "Extreme Programming"
gia' gia', mode passeggere lanciate da un gruppuscolo di poveri
svitati. Kent Beck, Martin Fowler, Ward Cunningham.... meno male che i
veri guru dell'informatica come te e i tuoi pochi colleghi
("eccezioni") ci aiutano a capire i veri valori....

 Premessa: passo 4 ore sul NG e produco per 16 ore di un normo-dotato.
Non sapevo che avercelo piccolo facesse programmare piu'
velocemente! :)

 per il mio lavoro?
Puo' benissimo non servirti ma non sapere cosa sia dimostra che sei tu
quello che vive segregato nel proprio orticello... (custodendo
gelosamente quelle tre cosette in croce che lo mantengono ancora in
vita, evidentemente..)

 mai detto questo!!!
e se l'ho detto mi sono frainteso (cit.)

 nope, I know exactly what they are.
evidentemente 'sto poveretto pensa che scrivere in inglese gli dia
piu' tono :)
Cosa non darei per vederti "in action" all'universita'....


quoto in toto.

 quoto in toto.
Io quoto in parte, e faccio riferimento alla mia esperienza su Windows 
CE: c'ï¿œ voluto un paio di mesi per addentrarsi nell'ambiente, se 
qualcuno mi avesse dato delle dritte su come fare, avrei risparmiato due 
mesi di lavoro. Certamente se non sapessi fare nulla, sarei andato poco 
avanti, anche con le sue ipotetiche dritte.

 e magari non ti fai schifo quando ti guardi allo specchio...
Non vedo perche' dovrei farmi schifo per constatare che non posso
combattere la maggioranza.
Ti senti superiore perche' cerchi di fare qualcosa di impossibile e
inutile ?
Se ti accontenti di questo, beh contento te ... ci sono molte altre
cose che si possono fare "al posto di" combattere mulini a vento.
C'ya
   STeve

 Cosa non darei per vederti "in action" all'universita'....
Capire qualcosa magari aiuterebbe  ...

 professionista...
Magari si puo' riassumere piu' semplicemente il discorso di Tirzanello
(visto da un HR tipico) : "Affianchiamo qualcuno al tizio che e' bravo
cosi' lo possiamo fare fuori e risparmiare un po' di soldi, ma
chiamiamo il tutto "pair programming" che fa figo e magari il tizio
non si insospettisce ed e' pure contento di credere di lavorare in un
ambiente giovane, dinamico e stimolante".
Poi si possono aprire anche tanti altri discorsi paralleli, tipo
quello per cui non e' detto che il pair programming sia adatto per
qualsiasi tipo di sviluppo SW o tipologia aziendale e, perche' no,
carattere del singolo.
C'ya
  STeve

 ("eccezioni") ci aiutano a capire i veri valori....
Certo che se aspettiamo una cima come te stiamo freschi ...


Graziue per aver postato il commento che, dato che quel coglione l'ho 
plonkato (e lui lo sa), non avrei potuto immaginare quanto sia viscido.
Risponde a chi non gli pu� rispondere e gode dell'apparenza di 
superiorit� retorica. E' pi� viscido di quanto avrei potuto immaginare.
E dimostra anche di avere coda di paglia. Sta ringhiando proprio perche 
si riconosce nella categoria degli imcapaci che ho descritto.
Non � che mi sorprende, eh...

 velocemente! :)
Vero, quando programmo è piccolo. Quando programmo. :P 


 di 25min pero' a volte cazzeggio un vallo! :-D
Uhm... non saprei. Il ilmite dei 25minuti a volte può essere decisamente 
limitante (e tutta la cosa in ).
Senza contare che se ascolto Bach, le sonate per pianoforte solo di 
Mozart o gli Hardcore Superstar posso stare in zona di altissimo 
rendimento anche per *ore*... :-)
Ciao,
Giulio
--


perche' e' evidente che avere come unico criterio morale "il
comportamento della maggioranza" e' squallido, riduttivo, disumano e
pericoloso. Se si accetta questo criterio ogni volta che "la
maggioranza" per un motivo o per l'altro raggiunge uno stadio di
comportamento criminale o semplicemente stupido non c'e' modo di
uscirne. Ti faccio un esempio drammatico per aiutarti a capire: ai
tempi della seconda guerra mondiale chi era la maggioranza? I
tedeschi , i fascisti o i partigiani? Chi e' che si poteva guardare
allo specchio senza farsi schifo?
Poi e' chiaro che ci sono tanti modi per cercare di migliorare
l'ambiente in cui si vive, ma certo borbottare "e' inutile comportarsi
correttamente visto che la maggior parte della gente non lo fa" e'
solamente squallido e nocivo.

 ambiente giovane, dinamico e stimolante".
No, non si puo'. Come hanno gia' fatto notare quello e' affiancamento
e non pair programming.
Pair programming e' una tecnica condivisa da tutto il gruppo che
lavora sullo stesso progetto non solo da due. Inoltre ha un senso
quando le competenze dei due programmatori sono paragonabili non
quando uno puo' solo imparare dall'altro. Ora ti pare che ci sia
bisogno di ordire complotti per sostituire un poveretto che non
capisce queste cose???

 superiorità retorica.
Quando leggo delle stupidaggini io do la mia risposta, poi chi ognuno
e' libero di leggerle o meno..

 Il codice non è scritto sulla pietra. C'è sempre il tempo di migliorarlo.
vero, ma da buon programmatore dovresti sapere che prima viene
individuato un difetto, meno costoso risulta eliminarlo.


Non saro' una cima, ma almeno non vado delirando sul fatto che una
delle metodologie di programmazione piu' influenti degli ultimi dieci
anni, sostenuta da "cime" come Beck, Fowler e Cunningham sia "una
moda". Un'affermazione cosi' nel 2001 avrebbe dimostrato solo un
notevole grado di rigidita' mentale, oggi dimostra che sei indietro di
almeno 10 anni...

 veloci.
Questo e' un discorso molto interessante. Per quel che riguarda la mia
esperienza ti posso dire che io ho fatto pair programming ma senza
usare la tecnica del "pomodoro" e con interruzioni molto piu' lunghe,
dell'ordine dell' ora. Devo dire che in effeti lavorando in pair il
ritorno "in the zone" e' molto piu' veloce che lavorando da solo.
Credo sia dovuto al fatto che lavorando in pair si realizza una specie
di risonanza mentale che ti aiuta a eliminare gli altri pensieri e a
concentrarti nuovamente sul problema. Per chi non ha mai fatto pair
programming e' un meccanismo simile a quello che si realizza quando
prepari un esame all'universita' insieme ad un altro studente. Gli
intervalli di 25 minuti sembrano brevi anche a me, ma penso varrebbe
la pena di provare. Si parla comunque di break minimi (5 minuti) che
potrebbero funzionare solo per alleggerire la tensione senza farti
perdere troppo di vista il problema da risolvere.

 avanti, anche con le sue ipotetiche dritte.
Questo penso sia un discorso leggermente diverso: rientra nel caso in
cui un aiuto da una persona già esperta in un settore può velocizzare
il tempo di apprendimento di alcune tecnologie, soprattutto se hai già
un background che ti permette di "assorbire" rapidamente questi input.
Se si parla di queste cose si parla proprio di formazione, che io
escludevo nel mio discorso di prima, che era relativo solo al semplice
concetto di "lavorare assieme" (non so come meglio definirlo). Come
già molti hanno fatto notare, il caso in cui c'e' una persona che per
mandato insegna ad un'altra non sta sullo stesso piano rispetto a due
persone che lavorano insieme allo stesso progetto, anche se ovviamente
il confine tra le due situazioni è fuzzy e c'e' tutta una gamma di
possibilità nei rapporti che è quella tipica delle dinamiche di
relazione (a meno che il tuo compagno non sia giapponese, in qual caso
sarà dura tirarlo fuori dallo schema sensei-senpai ;^))
bye!


Dai, io per carità ti rispetto e ti leggo con interesse, ma qui stai
facendo il disfattista.
Ci sono posti di lavoro di merda, verissimo, ci sono sia in Italia che
negli Stati Uniti, che gli Stati Uniti siano questa sorta di Atlantide
della programmazione non è vero, c'è sicuramente un mercato del lavoro
molto differente (e per me migliore, più meritocratico), ma che
l'Italia sia messa *così* male non è vero. Ci sono fior di aziende, in
molte di queste i tecnici sono arrivati a ricoprire ruoli importanti
(e per motivi pratici, non perchè si sono messi a 90).
Combattere la maggioranza è un dovere, magari perdi 9 volte, ma alla
decima vinci. Altrimenti non servi ad un cazzo, ed è meglio che te ne
vai.
  ngw

 Non è che mi sorprende, eh...
Senza entrare nel flame, questa è una fallacia usenettiana gigantesca! Tu 
sei liberissimo di plonkare qualcuno, questo qualcuno è liberissimo di 
continuare a risponderti, ci mancherebbe altro! Il plonk è una tua scelta 
personale, non un'imposizione a qualcun'altro.
-- 
Vide


Permettimi di dubitare che quello era il suo ragionamento. Negli altri 
post ha dimostrato di essere un troll e un coglione, non vedo perché in 
questo caso poteva essere diverso. Se hai qualche dubbio rileggi il suo 
post e anche quello di qualche giorno fa per il quale l'ho plonkato.


Temo che non abbia proprio afferrato il punto... o forse sta solo
cercando di battere il record di stupidaggini dette in un solo thread?

 La lezioncina la insegnano a scuola, quello che dicevo io e' che
Che lezioncina e che scuola ?
E' una tecnica precisa, si può confutarne la bontà, definirla fuffa,
esserci contro, ma è una tecnica di programmazione inventata da
programmatori ,usata da programmatori.
Aggiungo che il solo fatto che venga imposta la dequalifica
immediatamente come pair per il semplice fatto che si suppone
utilizzata in contesti dove i programmatori possono decidere come
lavorare, come organizzare il team e gli strumenti.
Tanto per capire che non se l'è inventata l'articolista :
http://www.amazon.com/gp/search/ref=a9_sc_1?rh=i:aps,k:pair+programming&page=1&keywords=pair+programming&ie=UTF8&qid=1253624300

 Tanto per capire che non se l'è inventata l'articolista :
http://www.amazon.com/gp/search/ref=a9_sc_1?rh=i:aps,k:pair+programmi.
..
Ma si è vecchia di almeno 10 anni (di più in realtà).
Che ci vuoi fare ...
  ngw


http://blog.obiefernandez.com/content/2009/09/10-reasons-pair-programming-is-not-for-the-masses.html
:-)
  ngw

 bye!
cheers!

 :-)
Beh, guarda che ti ho trovato io :
Williams, Laurie, Robert Kessler, Ward Cunningham, and Ron Jeffries.
2000. "Strengthening the
Case for Pair Programming." IEEE Software 17 no. 4
da un bel libro : Facts and Fallacies of Software Engineering di
Robert L. Glass
che mi sono andato a rispulciare per l'occasione.

 ci riescono anche bene. Personalmente non approvo, ma tante' ;-)
la tecnica di trattenere il know-how non solo non paga nel medio-lungo 
periodo, ma � addirittura dannosa. nel breve ti pu� anche gratificare, 
ma appena la cosa crea il pi� piccolo ma inevitabile disagio (es. c'� 
bisogno di un intervento mentre sei in ferie o ti viene la febbre in un 
momento non opportuno) ecco che il vento gira di 180 gradi perch� 
improvvisamente l'azienda si rende conto che il tuo atteggiamento 
costituisce un problema. allora s� che ti *impone* l'affiancamento e di 
passare le competenze ad un altro, ma a quel punto per� non sar� per 
sana collaborazione bens� con il preciso intento di neutralizzarti.
magari guarda meglio fra quelli che conosci te, vedrai che il "campare 
di rendita" � grazie ad altri fattori (leggi: qualche santo protettore 
in paradiso).

 realta'... ma a cucirci sopra tutto sto popo' di flame.... :-)
Quindi riassumendo :
Una Azienda molto brava chiede a un fisico che per hobby fa il developer
di scrivere una libreria SW.
Il fisico in 6 mesi scrive una porcheria illeggibile e sparisce.
La super SW house allora assolda una intera EQUIPPE con le palle che usa 2
anni della propria vita a capire la porcheria del fisico developer per
hobby 
A questo punto questi fenomeni cercano di occultare le loro grandi
scoperte di come ragiona il fisico hobbista develeoper per mantenersi un
posto nella super SW house
COn la pair programming dall'inizio :
Se l'azienda avesse fattao la pair da subito il fisico avrebbe avuto
affiancato un developer ( o nel peggiore dei casi un geologo con l'hobby 
) e l'azienda avrebbe risparmiato 2 anni ( e forse fino alla pensione ) di
stipendi di EQUIPPE
COn la pair programming messa oggi :
L'azienda oggi potrebbe liberarasi di un intero team di super developer
con le palle ( e famigghia ) che hanno impiegato 2 anni ( il tempo di
scrivere un sistema operativo ) per leggere un algoritmo e sostituirli con
2 ragazzini svegli e in gamba
Qua si dice va evitata la pair programming e difeso il super team 
Sono solo io che sono in ginocchio dalle risate o c'e' qualcun altro ?
:-))))))))))))))))
Nicola
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 vai.
????? "combattere la maggioranza e' un dovere" va un zichinino contro
il concetto di democrazia non credi ? Quanto meno va contro il mio.
Quello che uno puo' fare IMHO e' cercare un posto dove la maggioranza
la pensa come te o comunque dove puoi fare quello che ritieni meglio
per te.
Altrimenti siamo alla stregua "dell'esportare democrazia", cosa che se
ricordo bene non e' che approvavi molto ...
C'ya
 STeve

 allo specchio senza farsi schifo?
Hai dimenticato i socialisti. Comunque, credo dopo aver letto parecchia
roba che di fatto non potesse guardarsi serenamente allo specchio
nessuno.
-- 
Ciao!
Luca

 ricordo bene non e' che approvavi molto ...
Porta pazienza, ma non si parla di "democrazia", si parla di
efficienza, capacità, metodo e produttività. Se vado in una società di
pecoroni che di fatto non funziona, mi faccio in quattro per metterla
apposto, ovviamente non con un fucile in mano, ma parlando e spiegando
come fare le cose per bene, con tante belle dimostrazioni e tanti bei
fatti, in modo che anche il meno dotato possa vedere con i suoi occhi.
L'ho sempre fatto, sia a livello tecnologico (per esempio con Python e
Ruby), sia a livello di metodologia (noi si sta utilizzando SCRUM da
un po', non proprio alla lettera, ma buona parte, e con discreto
successo).
Spostarmi ? E per quale motivo, per girare all'infinito finchè non
trovo wonderland ? Che inutile perdita di tempo.
Tra l'altro, *molto* raramente mi è capitato di imbattermi in
avversari di eccezionale intelletto, il 90% di questi problemi sono
creati da gente pigra in tutti i sensi, che cede nel momento in cui
a) ti prendi la responsabilità
b) gli mostri le prove (ed è già raro che se le leggano, 'ste prove)
c) hai l'abilità dialettica superiore a quella di una scimmia
Niente colpi di stato e "tu non sai chi sono io", quindi.
Tra l'altro si vede che sei via dall'Italia da tanto, perchè sapresti
che la grossa e fondamentale differenza tra Italia e USA non è questa
paventata stupidità e cattiveria dove tutti tentano di fottere tutti,
ma la fede inespugnabile verso uno strumento precisissimo in mano ad
ogni bravo manager degno di portare questo titolo: l'occhiometro. Con
una manciata di dati li freghi *sempre*.
Si sa, sono altamente autoreferenziale, quindi mi cito:
http://stacktrace.it/articoli/2007/12/tecnocrazia-rivolta-e-rivoluzione/
  ngw


sono deluso, hai battuto il mio senso dell'umorismo! :)

On Sep 22, 9:00 pm, "Luca Menegotto" <otlucaCAV...@CAVAMIyahoo.it>
wrote:

tanto per rimanere nella "massime",  "chi non ha peccato scagli la
prima pietra", pero' nemmeno
"facciamo di tutta l'erba un fascio"...
Le distinzioni si possono fare eccome.

 ci riescono anche bene. Personalmente non approvo, ma tante' ;-)
personalmente non lo approverai, ma lo sostieni sparando minchiate
come all'inizio di questo thread.
Complimenti vivissimi.

 lightweught
Mr "discretamente il mio lavoro lo so fare "..la prossima volta che
cerchi di impressionare qualcuno con delle buzzword cerca almeno di
essere preciso...
Flyweight pattern non Lightweight... ao' ettecredo che te lanciano
sguardi bovini... :)

 Io non faccio parte di quel progetto ;-)
vabbè, insomma, ti fidi di come te l'hanno venduta. La prendo per
buona, ma la sensazione che t'abbiano raccontato un po' di fregnacce
mi rimane :^)
bye!

 una manciata di dati li freghi *sempre*.
Infatti si vedono i risultati. Sempre meno isole e sempre meno felici.
Oh mica e' un reato pensarla diversamente no ?
C'ya
  STeve

 Che per definizione detta le regole.
Tanto per cominciare la democrazia non e' "la maggioranza che detta le
regole".
La maggioranza promulga delle leggi che pero' devono rispettare alcuni
principi fondamentali (tipo la costituzione..). C'e tra l'altro anche
un'opposizione (ok , te lo riconosco, non in Italia, ma adesso non
penserai mica che l'Italia in questo momento sia una democrazia..) che
e' minoranza per definizione ma non per questo dice:
"vabbe dai..e' inutile opporsi , tanto questa e' una democrazia e la
maggioranza detta le regole" :)
Chiarito questo comune fraintendimento tra democrazia e "dittatura
popolare",mi tocca anche dirti che l ' ordinamento di una nazione non
ha una beneamata fava a che fare con il  cercare o meno di migliorare
le condizioni di vita e di lavoro laddove la media dei tuoi vicini si
comporti in maniera inefficiente, corrotta o semplicemente stupida.
Pensi che in una monarchia sia piu' semplice migliorare il tuo
ambiente di vita o di lavoro?  Inoltre e ' proprio quando la
maggioranza sta prendendo una strada sbagliata che ha senso darsi da
fare per migliorare le cose. Se tutto va a meraviglia che minchia ti
migliori? : P
Ti prego, smetti di renderti ridicolo. Come qualcuno ha gia' detto in
questo thread, capita a tutti di sparare una minchiata, il vero errore
e' ostinarsi a difenderla...

 Oh mica e' un reato pensarla diversamente no ?
Ci mancherebbe, dai ...
  ngw

 muore una fata ?
hehehe questa meritava un post a se.

 cosi'.
Vedi che non sai cos'è il pair programming ?
Questo è ciò che riporta wikipedia:
Pair programming is a software development technique in which two
programmers work together at one work station. One types in code while
the other reviews each line of code as it is typed in. The person
typing is called the driver. The person reviewing the code is called
the observer[1] or navigator. The two programmers switch roles
frequently (possibly every 30 minutes or less).
While reviewing, the observer also considers the strategic direction
of the work, coming up with ideas for improvements and likely future
problems to address. This frees the driver to focus all of his or her
attention on the "tactical" aspects of completing the current task,
using the observer as a safety net and guide.
Abbastanza facile da trovare.
Uno si dovrebbe formare una opinione dopo essersi studiato la materia,
non prima.
  ngw


Chissà a che cazzo ho risposto ...
Scusa eh, è che qua non ho capito bene come funziona, quella roba qua
di usenet :p
Epic fail
  ngw

 nel complicare le cose?
No, gli viene di natura :-)))))))))

 quanto sarei curioso di sapere di che progetti fai parte...
un esempio fresco fresco?
M'e' appena arrivata una mail da una nota rivista scientifica.
topic: Breast Cancer Automatic Detection [etc etc]
As we believe that you are an expert in the field of the above
referenced submission, we would like to invite you to review it.  We
would very much appreciate it if you could find the time to examine
this [etc etc]
Mi chiedono se per favore posso trovare un po' del mio tempo a dare
uno sguardo alla cosa e dire la mia... infatti, pensandoci bene, se
qualcosa ho sbagliato, e' stata nel dedicare parte del mio tempo
libero a dar retta a te e a (pochi) pari tuoi nel flame. Scusa se non
ti rispondo alle varie provocazioni, m'arimbarzano :-) Chiusa
parentesi, tot ziens.

 mi rimane :^)
beh, se son fregnacce, e tuttavia son riusciti a convincere la
commissione del contrario, tanto di cappello ;-)

 commissione del contrario, tanto di cappello ;-)
Succede, succede... che le commissioni scientifiche non son note per
essere particolarmente scafate dal punto di vista strettamente
tecnologico :^)
Non te lo dico per sentito dire ma per esperienza diretta... ma son
cose che non posso raccontare in pubblico.
Ho letto in questi giorni, tra l'altro, una divertente raccolta di
"cantonate" prese da peer reviewer che avevano rifiutato articoli che
non avevano capito e che poi sono diventati capisaldi
dell'informatica... ma ora non riesco a ritrovarla!
bye!

 No, gli viene di natura :-)))))))))
LOL :-)))

 dell'informatica... ma ora non riesco a ritrovarla!
se ti capita, posta ;-)

 dell'informatica... ma ora non riesco a ritrovarla!
BTW, errare e' umano. E' comunque di solito l'editore che ha l'ultima
parola, i reviewer sono solo esperti che danno le loro consulenze
nominati dall'editore, e sono piu' d'uno... in questi casi eclatanti,
la cantonata dovrebberlo prenderla tutti i reviewer che leggono
l'articolo.

 hehehe questa meritava un post a se.
E' troppo bella la metto su fb ...

 Mi chiedono se per favore...
a Mr Bean ma che te traduci.. oltre a pensare di darti un tono
parlando inglese credi di esser l 'unico che lo capisce ? :)
Certo che devono esser proprio messi male questi per aver bisogno del
tuo parere..
Inoltre a dare pareri sono buoni cani e porci.. dammi un esempio di
qualcosa di "concreto", qualche progetto che hai realizzato TU.
Cosi almeno possiamo stare tranquilli che almeno nel tuo caso non sei
diventato ricercatore a forza di calci in culo...

 No, gli viene di natura :-)))))))))
finche' si scherza si scherza, tra le doti migliori e tipiche di un
fisico c'e' proprio l'amore per la chiarezza e la semplicita'.
Tutta la fisica e' un processo che parte da fenomeni apparentemente
non correlati o confusi per trovare delle leggi generali, fondamentali
e il piu' semplici possibile.
Pensa solo a tutto il bordello di fenomeni che hanno a che vedere con
l'elettromagnetismo e  a come possono essere tutti compresi e
descritti dalle equazioni di Maxwell. Puoi dire che la fisica non ti
piace ( anche se sarebbe probabilmente colpa di un cattivo
approccio ..), che non e' "il tuo genere", che non la capisci, che hai
conosciuto un fisico o due che non si sapevano esprimere ( se  e per
quello ci sono persone cosi in tutti i mestieri..) ... ma direi che la
fisica favorisce la complessita' dimostra solo delle grosse lacune di
cultura scientifica.


Eh hai poco da ridere caro mio.. e' ancora piu' grave che tu che
lavori in universita' abbia questi stupidi pregiudizi..
Tanto per dirne solo una che dimostra l'ennesima cantonata che hai
preso, tu hai presente in cosa e' laureato Dennis Ritchie?

 sguardi bovini... :)
Pensa che sono persino andato a cercare in giro documentazione
su sto pattern Lightweight ...
Sono proprio messo male :-)
Cmq i pattern sono moltissimi, non � detto che non sia stato
formalizzato da qualcuno.

 formalizzato da qualcuno.
No no, il fatto che l'abbia citato insieme a Builder, che e' uno dei
"pattern classici" ,e' un chiaro segno che intendesse Flyweight...

 qualcosa di "concreto", qualche progetto che hai realizzato TU.
Ah ciccio, lets make things nice and sparkling clear! Per revisionare
chiedono di solito a *solo* ~5 esperti e sono *sempre e solo* persone
che hanno condotto ricerche e ottenuto risultati nell'ambito
specifico. Quasi sempre prendono la persona che la ricerca l'ha
gestita, raramente chi ha solo partecipato. Quindi, se ancora non ci
dovessi arrivar da solo, dovresti capire da te che ho ottenuto e
pubblicato risultati in campo analogo (coordinando -tra l'altro-
persone in piu' continenti, dipartimenti e facolta'... e nessun
italiano :D )

 pubblicato risultati in campo analogo
beh una volta arrivato a fare il ricercatore a forza di calci in culo
qualche articoletto lo vorremo ben pubblicare no? :)

 Soprano
Si ma siamo un attimo sinceri, anche per dare un finale a questa
discussione. Pair si pair no a parte, bastava che tirzanello si
ritirasse in buon ordine dopo le sciocchezze dette inizialmente e
tutto si sarebbe chiuso li. Come sempre, è la mancanza di umiltà che
fa degenerare nelle discussioni e poi giù a lamentarsi di attacchi
personali quando invece è evidente a tutti che di Spiderman ce n'è
uno, tutti gli altri fan rumore sugli specchi...