Dovresti scrivere una buona documentazione e pulire il codice per aumentare il "Bus Factor"?

Dovresti sforzarti di diventare insostituibile non scrivendo codice che nessun altro capisce, ma raccogliendo più esperienza e conoscenza di altri. Il primo modo ti rende uno sviluppatore che tutti cercano di evitare di lavorare, poiché temono e detestano il mantenimento del codice che hai scritto. In questo modo diventi un membro del team ricercato, che i manager vogliono avere nella propria squadra.

Nella mia esperienza, scrivere codice pulito, ben documentato (e preferibilmente auto-documentante) ha sempre dato i suoi frutti. In effetti, ho preso quasi ogni opportunità di aiutare e insegnare agli altri (oltre a imparare da loro quando sapevano qualcosa di meglio), e non mi sentivo quasi mai in pericolo di essere rimpiazzato da qualcuno meno capace di me. In realtà, questo di solito ha aiutato l'intero team a lavorare meglio e a risolvere i problemi più velocemente, che è il sogno di ogni manager - e un manager ragionevole non vuole sostituire i membri di una buona squadra.

Se hai intenzione di manipolare le organizzazioni o le persone in modo così trasparente, è meglio che siano stupide o in una marmellata che non le lascia altra scelta. Un negozio di sviluppo software ben gestito guarderebbe il tuo codice oscuro e la documentazione mancante e ti licenzierà semplicemente prima che tu possa fare molti danni. Se sono mal gestiti, o non riescono a far funzionare altri sviluppatori, perché vorresti avere un sinecure con loro?

PS Né Greene né Machiavelli in realtà hanno fatto molto altro oltre a scrivere libri che cercavano di adulare gli aspiranti "uomini duri" dell'epoca. Prendi il loro consiglio con un pizzico di sale.

Se sei insostituibile, non puoi essere promosso.

Non vuoi essere insostituibile. Non vuoi far sentire le persone a seconda di te, vuoi che ti apprezzino. In generale, vuoi stare lontano dalle persone, che credono che anche la metà delle leggi del potere debba essere applicata alle relazioni (professionali o personali).
Queste regole sono un insieme di istruzioni su come stabilire con successo una situazione win-lose. Quello che vuoi è una situazione win-win .
Non appena la gente inizia a provare, stai cercando di spingerli sul lato perdente di una situazione di vittoria-sconfitta, loro reagiranno. I tentativi di stabilire situazioni di vittoria-sconfitta spesso finiscono in un risultato di perdere perdere, perché stai sprecando risorse in modo efficace per far perdere il tuo partner, invece di investirli nel successo complessivo della tua partnership.

Se lo fai con i tuoi datori di lavoro, cercheranno di forzare le misure su di te, per ridurre il tuo monopolio della conoscenza. Per lo più, queste saranno linee guida ridicole su come devi fare il tuo lavoro e trasformerai la tua vita lavorativa in un inferno vivente. Inoltre, ti chiameranno alle 3 di notte quando qualcosa si rompe, perché tu sei l'unica persona che può aggiustarlo. È probabile che il tentativo di sfruttare tali situazioni come leva finanziaria si ritorti contro e ti causi più problemi.

The graveyards are full of indispensable men.
- Gaulle, Charles De

Quindi taglia la merda e fai il tuo lavoro correttamente. Se non altro, allora per te, perché è probabile che tu sia l'anima povera, che deve apportare alcune modifiche al codice tra due anni.

Being replacable, isn't that against the interest of a developer?

Detesto infrangerlo, ma tutti è sostituibile. Certo, a volte potrebbe essere una leggera sfida sostituirti (se sei esperto e abbastanza brillante), ma sono anni luce da impossibile.

Il modo per essere veramente un bene prezioso per il tuo datore di lavoro (non solo il datore di lavoro corrente, ma un qualsiasi datore di lavoro ) è dimostrare la capacità di scrivere codice facile da ingannare da chiunque legga il codice (poco aumentare il tempo di lavoro con esso) e documentare il codice (chiunque può ottenere una panoramica di alto livello dei tuoi sistemi senza scavare nel codice).

In realtà essere bravi nella documentazione del codice è una qualità difficile da ottenere in questi giorni, in modo che da soli possa aiutarti a distinguerti dagli altri.

Il codice pulito e ben documentato è anche degno di essere messo su un curriculum (almeno, risultati tangibili di esso, cioè "siamo stati in grado di portare n di nuovi sviluppatori su con ramp up minimo e assistenza dovuta alla mia documentazione) , dove essere furbi di rendersi "insostituibili" non lo è.

Le risposte negative non sono troppo sorprendenti, dato il numero di programmatori migliori della media che questo sito attrae. Le persone di talento generalmente non hanno bisogno di ricorrere a questo tipo di tattiche di sicurezza attraverso l'offuscamento. Ma ho lavorato in un fornitore automobilistico di Fortune 500 con alcuni sviluppatori non così talentuosi che si sono ritagliati piccoli feudi per loro stessi, che hanno custodito con zelo creando una copiosa quantità di documentazione per le orrende interfacce che avevano progettato.

L'intero lavoro di un ragazzo era mantenere il codice per un modulo che collegava due sottosistemi completamente separati, consentendo ai moduli su ciascun sistema di comunicare tramite un UART. Fondamentalmente, era la programmazione seriale 101. Invece di creare un'interfaccia generale simile a questa:

  int sendData(int targetModule, void *data, size_t byteCount);
  int recvData(int sourceModule, void *data, size_t maxBytes);

ha creato opcode separati per ogni singolo messaggio che due moduli comunicanti potrebbero desiderare di inviare a vicenda. Il che significava che il suo modulo doveva conoscere ogni messaggio e doveva essere aggiornato ogni volta che veniva aggiunto o modificato un messaggio. Parla di intimità inappropriata!

Il fatto è che questo tizio ha tenuto un documento Word elencato in modo ordinato tutti gli opcode / messaggi e aggiornato diligentemente come necessario. È diventato il suo intero lavoro . Qualche volta alla settimana, mandava una nuova revisione a tutte le persone sfortunate abbastanza da averlo sul loro percorso critico. E questo era visto come "professionale", dal momento che la gestione amava vedere la documentazione. Mi fa piangere per l'industria automobilistica.

Credo che il mio punto sia: a volte scrivere documentazione può, in effetti, proteggere i programmatori mediocri. I manager spesso non sono in grado di distinguere tra un buon design e uno cattivo e molti sono costretti a prendere decisioni tecniche con informazioni limitate. È incredibilmente stressante per loro. Vedere un documento Word con dozzine di tabelle ben formattate può essere molto confortante, anche se ciò che descrive è un'idea fondamentalmente cattiva.

Being replacable, isn't that against the interest of a developer?

Dipende dagli interessi di quello sviluppatore. Se sei uno che vuole mantenerlo in un unico lavoro per tutta la tua carriera, sii assolutamente indispensabile per una società che premia l'incompetenza e guadagna bene allora sì, assolutamente.

Ma cosa succede quando l'azienda si blocca, probabilmente perché hanno assunto troppe persone come quella? Dove andrai dopo? Che cosa quando ti chiedono perché sei rimasto nello stesso lavoro per 15 anni? E così via.

Ora guarda in un altro modo: quanti sviluppatori hanno perso il lavoro essendo qualcuno che scrive codice che chiunque può leggere?

L'unica probabilità che ciò accada è se l'azienda è in difficoltà e rende ridondante la gente. Se ciò sta accadendo, farai meglio a uscire, e sarai molto ben preparato per le prossime interviste. Inoltre la tua coscienza sarà completamente libera - non ti lascerai dietro un codice inesplicabile che hai scritto per il tuo guadagno personale.

Non so che tipo di persona sei, ma che serve meglio i miei interessi.

Personalmente, penso che uno dei miei più grandi punti di forza sia nell'automazione del mio lavoro. Cosa pensi che una società tende a pensare quando sono diventato surplus per le mie esigenze? Pensano "ok, ci libereremo di lui ora" o pensano "perché non lo spostiamo in un altro ruolo e gli permettiamo di farlo di nuovo"?

Being replacable, isn't that against the interest of a developer?

Hai ragione, ma penso che tu abbia frainteso il significato di sostituibile. Potrei trovare 1000 sviluppatori che scrivono codice frenetico, senza documenti che può trasformarsi rapidamente in un disordine irraggiungibile.

Gli sviluppatori che producono non solo programmi stabili, ma anche codice pulito, documentazione informativa e garantiscono la continuità del progetto, che non è solo insostituibile, è inestimabile .

Tratterò questa domanda da una prospettiva diversa, poiché ci sono già diverse risposte eccellenti.

Pensa a cosa succede quando giochi a giochi meschini cercando di renderti "insostituibile", anche se impedisci ad altre persone di imparare come funziona il tuo codice. Rimani nello stesso lavoro mantenendo i tuoi stessi pasticci per tutto il tempo che la compagnia ti tollera. E questo è il migliore dei casi, lo scenario peggiore è che altri ingegneri e manager più talentuosi e più etici nella tua azienda vedono l'ostacolo che le tue pratiche peggiori impongono all'azienda e decidono di fare qualcosa al riguardo: licenziandoti e riscrivendoti tutto da zero. È stato fatto. In effetti, è una cosa abbastanza comune accadere.

Considera ora cosa succede quando scrivi un buon codice e una buona documentazione. Crei un componente o un sistema che funziona bene, che dopo un po 'di tempo in esercizio, i bug funzionano senza problemi e difficilmente devono essere guardati. Ci vuole un piccolo sforzo per mantenerlo. È quindi possibile passare a progetti più grandi e migliori, con una solida vittoria sotto la cintura. Le persone ti riconosceranno per aver fatto un buon lavoro e inizieranno a rispettare la tua opinione. Avrai la possibilità di avanzare nella catena del cibo e prendere decisioni più significative, o fare lavori più importanti e di maggior impatto, o gestire progetti a un livello più alto. La tua carriera migliorerà, sarai promosso, guadagnerai di più, otterrai riconoscimento e approvazione da parte dei tuoi colleghi, aggiungerai sempre più successi a progetti sempre più importanti.

Quale percorso preferiresti?

Se sei l'unico punto di errore, il tuo cliente (o datore di lavoro) tenterà probabilmente di sostituirti; c'è sempre un punto in cui è meno costoso sostituire il software che mantenerlo, non importa quanto sia essenziale. C'è una ragione per cui l'IT è una delle professioni più esternalizzabili.

D'altra parte, essere sostituibili offre diversi vantaggi inestimabili:

• essere in grado di prendere le vacanze
• non è in corso
• libertà di partire e lavorare su un progetto nuovo ed entusiasmante

La documentazione eccellente alla fine sarà obsoleta con refactoring / evoluzioni e tenerla aggiornata richiede molto tempo.

Pulisci codice + unit test > eccellente documentazione

Se non dedichi 5 minuti alla stesura di una documentazione rapida, passerai un'ora a rileggerla e spiegarla alle persone quando devono utilizzare il tuo codice.

Ancora peggio potrebbe passare giorni a cercare un nuovo lavoro perché il tuo capo ha scoperto che non stavi scrivendo codice gestibile.

La risposta alla tua domanda è "sì". Sì, dovresti scrivere una buona documentazione e un codice pulito. Fare deliberatamente diversamente mostra una mancanza di integrità, che, sebbene sempre più diffusa nel mondo degli affari, non è in qualche modo improvvisamente una cosa "buona".

Nessuno è insostituibile. Le persone che fabbricano una situazione in cui pensano di essere in grado di scoprire nel modo più duro in cui non lo sono. Produrre una co-dipendenza per se stessi è controproducente in quanto limita anche te, non solo il tuo datore di lavoro.

One of the main goals of software development companies is to increase their Bus factor

False premessa. Gli obiettivi principali di una società di sviluppo software (ognuno dei quali ho lavorato in ogni caso) sono produrre il miglior software possibile e fare soldi, non necessariamente in questo ordine. Ridurre il "fattore bus" è solo un modo per evitare di perdere denaro.

Law 11 Learn to keep people dependent on you.

Che cosa significa per te?

Vuoi che le persone dipendano da te perché le hai minate in modo tale da poter andare avanti con il tuo aiuto? O vuoi che le persone dipendano da te perché sei intelligente e perspicace, affidabile, affidabile e in grado di aiutare anche gli altri a fare meglio il loro lavoro? Vuoi far sembrare cattivi i colleghi senza il tuo aiuto, o vuoi che ti apprezzino per averli fatti belli?

È la tua chiamata.

(assumendo il codice di produzione)

Tendo ad andare un po 'oltre. Ho scritto di fare programmi "a prova di idiota", ma non sempre lo qualifico: scrivo un sacco di codice che altre persone non vedranno o non lavoreranno con (almeno, questa è l'aspettativa quando è scritta). Io sono l'idiota che sto cercando di difendermi da quel caso. È una buona cosa quando il tuo programma rileva problemi per te, e il problema è stato semplificato così tanto che è abbastanza ovvio che c'è un errore, e la sua origine. La verità è che i dettagli di implementazione sono evidenti quando si scrive un programma (a meno che non lo si implementa prematuramente), ma dovrebbero essere astratti e resistenti agli errori per i client (anche quando esiste la località modulo). Il motivo è che i programmi diventano molto complessi. A volte puoi separare i problemi, ma non sempre. Se si mantengono i componenti molto rigidi, semplici, ben incapsulati e a prova di idiota, tendono a scalare bene e la maggior parte dei difetti viene rilevata prima della spedizione. È più facile da riutilizzare e hai più sicurezza e un tempo più facile per riutilizzare i programmi. Inoltre, quei programmi complessi che scrivi diventano più complessi (anche per te) dopo qualche tempo lontano dal programma. Quando lo leggi in 6 mesi, può richiedere un'assurda quantità di tempo per comprendere e eseguire il debug rispetto alla versione a prova di idiota. Se un componente introduce un cambiamento di rottura, può passare inosservato per un lungo periodo altrimenti. I programmi sono complessi; non puoi sfuggire a questa realtà, ma puoi renderla una prova idiota, che ti renderà la vita molto più facile quando qualcosa va storto o quando deve essere riutilizzato o modificato. Pertanto, l'approccio a prova di idiota significa che il tuo software può essere compreso, riutilizzato o gestito dagli junior o dalle persone più recenti nel team (non solo da qualcuno che ha esperienza / esperienza come te). La sostituzione è una questione separata: se le persone amano lavorare con i tuoi programmi, stai facendo un buon lavoro - non preoccuparti della sostituzione. Certo, potrei inventare scenari in cui programmi incomprensibili potrebbero salvare il tuo lavoro, ma scrivere un buon programma che gli altri possono usare e mantenere è chiaramente il male minore (guarda le risposte degli altri). Se mi sorprendo a scrivere qualcosa che non è una prova idiota, cerco di risolverlo.

Apart from the scenario, where you need some documentation for yourself in order to continue a project after 6 months of pause, there seems to be a clear conflict of interest here between the developer and the software company.

Non hai davvero idea di cosa stavi pensando in un momento in cui rivedi le implementazioni dormienti. Quando sei veramente esperto, allora il problema è più semplice perché puoi fare affidamento su metodologie o approcci consolidati che usi. Ciò, tuttavia, presuppone anche che queste metodologie siano invarianti. Anche se la documentazione può risultare lassista, devi ancora essere difensivo nelle implementazioni (ad es. Sai meglio di passare NULL in questo scenario - prova questa condizione).

So as a programmer, should you really write excellent documentation and easily readable code for everyone; or should you write code and documentation in a way that it does the job and you yourself can understand it, but another person may have trouble understanding it?

Raccomando l'approccio a prova di idiota, che è ancora più chiaro e più resistente agli errori rispetto all'approccio basato sul fattore bus. Scrivi i tuoi programmi e la documentazione in modo che sia facilmente comprensibile da qualcuno esterno al progetto - è un bene anche per te. Così facendo aumenterai il tuo valore per la tua azienda e il tuo team, non vogliono vogliono per sostituirti.

Hai sostanzialmente frainteso il gioco. Il gioco non è quello di continuare a fare le stesse vecchie cose che hai fatto prima, essendo responsabile di tutto il codice che hai scritto perché nessun altro lo capisce. Il gioco consiste nel completare un progetto e passare a quello successivo, lasciandosi dietro un codice che qualcun altro può facilmente comprendere e lavorare in tua assenza, in modo da poter fare nuove cose e assumere responsabilità sempre più diverse. La tua premessa funziona solo se sei felice di rimanere bloccato a fare la stessa cosa più e più volte senza alcuna possibilità di imparare o migliorare.

Voglio anche sottolineare che se non hai occasione di guardare quel codice molto spesso, anche tu avrai dei problemi a capirlo in sei mesi se lo offuschi deliberatamente.

Documento quel piccolo codice che scrivo, non in modo che altri possano leggerlo, ma in modo che I possa leggerlo tra 3 mesi! Si tratta di semplificare la manutenzione. Se sei responsabile per il codice che hai scritto e non riesci a correggere i bug che si presentano più tardi lungo la linea, allora vorresti che fosse ben documentato ... È abbastanza irrilevante quanto sei sostituibile se non sei capace per fare il tuo lavoro!

Ogni professionista informatico "insostituibile" con cui ho avuto la sfortuna di interagire è stato sostituito, in gran parte perché stavano cercando di tenere in ostaggio le risorse dei loro datori di lavoro. Quando ho avuto persone che mi riferiscono di dirmi che il loro tempo è prezioso per "sprecare" la documentazione, le sostituisco il prima possibile.

Sembrerebbe che se un potenziale impiegato ritiene che le 48 leggi di potere siano eticamente o moralmente accettabili, allora starebbe meglio senza di loro.

Se VERAMENTE vuoi essere insostituibile (cosa che potresti voler riconsiderare dopo aver letto tutte le risposte ...) - perché fermarsi con non documentare il codice?

C'è una guida davvero geniale su come scrivere codice non mantenibile che dovresti assolutamente leggere: link

Buon divertimento! (Sicuramente l'ho fatto ...)