Si sta specializzando nel settore IT? [chiuso]

Direi che una buona squadra dovrebbe avere un comune denominatore di conoscenze e abilità condivise da tutti gli sviluppatori. Tutti i programmatori C ++ competenti dovrebbero avere almeno una conoscenza di base di ad es. modelli e sapere a chi rivolgersi se vedono qualcosa al di sopra del loro limite. Dovrebbero anche condividere un'idea più o meno comune di come dovrebbe essere il "buon codice". E dovrebbero avere un quadro più o meno realistico del loro attuale livello di abilità, rispetto sia ad altri membri della squadra che all '"ideale", ad es. i migliori cannoni su SO.

Naturalmente, non tutti possono essere senior anche in una buona squadra - è perfettamente OK avere juniores. Tuttavia, tutti (compresi loro stessi) dovrebbero essere chiari sul fatto che sono junior (anche se riguardano solo le loro abilità C ++), e hanno bisogno di un tutoraggio più supervisione dei membri del team più esperti per apprendere le migliori pratiche e applicarle correttamente.

Ora, ovviamente, queste squadre sono rare nella vita reale. Tuttavia, dovremmo sforzarci di raggiungere questo ideale. Se risulta che il codice che hai scritto era confuso o incomprensibile per un altro sviluppatore e questo ha causato un bug / perdita di memoria / ..., puoi metterlo in pratica sulla retrospettiva del team e valutare i modi per evitare tali problemi in futuro. Potresti decidere di stabilire convenzioni di codifica comuni, per formare membri sprovvisti di conoscenze / abilità specifiche, di organizzare workshop che discutono i pro ei contro di specifici idiomi / schemi / tecniche di codifica, ecc.

L'importante questione qui è la comunicazione. Non è un caso che i metodi agili si concentrino così tanto su questo. Per esempio. XP include la programmazione di coppie, che rende naturalmente facile diffondere le conoscenze e le informazioni all'interno del team, e per i nuovi membri del team imparare la cultura locale, codificare gli idiomi e le migliori pratiche. La programmazione delle coppie non è sempre possibile, ma la comunicazione e la discussione all'interno del team dovrebbero essere incoraggiate e supportate con ogni mezzo.

Un altro problema che si cela dietro i tuoi esempi è la proprietà del codice. Che i diversi membri del team usino idiomi completamente differenti, o addirittura opposti, può facilmente accadere in un progetto in cui ognuno ha il suo feudo, esclusivamente "possedere" parte del codice. Tuttavia, accade molto meno spesso nei progetti in cui tutti possono toccare qualsiasi parte di codice e dove le persone sono - in misura maggiore o minore - regolarmente ruotate tra diversi moduli e parti di codice. Questo aiuta a condividere le conoscenze, aumentare il "fattore bus" e aiuta anche il team a lavorare su pratiche comuni e linguaggi di programmazione.

Nel 1985 ero altamente specializzato per un PC. I miei prog sono stati studiati dagli utenti e dalla fabbrica che ha reso questi PC forniti i miei programmi a tutti gli utenti. Il PC si estinse tre anni dopo. Il linguaggio era molto specifico, anche il sistema operativo. Tutto questo morbido divenne inutile. Anche le mie conoscenze.

Ora non metterei mai tutti gli egs in un cestino.

C'è una risposta a breve termine e una risposta a lungo termine, e nessuna delle due è assoluta.

Nel breve termine là tende ad essere un migliore ritorno sull'investimento in competenze specializzate. Se due persone stanno facendo domanda per un lavoro facendo C ++ (o Python o Oracle ...) e uno è più chiaramente più competente nel lavoro in corso, sarà generalmente scelto per questo. Alcune aziende cercano competenze più ampie, ma di solito sono assunzioni strategiche (dopo la scuola, programmi di formazione manageriale, ecc.) Piuttosto che compiti specifici. Se ho davvero bisogno di qualcuno che mi aiuti a ottenere i miei database per oltre 6 mesi, voglio una rockstar SQL, non qualcuno che abbia un po 'di tutto, e che abbia anche giocato a baseball alle superiori e che parli il latino.

Nel capovolgimento a lungo termine . Un buon CIO / CTO / CEO / Imprenditore / Leader deve essere in grado di conversare su molti livelli e su molti argomenti. La specializzazione potrebbe averli portati lì, ma essere un generale tende ad essere più importante. Solo in seguito, imparare cose al di sopra e al di là del lavoro (trascorrendo 3 mesi è supporto, automazione del test di apprendimento, un incarico laterale in Sud America) inizia a dare i suoi frutti.

Ovviamente c'è un consiglio più tattico, che è imparare cosa ti interessa. : -)

is it better to be just good at everything

No. Non puoi essere bravo in tutto. Sii bravo in ciò che ti viene assunto per il tempo più lungo se stai programmando per vivere, cioè fai quello che il mercato vuole (alcuni diranno di fare ciò che vuoi ma è all'altezza!)

The problem is, that with larger solutions programmers are rarely working alone, and most likely skills don't overlap that much either. So some parts of code I write might be confusing to other team members, and the other way around.

Questo non è il modo in cui va di solito. In un progetto con 10 persone, è probabile trovare 1 DBA, 2 persone per i test, 1 designer grafico e il resto sono tutti sviluppatori. Altri sviluppatori con la tua area di competenza devono capire il tuo codice. Ma il DBA no. Quindi parli con le pere. Non è comune essere l'unico sviluppatore C ++ in un progetto a meno che il linguaggio di base del progetto sia Java e l'integrazione sia richiesta o perché si conosce un'applicazione legacy che utilizza C ++ o simili. In ogni caso dovresti imparare a scrivere codice leggibile da altri e devi imparare a leggere il codice di altre persone. In buoni progetti, ci sono degli standard di codifica, la maggior parte degli sviluppatori li segue e questo rende il codice più o meno lo stesso. Se non si ottiene qualcosa, basta chiedere, si suppone di far parte di una squadra e tutti dovrebbero aiutare tutti gli altri - Questo è il lavoro di squadra, in parte è quello di condividere conoscenze con il vostro team. Se hai un modo migliore di fare le cose lo dimostri al resto. Se a loro piace, va bene, se non, vai con il flusso - È così semplice!

Personalmente, penso che sia difficile evitare almeno una certa specializzazione. Vorrei solo cercare di concentrarmi maggiormente su un campo ampio, piuttosto che su uno specifico. Consentitemi di usare "Bill" e "Bob" come esempi qui per descrivere il motivo per cui ritengo che ciò sia importante. Quindi questa grande azienda ha un grande mainframe del marchio X, e le lingue in cui è programmato sono chiamate Xasm e Xc. Bill e Bob fanno parte di un team dedicato a migliorare la sicurezza di questo mainframe. Bill si concentra sulla programmazione della sicurezza in generale e apprende la teoria alla base della gestione attiva della venerabilità e simili, mentre Bob si dedica alla programmazione sulla macchina e alle minacce di migitage sul sistema operativo speciale di questa macchina. Improvvisamente, la società che produce i mainframe del marchio X si venderà a Y e i progetti di X verranno gradualmente eliminati. Ora poiché Bill ha una grande esperienza nel campo della mitigazione delle minacce, insieme alla conoscenza di come usare il vecchio mainframe, è ancora di grande valore per l'azienda, poiché è richiesta solo una piccola riqualificazione. Bob, d'altra parte, sa solo come mitigare le minacce che esistono sui mainframe della marca X, molte delle quali potrebbero non avere controparti su Y.

Riposo il mio caso