Quali fattori dovrebbero influenzare il modo in cui decido quando abbandonare un piccolo progetto con un amico? [chiuso]

Mi sono trovato in una situazione difficile fino a tardi. Ho lavorato su un gioco con un compagno di programmazione per quasi 8 mesi. Entrambi abbiamo iniziato come programmatori principianti verso agosto dello scorso anno, è uno studente CS del 2 ° anno, sono una tecnologia di supporto IT commerciale e sono un programmatore autodidatta con una moltitudine di libri e abbonamenti online.

Il problema che ho constatato costantemente è che mentre scriviamo un pezzo di codice, spesso sarà un po 'compromesso insieme, avrà molti fallimenti e se è un concetto nuovo di zecca per uno di noi, pieno di soluzioni ingenue. Questo va bene, stiamo imparando, mi aspetto che entrambi i nostri codici vengano un po 'hackerati insieme sul primo o secondo passaggio. Il problema si presenta quando si tratta di correggere e refactoring quei comportamenti compromessi insieme.

Il mio partner manterrà il suo comportamento appena acciottolato, rifiutando palesemente di vedere qualsiasi errore nel momento in cui inizia a funzionare. Rivendicando la perfezione da un pezzo di struttura non posso nemmeno provare a usare anche se avesse commenti e metodi e campi appropriatamente denominati. Non importa quanto ci provi, non riesco proprio a fargli vedere i difetti palesemente ovvi che impediranno ulteriori cambiamenti o espansioni del comportamento senza romperlo completamente e tutto ciò a cui è così strettamente accoppiato potrebbe anche essere nella stessa classe. Le soluzioni hackerate rimangono perennemente hackerate, i progetti mal concepiti restano come quando concepiti e testati per la prima volta.

Passo tanto tempo a fare da babysitter a un nuovo codice quanto a scriverlo da solo, sono una perdita di cosa fare. Il mio partner lo ha perso stanotte e ha chiarito che, qualunque cosa accada, qualunque sia il punto di riferimento, qualunque sia la pratica comune, qualunque sia la prova inconfutabile, il suo codice rimarrà come prima. Anche se interi libri sono stati scritti sul perché vuoi evitare di fare qualcosa, rifiuterà di riconoscere la loro validità affermando che è solo l'opinione di qualcuno.

Ho un interesse acquisito nel nostro progetto, tuttavia non sono sicuro di poter continuare a lavorare con il mio partner. Mi sembrano avere tre opzioni aperte per me.

• Smetti di preoccuparti del funzionamento della base di codice oltre il punto di compilazione e affronta il tentativo di mantenere e analizzare il comportamento che a malapena cammina. Sperando che una volta che le cose inizino a rompersi seriamente, lo vedrà e proverà a fare qualcosa di più che mettere semplicemente un cerotto sul design fondamentalmente difettoso.
• Continuate con gli infiniti argomenti su questioni che sono state decise dieci anni fa da altre persone molto più capaci.
• Smetti di programmare su questo progetto, abbandonando quasi 10.000 righe del mio codice e innumerevoli ore schiacciando il design e provando a trovare un nuovo progetto per conto mio.

Quale approccio posso adottare per determinare se vale la pena continuare con questo progetto con questa persona? O quali fattori dovrebbero influenzare la mia decisione? Abbiamo scritto un sacco di codice e non voglio rinunciare a meno che non sia necessario.

Il codice spedito e imperfetto è meglio del codice perfetto sulla lavagna che non viene mai spedito.

Detto ciò...

Quelli di voi con più esperienza o che si sono trovati in situazioni simili. Che cosa hai fatto? Cosa mi consiglieresti di fare?

Vorrei considerare quanto segue.

• Qual è lo scopo di questo progetto? Divertimento? I soldi? Per imparare?
  • Stai davvero realizzando questo scopo?
• Questa persona ti sta davvero permettendo di raggiungere meglio i tuoi obiettivi?
• Quanto sei vicino alla spedizione?
• Questi problemi ti impediscono di avviarti? O sono una questione di orgoglio personale?
• Ci sono vantaggi nel lavorare con qualcuno su base volontaria quando è frustrante?

Smetti di programmare su questo progetto, abbandonando quasi 10.000 righe del mio codice e innumerevoli ore di lavoro sul design e prova a trovare un nuovo progetto per conto mio

Considera quanto sopra, prova a pensare attraverso il lavoro aggiuntivo richiesto.

Devi capire le tue priorità e determinare se valgono le questioni legate al lavoro con questa persona. Non possiamo capirlo per te.

Il mio partner lo ha perso stanotte e ha chiarito che, qualunque cosa accada, qualunque sia il punto di riferimento, qualunque sia la pratica comune, qualunque sia la prova inconfutabile, il suo codice rimarrà come prima.

Sai che non vuoi lavorare con questo tipo di persona.

Stai facendo un progetto come questo presumibilmente perché vuoi imparare la programmazione e trovare l'eleganza nel mestiere stesso.

Questa potrebbe essere una cosa culturale. In alcune culture, ammettere di aver commesso un errore è inaudito e chiedere a qualcuno di ammettere di aver commesso un errore riguarda la cosa più rude che puoi fare. Se è quella situazione, scappa.

Nella mia esperienza con persone molto intelligenti, se dici loro che qualcosa che stanno facendo è tutt'altro che perfetto, o ti daranno (1) una ragione corretta e facile da capire perché quello che stanno facendo è giusto, (2) voi che sanno che è sbagliato, ma non hanno tempo di ripararlo a causa delle priorità, o (3) grazie per averlo sottolineato e risolto.

Rifiutare di apprendere riguarda l'attributo peggiore che uno sviluppatore di software possa avere. Lascialo. La vita è troppo breve e preziosa per perdere tempo con lui.

Forse il modo più semplice è portare qualcun altro nel progetto - o ti sbagli e la sua base di codice è semplicemente troppo intelligente per te, o hai ragione ed è troppo intelligente per tutti. Lo scoprirai presto e otterrai il backup se si rivelerà essere codice di livello junior programmatore spazzatura, contorto.

D'altra parte, un prodotto funzionante merita un numero qualsiasi di anni di codice finemente sintonizzato, elegante e chiaro. Crea il gioco, spediscilo, poi vai via - lascialo per mantenerlo e non lavorare su v2.

Ecco alcune idee anche se alcune si escludono a vicenda.

• Responsabilità separate della fonte. Se lavori sul Modulo A e lui sul Modulo B puoi competere con i tuoi diversi stili. Rilascia spesso funzionalità di lavoro? Raggiunge un punto in cui deve riscrivere il suo codice da zero? Rifattorizza il codice dai tuoi moduli e non toccarlo,

• Lascia che faccia il mantenimento del suo peggior codice. Se lo fa con successo hai evitato un compito terribile. Se non è in grado, sentirà il dolore.

• Consideralo dal punto di vista dell'utente o aziendale. In alcuni casi è necessario solo un prodotto valido che Google o Microsoft potrebbero acquistare. In altri stai lanciando un prodotto sul mercato e supportare migliaia di clienti con codice difettoso o compromesso sarà un inferno. Non è lo stesso se il tuo codice controlla i droni con missili nucleari o crea video felici per gli adolescenti.

• Fa le lezioni, tu fai le prove. Il refactoring del codice con i test è più semplice e sicuro. In questo modo non dovrai cercare all'interno del codice solo la barra Junit. Ciò presuppone che A) stai programmando dei test, B) il tuo codice di collega sia verificabile. Se trovi difficile costruire i test durante la fase di codifica, quest'ultimo sarà peggio.

• Vai insieme alla formazione o agli eventi. Quando non conosci il modo giusto è abbastanza naturale, usa l'unico modo che conosci. Vedere il codice di altri potrebbe non risolvere tutto ma non ti farà male provare.

• Trova i tuoi punti di forza complementari. Il refactoring a volte può essere divertente. Se scrive cose che almeno funzionano, potresti fare il refactoring. Può fare picchi per esplorare soluzioni che non finiscono nel codice di produzione.

• Potrebbe non voler riscrivere il codice ma potrebbe accettare di scrivere meglio il nuovo codice. Capisco che riscrivere è difficile, noioso e può spezzare le cose. Coltiva alcune isole di qualità. In questo modo avrà buoni esempi di come fare le cose.

• Usa la regola del boy scout . Non lasciare intatte le cose a meno che tu non abbia bisogno di lavorarci sopra. Se un modulo è scritto male ma funziona e non è necessario modificarlo, lasciarlo così. Se devi correggere un bug o completare una funzione, miglioralo un po '. Dopo qualche tempo migliorerà il 20% delle lezioni che cambi l'80% delle volte. Altre isole di qualità.

Non possiamo suggerire quale sia la soluzione migliore senza conoscere entrambi. In bocca al lupo.

Ok, ecco una risposta che probabilmente non ti piacerà.

Non "correggere" il codice a meno che non riesca a implementare la funzione.

Ecco il mio ragionamento. Probabilmente stai cercando di fare soldi. Per fare soldi devi spedire velocemente le funzionalità completate. Nessuno ti pagherà di più per un gioco per computer "ben codificato".

La maggior parte delle aziende ha lo stesso problema. Rifattorizzare il codice esistente per renderlo "migliore", a volte anche obiettivamente migliore in termini di velocità o affidabilità O scrivere nuove funzionalità.

Il 99% delle volte sceglie di scrivere le nuove funzionalità perché il risultato di una semplice analisi costi-benefici.

Mi piacciono tutte le risposte finora. Prendendo uno dei punti dalla risposta di Enderland :

Ci sono vantaggi nel lavorare con qualcuno su base volontaria quando è frustrante?

Vorrei impiegare questo tempo per collegare lo scambio di stack di revisione del codice . È un posto meraviglioso in cui puoi ottenere il tuo codice criticato da professionisti. E onestamente, molte delle recensioni sul codice sono estremamente utili per le persone coinvolte: chi chiede, chi risponde e chi inciampa e le legge. Raramente ricevi recensioni così utili in un ambiente professionale (che potrebbe essere il caso nei posti in cui ho lavorato per qualsiasi motivo).

Il mio consiglio è di pubblicare alcuni dei tuoi codici per la revisione. Non consiglierei di usarlo come munizioni per dimostrare che questo tizio si sbaglia - dubito che lo prenderà a cuore - ma puoi ottenere informazioni molto utili sia sul codice che hai scritto che sul codice che ha scritto. Consiglierei di inviare i pezzi di codice su cui voi due combattete di più. Con ogni probabilità, entrambi in qualche modo sbagli e puoi usare la recensione come un modo per far intervenire una terza parte obiettiva. Ciò realizzerà alcune cose:

• Puoi disconnetterti dalla tensione emotiva della situazione.

• Ricevi una consulenza professionale in tempo reale. Un grande impulso a ciò che stai imparando.

• Qualcuno ti dirà che ti sbagli. Il che è positivo, perché chiunque lo fa per un certo periodo di tempo lo sentirà. Puoi gestirlo male come questo ragazzo con cui stai lavorando, oppure puoi imparare ad affrontarlo.

Penso che se usi le recensioni del codice nel modo giusto, hai molto da guadagnare affrontando questa persona estremamente frustrante. Ed è molto più interattivo di un libro o sito Web che dice "fai questo, perché è il modo giusto per la maggior parte del tempo".

Allo stesso modo, c'è lo scambio di stack degli sviluppatori di giochi . Non tanto un posto dove pubblicare il codice per la revisione, ma per chiedere concetti / idee con cui stai lottando. Ancora una volta, quel posto è estremamente utile per tutti i soggetti coinvolti.

Potresti aver visto entrambi questi siti prima; Volevo solo assicurarmi che facciano parte del tuo set di strumenti.

Sembra abbastanza senza speranza. Probabilmente mi arrenderei e andrei avanti se mi sentissi come te; arriva sicuramente il momento di andarsene e potresti essere lì.

Se non sei ancora pronto per andartene, devi trovare un modo per raggiungere un migliore accordo sul tuo processo. Sembra che tu abbia standard di codifica, ma non standard concordati. La prossima volta che vieni ad un incrocio, la prossima volta che vuoi scimmiottare con un po 'di codice e il tuo amico vuole lasciarlo da solo, spara per una conversazione seguendo le seguenti linee:

douglas: Voglio cambiarlo perché X, che è proprio qui nelle nostre linee guida.

amico: va bene come è.

Douglas: Quindi stai dicendo che dovremmo cambiare le linee guida?

amico: No, penso solo che vada bene così.

douglas: A cosa servono le linee guida?

amico: non lo so - li hai scritti.

Douglas: Quali linee guida vorresti scrivere?

amico: non scriverei linee guida. È una perdita di tempo.

douglas: Quindi dovremmo semplicemente buttare via le linee guida e scrivere qualunque schifezza stiamo pensando in quel momento?

amico: questa non è una schifezza.

Douglas: è perfetto? È l'ideale?

amico: fa il lavoro; passiamo alla prossima funzione.

Douglas: C'è qualcosa su cui possiamo concordare, che X è un buon codice e Y è un codice cattivo?

amico: lasciami in pace; Voglio solo programmare!

Bene, non è andata bene, vero? Immagino che la sensazione che ho sia che tu e Buddy desideriate cose diverse. Se c'è qualcosa su cui puoi essere d'accordo, fantastico; inizia da lì e costruisci su di esso. Ma non puoi fargli accettare di volere quello che vuoi - non più di quanto potresti farti desiderare quello che sembra voler. Se riesci a trovare quel desiderio comune, e giungere ad un accordo comune da lì, forse puoi lavorare insieme.

Douglas: cosa vuoi?

amico: voglio solo programmare.

douglas: Anche io voglio scrivere codice, ma voglio essere orgoglioso del mio codice.

amico: sono orgoglioso del mio codice.

douglas: Ecco una funzione di cui sono orgoglioso: cosa ne pensi?

amico: va bene, ma non dovresti ricalcolare X all'interno del loop; è inefficiente.

douglas: Quindi stai dicendo che dovremmo sempre calcolare valori costanti al di fuori dei loop?

amico: Beh, duh!

Douglas: Pensi che dovrebbe essere nelle nostre linee guida?

amico: certo.

douglas: OK, lo aggiungerò alle nostre linee guida e aggiornerò il mio codice ...

Douglas: Com'è adesso?

amico: bene.

Ora Buddy sta contribuendo alle linee guida (anche se indirettamente), e quindi ha un po 'di senso della proprietà. Forse - solo forse - inizierà a prenderli più sul serio. Penso che sarei propenso a cancellare la lavagna e ricominciare con le linee guida, lasciando che la maggior parte o tutti provengano da Buddy all'inizio. Vai avanti e scrivi codice di merda così sente la necessità di aggiungere alle linee guida; lasciali venire da lui. Forse allora inizierà a capirne il motivo.

Ma se preferisci rinunciare e andare avanti, potrebbe non essere una cattiva opzione.

Supponendo che tu decida di abbandonare il progetto:

• Fork il codice e refactoring, usandolo come un elemento di portafoglio "prima / dopo"
• Poiché l'obiettivo era (principalmente o parzialmente) imparare la programmazione e poiché apprendere qualcosa richiede 2-4 volte che fare qualcosa che già conosci, quel lavoro non è davvero sprecato.
• "Affondamento dei costi sommersi" (l'investimento che hai già fatto in un'impresa prima di apprenderla è stata una cattiva idea) è uno degli errori umani più comuni nel processo decisionale
• Per mantenere l'amicizia, inquadra la tua decisione in base alla priorità dell'amicizia rispetto alla programmazione

tl; dr dovresti probabilmente abbandonare il progetto.

Senza saperne di più su ciò che ci hai detto, speculerei che l'attrito che stai vivendo è legato all'esperienza.

Anche se non sei un programmatore di professione come professionista IT, probabilmente hai imparato la prima volta nel modo giusto di fare le cose nel modo giusto, il tuo riferimento al tuo sé futuro indica che l'hai fregato in passato e imparato non farlo.

Il tuo studente CS del 2 ° anno, anche se abbastanza dotato, probabilmente non ha la prospettiva di averlo fatto (se sei come me, ripetutamente :).

Lui / lei non crederà mai veramente nel valore di sistemare le cose man mano che vai avanti fino a quando non avrà bruciato le cicatrici per non averlo fatto o non sarà guidato in una cultura con un'eccezionale disciplina ingegneristica, o entrambi.

Questa persona può essere il tuo peer di programmazione, ma non è il tuo peer di progetto, quindi fare questo gioco come progetto peer è probabilmente una causa persa. A meno che tu non sia disposto a mangiare solo il costo futuro. Forse la relazione è abbastanza preziosa per te. In tal caso, dategli abbastanza corda per impiccarsi e intervenite per aiutare a ripulire il disordine quando quella persona è costretta a riconoscere il problema.

In caso contrario, esegui il cauzione e fai un progetto con un peer, oppure fai un progetto mentore / mentee in cui questa è la dinamica fin dall'inizio.

Per aggiungere ulteriori punti a tutte le ottime risposte:

• Quanto più sforzo ci vorrà per completare il progetto? Si noti che il completamento dell '"ultimo 10%" richiede molto più tempo di quanto le persone si aspettino. Ciò include test / messa a punto del gioco, correzione dell'usabilità, gestione di una varietà di piattaforme target, rilascio, ... Se si tratta di un gioco iOS, allora c'è la firma del codice e la revisione di Apple. Onestamente, la finitura può richiedere fino al primo "90%". E sarà ancora più difficile se il codice è cattivo come suggerisci. (Puoi iniziare a giocare provandolo ora?)
• Realisticamente, con quale probabilità le persone apprezzeranno il tuo gioco?
• Attenzione al " costo euristico sommerso ". Valuta quell'investimento di 10.000 righe di codice alla luce del quadro generale, guardando indietro a un prodotto finito e senza eccessivo ottimismo.
• Puoi continuare se ci vogliono altri 3 anni? Voi due avete stili di sviluppo diversi (non una buona partita di squadra). Sembra che tu sia quasi alla fine della tua pazienza e se continui ad andare avanti, potrebbe essere difficile rimanere amici.

Dovresti continuare a fare il tuo codice nel modo in cui pensi sia giusto, con commenti e simili e fare una copia della tua versione del codice (nel caso in cui cambi il tuo codice).

Non combattere, non arrabbiarti, sorridi quando vedi le sue decisioni sbagliate.

Reclami solo come utente, se funziona, non lamentarti.

Non arrenderti neanche, è importante abituarsi a persone diverse da te, che accadranno in un vero lavoro.