Il codice di non documentazione risulta nella sicurezza del lavoro? [duplicare]

Qualsiasi dirigente responsabile licenzierà un dipendente diventato indispensabile. Il motivo è che più sono lì, più grande è il danno quando se ne vanno.

Per il punto di vista dei dipendenti, questo tipo di "sicurezza del lavoro" non è saggio: la direzione non può promuovere qualcuno che è indispensabile, non può dare loro i nuovi progetti. Sarai bloccato nello stesso giorno del maiale per il resto della tua vita. Potrebbe non sembrare pessimo all'età di 20 anni, ma 20 anni dopo fare la stessa cosa allo stesso modo con un manager abbastanza vecchio da essere tuo figlio .... Quindi decidi di andartene, ma non riesci a trovare un lavoro a causa del tuo riferimento controlla, e soprattutto non saprà mai perché ... Il caso peggiore, probabilmente, non plausibile - certamente no.

Modifica / Chiarimento Ci sono molti modi per licenziare qualcuno in questa situazione - una mossa laterale o addirittura al ribasso può essere appropriata, tuttavia se la persona è un costruttore di imperi di solito costruiscono un altro impero, e spesso non andranno volentieri (una volta che vedono il potere essere portato via ). Se solo "cadono" nell'essere insostituibili, di solito saranno la prima persona a identificare il problema e saranno disposti a partecipare alla soluzione, non è questa la domanda. Se l'intera vitalità delle organizzazioni o anche la sopravvivenza dipende dal non essere in grado di licenziare un individuo, allora costerà meno farlo prima o poi.

Ci sono pochissimi Steve Jobs in questo mondo, e il ragazzo che sta costruendo il suo impero è, a conti fatti, molto improbabile che sia uno di loro. Ho spesso osservato che persone "insostituibili" venivano rimpiazzate, di solito a un costo molto inferiore a quello immaginato da chiunque.

Non l'ho mai provato in prima persona, ma penso che sia una mentalità molto sciocca sin dall'inizio.

Perché diventare indispensabile per essere cattivo nel tuo lavoro quando puoi diventare indispensabile per essere bravo nel tuo lavoro?

Come giovane programmatore, ti dirò che cerco di documentare il mio codice almeno con moderazione, ma questo è il genere di cose in cui l'abitudine svolgerà un ruolo molto più importante dell'intenzione. Quando ho iniziato a programmare per la prima volta, non avevo un solido apprezzamento sul valore del codice di commento. Quando sono entrato in più classi di programmazione e le scadenze si sono accorciate mentre i progetti diventavano più difficili, non ho sempre commentato il mio codice perché non sempre avevo tempo. Non avevo preso l'abitudine di documentare come ho scritto, quindi spesso avrei documentato come un ripensamento.

Credo che molte persone si trovino in un posto come questo: se il codice di commento non è una pratica deliberata dal primo giorno, ci vuole più lavoro per radicarlo, e molte persone probabilmente non si impegnano mai a farlo accadere. Tuttavia, non ho mai volontariamente mantenuto i commenti out del mio codice. Se ho tempo e ricordo che è necessario, credo che dovrebbe essere fatto.

Per quanto a tutti noi piace credere altrimenti, l'accaparramento di informazioni può funzionare. Nel migliore dei casi è una strategia rischiosa, dal momento che chiaramente l'accaparramento di informazioni è intrinsecamente egoistico e probabilmente le persone si arrabbieranno se ti cattureranno.

Per inciso, ti starai chiedendo "come mai qualcuno potrebbe non essere scoperto?" Tuttavia, ho assistito alle persone che accumulano informazioni dallo staff tecnico, ma pretendono che il management stia collaborando. Ma la condivisione di tutte le informazioni è in realtà deliberatamente incomprensibile o falsa.

Questo non imbroglia il personale tecnico a lungo, ma lo rende difficile da dimostrare, e chiunque sia in grado di accumulare informazioni è probabilmente stato più a lungo e quindi ha più fiducia dal management. Soprattutto dal momento che sono in grado di creare una storia di se stessi salvando eroicamente un progetto dopo l'altro da successive ondate di programmatori che non sembrano mai riuscire a far funzionare correttamente il sistema.

L'accaparramento delle informazioni è particolarmente efficace se le informazioni che vengono accumulate includono molti dei requisiti di sistema effettivi, dal momento che i dipendenti tecnici possono alla fine scoprire anche il codice più oscuro dato un tempo sufficiente. Ma fare tutto questo oltre a determinare i requisiti richiede ancora più tempo, e sarà quasi impossibile fare a meno di tornare all'astronave delle informazioni.

Ovviamente, è necessario che una cattiva gestione permetta a questa situazione di svilupparsi e di lasciarla continuare, ma anche in questi giorni ci sono ancora un piccolo numero di aziende con un singolo dipartimento o due che nella loro peggiore i momenti consentono cattiva gestione occasionale.

È interessante notare che la vita di accumulatori di informazioni come avaro è spesso piuttosto difficile. Probabilmente non riescono a migliorare le proprie capacità perché sono impegnati a essere essenziali per qualunque sia la loro informazione accumulata. Presto non potranno cambiare lavoro perché è tutto ciò che sanno davvero come fare. E devono vivere nella paura del nuovo management con un senso abbastanza per vedere cosa sta succedendo e il coraggio di pagare i costi a breve termine per risolvere il problema.

Quindi, non lo consiglierei a chiunque non sia immorale e disperato. Ma in alcune circostanze può fornire più sicurezza sul posto di lavoro, quindi non farlo. Ma meno sicurezza carriera .

Ne dubito. Se stai scrivendo codice errato senza commenti, sei un cattivo programmatore. Non sembra una buona protezione del lavoro ... Probabilmente non sarai in grado di nasconderlo da tutto lo staff tecnico del tuo team. Alla fine qualcuno ti chiamerà per la gestione per non essere un ottimo sviluppatore. È più probabile che tu abbia una buona protezione sul lavoro se guadagni la reputazione di essere un grande sviluppatore che scrive un buon codice. È molto più probabile che tu protegga il tuo lavoro, dal momento che trovare buoni sviluppatori è molto più difficile che far capire a qualcuno codice mal scritto.

In ogni caso, non credo che gli sviluppatori debbano veramente preoccuparsi della sicurezza del lavoro oggi. è uno dei più grandi mercati del lavoro in crescita, quindi non è come se avessi bisogno di tenere la vita cara per un lavoro. Se perdi il lavoro per qualsiasi motivo, cambia idea e ci sono molte altre opportunità di lavoro.

Penso che i giovani non documentino il codice perché provengono dal college (o da un sistema educativo IT simile) che fanno solo piccoli progetti, quindi la documentazione non è necessaria.

La maggior parte dei programmatori esperienti possono essere questi giovani più anziani o semplicemente persone che lavorano sullo stesso progetto da anni, quindi conosce tutti gli aspetti del progetto e non si preoccupa degli altri perché è il capo / mente di quel progetto.

Non documentare il codice per la sicurezza del lavoro solo manterrà la tua posizione se si tratta di una piccola o vecchia azienda con la mente vecchia.

Un buon numero di aziende opera sotto la "conoscenza tribale" quando si tratta di progetti interni. Le persone che sono in giro da un po 'accumulano conoscenza e sono spesso riluttanti a rilasciare ai nuovi membri della tribù. Alcuni citano problemi di sicurezza ("Le nostre regole aziendali sono su una base di necessità di sapere e non è necessario conoscerle per il progetto"). Alcuni risponderanno in termini di acronimi che solo una persona con anni di esperienza in azienda saprà ("È necessario utilizzare l'interfaccia TXD unificata, non l'interfaccia TXM, per ottenere le proprietà UIO per trovare i valori standard JV. a ... ").

A volte questo è di design, con le persone che difendono le loro conoscenze e la loro superiorità nella squadra. A volte è proprio l'evoluzione della cultura dello sviluppo software dell'azienda. Il primo tipo può essere un ambiente di lavoro molto tossico ed è comune nelle aziende che praticano tecniche di gestione spietata del tagliagole come "rank and yank". Il secondo può accadere a causa di una gestione inconsistente o scarsa e tende ad essere più comune nelle aziende / gruppi più piccoli che sono cresciuti rapidamente con pochi controlli.

Tutto sommato, non è un buon ambiente di lavoro e un buon programmatore prenderà provvedimenti per evitare che ciò accada nella loro organizzazione. Sì, può comportare la sicurezza del lavoro per alcuni, ma è un costo pesante per l'azienda e per i membri del team.

Assolutamente no. Non durerebbero molto a lungo nella mia squadra, specialmente se fossi il loro superiore.

La documentazione del lavoro è preziosa per l'azienda in generale, quindi non vedo come sarebbe consentito continuare a meno che la società stessa non si accorga del fatto che il valore non va perso non disponendo di una documentazione adeguata.

Sarò dannato se riuscirò a ricordare ogni piccolo dettaglio del codice che ho scritto negli ultimi anni, quindi se non avrò documentato nulla alla fine mi metterò fuori lavoro.