Come dipendente di un'azienda, quando scrivi il codice ti senti come se avessi un allegato ad esso? Ritieni di possedere una certa proprietà del codice? O lo scrivi completamente distaccato da esso senza alcuna preoccupazione per ciò che accade dopo che ti sei trasferito su qualcos'altro?
EDIT: non sto parlando di scrivere codice errato e quindi di eseguire ...
Risposte:
Dopo 30 anni come appaltatore, è misto.
È tutto usa e getta. Ho lavorato con centinaia di clienti. Non vedrò mai più il codice. Perché attaccarsi? Non c'è senso di proprietà.
È molto visibile È più costoso del codice interno, quindi viene sottoposto a numerosi controlli. Dal momento che non sarò in giro per mantenerlo, si ottiene un sacco di controllo. Le procedure dettagliate e i passaggi di codice sono molto importanti. C'è un certo orgoglio nell'artigianato. Ma nessun senso di proprietà.
Il mio record è di 17 anni di produzione. 12 di quegli anni senza manutenzione di alcun tipo.
Lo so perché ho ricevuto una chiamata. Stavano rivedendo i loro sistemi contabili e volevano sapere come sostituire l'algoritmo intelligente di allocazione dei costi che avevo costruito tanti anni fa. Ho esaminato il codice e i file sono rimasti invariati rispetto all'ultimo miglioramento 12 anni fa. (Non una correzione di bug, AFAIK.)
La prossima corsa più lunga - di cui sono a conoscenza - sono stati 7 anni di funzionamento impeccabile. Ciò, tuttavia, aveva un grave problema con Y2K e richiedeva 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 è stato impeccabile perché i file non erano stati toccati dall'ultima versione che avevo realizzato.
Quindi sì, c'è molto orgoglio nell'artigianato.
Ma nessuna "proprietà". È il loro codice, non il mio. L'ho solo costruito.
Come sviluppatore più o meno solista, la paura di dover mantenere ciò che scrivo è il driver principale dietro di me cercando di non scrivere codice orribile.
Al lavoro, parte del codice è mio, in un senso simile a come la sedia su cui sono seduto è mia. L'ho scritto, l'ho reso il più bello possibile, mi sento possessivo, le persone mi chiederanno dei cambiamenti e le persone si riferiranno ad esso come il mio. E, come la mia sedia, una volta che lascerò la compagnia non la rivedrò mai più e non avrò più alcun attaccamento emotivo.
La parola "mia" ha molte varianti sul suo significato. "Mia moglie" e "mio spazzolino" non sono strettamente paralleli.
Se scrivi il codice per te stesso, puoi permetterti di provare qualcosa nei suoi confronti. Se scrivi codice per un'azienda, devi puramente eliminare quei sentimenti ogni volta che è possibile. Non riesco a contare il numero di volte in cui ho visto che un buon programmatore si procura dolore diventando emotivo per il codice.
Di 'a te stesso: "L'ho fatto, è buono, ma non è mio e ne 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 con lui.
Ricorda che ti stanno pagando. Tutti vorremmo fare cose interessanti, ma se ci stanno pagando per scavare buche, quindi riempirle di nuovo, questo è il loro privilegio. Ho appena avuto una situazione in cui ho scritto un'app Web, quindi ho trascorso mesi incorporando funzionalità terribili, quindi mesi in più per riportarla allo stato originale. Le ultime due settimane di "lavoro" che ho estratto dal mio repository SVN, quindi l'ho ricominciato con i nuovi numeri di versione. E sto bene con quello.
No, ma odio 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 esempio creando una dipendenza circolare con un modulo di livello superiore.
Sì e no.
Sì, è qualcosa che hai creato e quindi hai un attaccamento, proprio come un designer di auto è orgoglioso o imbarazzato quando vede le auto che ha progettato sulla strada.
No - Per quanto riguarda la proprietà, in genere si rinuncia in cambio di essere pagato per lavorare in un'azienda. I dipendenti della fabbrica che costruiscono auto 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 di escogitare una soluzione logica e, si spera, elegante. Detto questo, tutto ciò che scrivo sul tempo dell'azienda appartiene alla società. Spero che niente di tutto ciò ritorni a mordermi, e preferirei che mi venisse chiesto di correggere il mio codice, ma se no, allora no. (E potrei aggiungere che il tizio che stava scrivendo codice tre mesi fa e mettendoci il mio nome nel controllo del codice sorgente è un idiota).
Affatto. Una volta verificato, non è più "mio". Sarò il ragazzo ideale per la manutenzione e la risoluzione dei problemi, naturalmente, ma non ho alcun senso di proprietà nei suoi confronti.
Ho conosciuto alcune persone che si sono sentite molto proprietarie nei confronti del loro codice, al punto che si sarebbero irritate se qualcun altro avesse risolto un bug o in qualche modo lo avesse modificato senza prima eseguirlo. Non mi sono mai sentito così. Tutto ciò che chiedo è che se trovi un problema nel mio codice e lo risolvi, dimmi qual era il problema e come è stato risolto, quindi non commetterò lo stesso errore in futuro.
Adoro i codici che scrivo. Li capisco e li personalizzo in modo che lo facciano anche gli altri. 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 nel legarsi al tuo codice se riesci a vedere dove finirà, ad esempio se è tutto in casa e sai per chi o cosa stai programmando, direi che è una buona cosa ottenere allegato . Perché ti piacerà solo creare più pezzi di brillantezza, molto di più.
D'altra parte (consapevole del fatto che potrei ripetere ciò che @ S.Lott ha detto) se il codice finirà come proprietà di un cliente, allora non c'è alcun senso nel sentirsi sentimentali su di esso. È come ... prendersi cura del cucciolo del tuo amico quando è andato in vacanza. : - /
Gli appaltatori e i consulenti che potrebbero non vedere mai più il loro codice non sono probabilmente il candidato ideale per attaccarsi emotivamente al loro codice. Dover "abbandonarlo" più volte probabilmente paralizzerebbe la spinta creativa dei poveri consulenti dopo un po '.
Se lo consideriamo dal punto di vista di un dipendente e non di un appaltatore, direi che vorrei che tutti i membri del mio team fossero titolari del codice che scrivono e di tutto ciò che creano. Questa proprietà e questo orgoglio dovrebbero estendersi a tutto il team. Il sentimento 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 in team di piccole e grandi dimensioni.
Ciò che dovrebbe essere evitato e ciò che non mi piace sono le persone che sembrano emotivamente attaccate alle specifiche linee di codice che hanno scritto e lo difendono nella tomba. Non vogliono che vengano fatti cambiamenti, guardano in basso e rifiutano qualsiasi idea di cambiamento o miglioramento e provano a giustificarlo con qualcosa che sembra credibile. Ciò a cui si riduce spesso, per esperienza personale, è la paura del cambiamento e la paura dell'ignoto. In realtà non è rinunciare alle loro vecchie righe di codice che è il problema. Invece deve assumere qualcosa di nuovo, a volte non scritto da te stesso, e la paura di fallire.
Questo tipo di attaccamento "malato" al codice è qualcosa su cui lavoro sodo per cercare di prevenire. Ma le connessioni emotive "sane" al prodotto, e per estensione il codice scritto, sono qualcosa che incoraggio.
Questa è una domanda interessante e sono d'accordo con una delle pubblicazioni di cui sopra: Sì e No, ma per diversi motivi.
Mi affeziono al codice? Decisamente sì. Ma non credo sia il codice stesso, ma l'architettura e l'applicazione complessive. Di solito devi fare molte ricerche specifiche sul dominio prima di poter davvero mettere in codice ciò che gli uomini d'affari vogliono (a meno che tu non stia scrivendo un IDE - allora sei sicuramente bloccato in ricorsione).
D'altra parte: non ci sono molte cose che mi piacciono di più che buttare via parti obsolete della base di codice. Non importa quanto sia difficile la scrittura. Il viaggio conta molto di più del prodotto (almeno per l'ego, ovviamente anche il prodotto stesso deve funzionare).
C'è un senso di proprietà? Bene 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é diventare romantici sulle cose? Tuttavia, se continui a supportarlo (in qualsiasi modo), una sensazione di attaccamento è una buona cosa! Quando ti preoccupi del prodotto che stai costruendo, allora le probabilità sono piuttosto alte che stai cercando di fornire artefatti di alta qualità.
Quindi nel complesso cerco di adottare una "relazione" pragmatica con il codice che scrivo.
Inferno 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 di software. Anche se lo ammetto, vedere correzioni di bug eseguite sul mio codice da altri sviluppatori ha un impatto sull'ego.