allegato emozionale al codice [chiuso]

Dopo 30 anni come appaltatore, è misto.

1. È tutto usa e getta. Ho lavorato con centinaia di clienti. Non vedrò mai più il codice. Perché diventare attaccato? Non ha senso di proprietà.

2. È molto visibile. È più costoso del codice in-house, quindi ottiene un sacco di controllo. Dal momento che non sarò in giro per mantenerlo, ottiene una grande quantità di controllo. Le procedure dettagliate e le handover del codice sono molto importanti. C'è un certo orgoglio per l'artigianato. Ma nessun senso di proprietà.

Il mio record è di 17 anni di produzione. 12 di quegli anni con manutenzione zero di qualsiasi tipo.

Lo so perché ho ricevuto una chiamata. Stavano rivedendo i loro sistemi contabili e volevano sapere come sostituire l'intelligente algoritmo di allocazione dei costi che avevo costruito tanti anni fa. Ho guardato il codice e i file sono rimasti invariati dall'ultimo aggiornamento 12 anni fa. (Non un bug-fix, AFAIK.)

La prossima corsa più lunga - che io sappia - è stata di 7 anni di funzionamento impeccabile. Ciò, tuttavia, ha avuto un serio problema Y2K e ha richiesto alcune rilavorazioni per utilizzare nomi di file con anni a 4 cifre. Gli algoritmi interni erano tutti corretti, ma i file di registro sarebbero apparsi nell'ordine sbagliato.

Ancora una volta, so che era impeccabile perché i file non erano stati toccati dall'ultima versione che avevo realizzato.

Quindi, sì, c'è un grande orgoglio per l'artigianato.

Ma nessuna "proprietà". È il loro codice, non il mio. L'ho solo costruito.

Essendo uno sviluppatore più o meno solista, la paura di dover mantenere ciò che scrivo è il principale fattore che mi sta dietro cercando di non scrivere codice orribile.

Al lavoro, parte del codice è mia, in un senso simile a come la sedia in cui sono seduto è mia. L'ho scritto, l'ho reso il più bello possibile, mi sento possessivo, le persone mi chiedono dei cambiamenti e la gente si riferirà ad essa come mia. E, come la mia sedia, quando esco dall'azienda non la vedrò mai più e non avrò più alcun attaccamento emotivo.

La parola "mio" ha molte varianti sul suo significato. "Mia moglie" e "il mio spazzolino" non sono strettamente paralleli.

Se scrivi il codice per te stesso, puoi permetterti di provare sentimenti nei suoi confronti. Se scrivi un codice per un'azienda, devi eliminare brutalmente quei sentimenti ogni volta che è possibile. Non riesco a contare il numero di volte in cui ho visto che i bravi programmatori si causano il dolore commuovendo il codice emotivo.

Dì a te stesso: "L'ho fatto, è buono, ma non è mio e posso fare di più." Se ci credi , allora quando 6 mesi della tua vita diventano obsoleti perché un rappresentante di vendita per un prodotto inferiore ha dato al tuo capo un BJ a pranzo, non perdi il lavoro per impazzire per lui.

Ricorda che ti stanno pagando. Vorremmo tutti fare cose interessanti, ma se ci stanno pagando per scavare buche, poi riempirle di nuovo, questo è il loro privilegio. Ho appena avuto una situazione in cui ho scritto un'app Web, poi ho trascorso mesi a incorporare funzionalità terribili, poi mesi più a ricollegarlo allo stato originale. Le ultime due settimane di "lavoro" ho estratto dal mio repository SVN, quindi l'ho ripreso con i nuovi numeri di versione. E sto bene con quello.

No, ma odio davvero dover correggere i bug introdotti da altri nel codice che ho scritto in origine. Sarei più felice se il cambiamento mi fosse stato assegnato in primo luogo. Lo odio ancora di più quando la correzione è completamente al di fuori del design originale, ad es. creando una dipendenza circolare con un modulo di livello superiore.

Sì e No.

Sì: è qualcosa che hai creato e quindi hai un allegato, proprio come un designer di automobili è orgoglioso o imbarazzato quando vede le auto che ha progettato per strada.

No - Per quanto riguarda la proprietà, in genere lo dai in cambio di essere pagato per lavorare in un'azienda. I dipendenti di fabbrica che costruiscono automobili non ottengono la proprietà di ognuno che esce dalla linea perché sono pagati per il loro tempo.

Mi sento molto proprietario del codice che scrivo; rappresenta le decisioni che ho preso su come risolvere un determinato problema e quindi è un riflesso della mia capacità di pensare razionalmente a un problema e ideare una soluzione logica e, si spera, elegante. Detto questo, tutto ciò che scrivo in azienda è di proprietà dell'azienda. Spero che nulla di tutto ciò ritorni a mordermi, e preferirei che mi venisse chiesto di aggiustare il mio codice, ma in caso contrario, allora no. (E potrei aggiungere che il tizio che stava scrivendo il codice tre mesi fa e che ha inserito il mio nome su di esso nel controllo del codice sorgente è un idiota).

Assolutamente no. Una volta che lo controllo, non è più "mio". Sarò il ragazzo ideale per la manutenzione e la risoluzione dei problemi, naturalmente, ma non sento il senso di proprietà nei suoi confronti.

Ho conosciuto alcune persone che sentivano molto proprietarie nei confronti del loro codice, al punto che si irritavano se qualcun altro risolveva un bug o in qualche modo lo modificava senza averlo prima eseguito da loro. Non mi sono mai sentito così. Tutto quello che chiedo è che se trovi un problema nel mio codice e lo risolvi, dimmi qual è il problema e come è stato risolto in modo da non commettere lo stesso errore in futuro.

Adoro i codici che scrivo. Li capisco e li personalizzo così anche gli altri lo faranno. Quando la gente viene da me e dice "Amico, stiamo ancora usando quella sceneggiatura che hai scritto per noi: è così stabile e portatile", adoro quella sensazione di orgoglio e proprietà.

Non c'è nulla di male ad essere attaccati al tuo codice se riesci a vedere dove finirà, cioè se è tutto in-house e sai chi o cosa stai programmando, allora direi che è un buon cosa da attaccare. Coz ti piacerà solo creare più pezzi di brillantezza, molto di più.

D'altro canto (pienamente consapevole del fatto che potrei ribadire ciò che @ S.Lott ha detto) se il codice sta per finire come proprietà di un cliente, non c'è alcun senso nel sentirsi sentimentali su di esso. È come ... prendersi cura del cucciolo del tuo amico quando è in vacanza. : - /

Appaltatori e consulenti che potrebbero non vedere mai più il loro codice probabilmente non sono il candidato ideale per essere attaccati emotivamente al loro codice. Dovendo "abbandonarlo" più e più volte probabilmente paralizzerei la guida creativa dei poveri consulenti dopo un po '.

Se la consideriamo dal punto di vista di un dipendente e non di un imprenditore, direi che vorrei che tutti i membri del mio team sentissero la proprietà nel codice che scrivono e in tutto ciò che crea. Questa proprietà e orgoglio dovrebbero estendersi all'intero team. La sensazione di orgoglio e proprietà crea un attaccamento al prodotto nelle domande e aggiunge significato e senso al lavoro di un membro del team. Ho visto questo aumentare notevolmente le prestazioni nei team di piccole e grandi dimensioni.

Cosa dovrebbe essere evitato e ciò che non mi piace sono le persone che sembrano legate emotivamente alle linee specifiche del codice che hanno scritto e lo difendono fino alla tomba. Non vogliono cambiamenti fatti, guardano in basso e rifiutano qualsiasi idea di cambiamento o miglioramento e cercano di giustificarlo con qualcosa che sembra credibile. Ciò che spesso si riduce alla mia esperienza personale è la paura del cambiamento e la paura dell'ignoto. In realtà non sta abbandonando le loro vecchie linee di codice, questo è il problema. Invece è dover prendere qualcosa di nuovo, a volte non scritto da solo, e la paura di fallire.

Questo tipo di attaccamento "malato" al codice è qualcosa che lavoro sodo per cercare di prevenire. Ma le connessioni emotive "salutari" al prodotto e, per estensione, il codice scritto, sono qualcosa che incoraggio.

Questa è una domanda interessante e concordo con uno dei post sopra riportati: Sì e No, ma per ragioni diverse.

Cresco legato al codice? Decisamente sì. Ma non penso che sia il codice stesso ma l'architettura e l'applicazione complessive. Di solito devi fare molte ricerche specifiche per il dominio prima di poter davvero mettere in codice ciò che gli uomini d'affari vogliono (a meno che tu non stia scrivendo un IDE - quindi sei decisamente bloccato nella ricorsione).

D'altra parte: non ci sono molte cose che mi piacciono di più che buttare via parti obsolete del codice base. Non importa quanto difficile possa essere stata la scrittura. Il viaggio conta molto più del prodotto (almeno per l'ego, ovviamente anche il prodotto deve funzionare).

C'è un senso di proprietà? Beh, dipende dalla situazione del progetto. Quando non vedrai mai più il codice (perché la tua parte nel progetto è finita e stai andando avanti) allora perché essere romantici riguardo a questa roba? Tuttavia, se continui a sostenerlo (in qualsiasi modo), allora una sensazione di attaccamento è una buona cosa! Quando ti preoccupi del prodotto che stai sviluppando, è molto probabile che tu stia cercando di fornire artefatti di alta qualità.

Quindi, tutto sommato, cerco di adottare una "relazione" pragmatica con il codice che scrivo.

Diavolo sì, una volta ho picchiato un collega perché era abbastanza arrogante da rinominare un paio di variabili.

No, non proprio. Vengo pagato per lo sviluppo del software. Anche se lo ammetto, vedere le correzioni apportate al mio codice da altri sviluppatori ha un impatto sull'ego -.