Come suggerire le modifiche come dipendente assunto di recente? [chiuso]

Di recente sono stato assunto in una grande azienda (migliaia di persone, per dare un'idea delle dimensioni). Dissero di avermi assunto per il mio rigore e perché, nonostante la mia giovinezza (ho 25 anni), ero un programmatore C / C ++.

Ora che ci sono, posso vedere che l'intero sistema è vecchio e spesso utilizza tecnologie obsolete. Non esiste una convenzione di denominazione (file, funzioni, variabili, ...), non usano il controllo versione, non usano eccezioni o polimorfismo e sembra che quasi tutti abbiano perso la passione (alcuni hanno solo 30 anni ).

Vorrei suggerire alcuni cambiamenti, ma non voglio essere "il nuovo ragazzo che vuole cambiare tutto solo perché non vuole adattarsi". Ho cercato di "adattarmi", ma in realtà mi ci vuole una settimana per fare quello che farei un pomeriggio, proprio per via dei poveri strumenti che siamo costretti a usare. I miei colleghi non guardano mai molto alle nuove "cose" e tecniche che le persone usano oggi. È come se si fossero appena arresi. La situazione è davvero frustrante.

Sei mai stato in una situazione simile e, in caso affermativo, quali consigli mi daresti? C'è un modo sottile di cambiare le cose senza diventare la pecora nera qui? O dovrei rinunciare anche alla mia passione ed energia?

Grazie.

aggiornamenti

Seguendo i tuoi preziosi consigli sono stato in grado di suggerire modifiche e ora sono responsabile del team che deve creare e distribuire Subversion: D Grazie a tutti voi!

6 mesi dopo

Ho lasciato e ho trovato un ambiente molto più interessante, con una paga molto migliore e sfide più interessanti. Non ci tornerei per niente.

Mi trovavo in una situazione simile nella mia precedente azienda, dove ero stato per 5 anni. Quando mi sono iscritto nel 2004, erano:

• usano ancora Microsoft Access per i loro database (anche quelli business-critical)
• utilizzando Visual Basic 6 o Access / Excel VBA per lo sviluppo
• utilizzando molte terze parti invece di utilizzare internamente le risorse di sviluppo (i responsabili aziendali hanno guidato i propri progetti di sviluppo e il 90% delle volte ha messo in gara contratti all'insaputa dell'IT)
• sussulto senza controllo di versione.

Quando sono partito l'anno scorso, la compagnia era:

• utilizzando esclusivamente .NET e C #
• aveva bandito tutto lo sviluppo di Access
• utilizzando SVN per il controllo della versione
• aveva 2 potenti box di SQL Server e stavano migrando i database di Access esistenti su SQL
• tutto lo sviluppo è arrivato attraverso i team interni ed è andato in gara solo se le risorse erano limitate

All'epoca non avevo più compiuto 21 anni e il successivo più giovane nel team di sviluppo aveva 30 anni. Non ho fatto tutto da solo. Il responsabile IT era entrato a far parte dell'azienda contemporaneamente e voleva portare tutto lo sviluppo attraverso l'IT.

SVN è stato il mio primo risultato. Ho avuto un incontro con il mio responsabile di linea e ho messo in evidenza un paio di situazioni in cui il codice era stato reso attivo o modificato che aveva causato problemi, e ho sottolineato il fatto che non vi era alcuna responsabilità - praticamente non poteva incolpare nessuno, in fondo - e dopo questo ha ha iniziato ad ascoltare.

Ho quindi messo insieme una presentazione al team e spiegato il concetto di controllo della versione, e ho provato un paio di situazioni in cui SVN poteva aiutarci gli sviluppatori. I più giovani lo prendevano come un'anatra per annaffiare, i più grandi non tanto ma ci provavano e non si lamentavano di quelli che lo usavano.

Un altro risultato importante è stato portare in casa un sistema completo: ho guidato un progetto che ha consentito alla società di risparmiare 120.000 sterline all'anno in licenze. Ho trascorso circa 2 mesi del mio tempo libero a scrivere un nuovo sistema, l'ho presentato al responsabile IT e ho spiegato il risparmio sui costi. Mi ha quindi permesso di presentarlo al business e mi ha spiegato come potremmo implementare qualsiasi cosa a loro piacesse nel sistema - non essere più limitati ai sistemi "pronti all'uso".

4 settimane dopo il mio sistema era in pilotaggio in 10 località e 6 mesi dopo è entrato in funzione. Un anno dopo hanno annullato il contratto di terze parti, ne hanno rimosso tutte le tracce dalla rete e sono venuti da noi per un grande requisito di miglioramento del nostro sistema interno.

Il mio consiglio per te:

• se ti interessa la compagnia, sporgiti. Se ad altri non piace il tuo approccio, lascia che ti portino con te - si tratta di compromessi
• Adatta i suggerimenti alla persona con cui stai parlando: ai manager piace sapere come possono a) risparmiare denaro, b) incolpare accuratamente le persone quando le cose vanno male, ma agli sviluppatori piace sentire come possono a) risparmiare tempo, b) attaccare per se stessi, per esempio
• se sei appassionato di cambiamento (come sembra che tu sia), mostra alle persone il tuo entusiasmo e non scoraggiarti quando sono meno che entusiasti
• Non parlare di fare cambiamenti. Falli. Quando inizi a sfornare lavori fantastici in meno tempo rispetto ai ragazzi più esperti, le persone inizieranno a chiedere "perché?"

Dissero di avermi assunto per il mio rigore e perché, nonostante la mia giovinezza (ho 25 anni), ero un programmatore C / C ++.

Più probabilmente perché sei più economico.

Sei mai stato in una situazione simile?

Sì.

che consigli mi daresti

Partire.

C'è un modo sottile di cambiare le cose senza diventare la pecora nera qui?

Ci potrebbe essere. Introdurre modifiche e dimostrare come migliorano le cose per tutti. Dopo averlo fatto più volte, potresti ricevere apprezzamento da coloro che non sono persi.

O dovrei rinunciare anche alla mia passione ed energia?

Non c'è modo. Sei giovane e devi sfruttare appieno le opportunità. Non perdere anni "da qualche parte". Guarda questa posizione e capire se ti darà preziosa esperienza per guidare ulteriormente la tua carriera. Se vedi opportunità, esplorale. Se non ce ne sono ed è solo "un lavoro", esci. La pratica dimostra che coloro che hanno perso la passione (o non l'hanno mai avuta) non possono riacquistarla. Cerca una squadra di persone appassionate e unisciti a loro.

Dare l'esempio . Variazione incrementale di volta in volta. Accosta un collega e dimostra qualcosa a loro. Se non lo capiscono, riprovaci un'altra volta.

Prenderà del tempo. Basta non allontanare le persone dalle loro zone di comfort troppo rapidamente.

Triste ma è per questo che sei qui e non lo sono.

Per esempio. Imposta il controllo versione localmente e mostra loro come può essere d'aiuto. Quindi dai loro alcune risorse (lettura semplice) che possono aiutarti.

Un'altra cosa sugli strumenti . A volte devi spendere i tuoi soldi per acquistare strumenti migliori. So che non è "la cosa fatta", ma mentre parlo con altri commercianti trovo molti ingegneri "reali" che modellano / acquistano i propri set di strumenti per fare meglio il loro lavoro. Io per primo l'ho sempre fatto dove posso vedere che mi salvo dall'atrofia delle abilità.

Sono un vecchio (51) e ho avuto lo stesso problema in ogni lavoro che abbia mai avuto. Forse viene solo dall'essere sempre il ragazzo più intelligente nella stanza! :-) Seriamente, però, quando sai come farlo nel modo giusto e loro no, spesso pensi: "Ehi, mostrerò a tutti questa tecnica nuova e migliorata e saranno tutti colpiti e vorranno saltare dentro per usarlo. " Ma nella vita reale, il 90% delle volte, mostri alle persone un modo migliore e escogitano una lunga lista di scuse per capire perché il modo in cui lo hanno sempre fatto è meglio. Quando dimostri che le loro ragioni non sono valide, escogitano nuove, persino più lagnanti ragioni. Ho avuto molte volte che

Anche se sei davvero un genio, devi accettare che nessun altro sappia che sei un genio fino a quando non lo dimostrerai. Mi viene in mente Kris, un mio amico che ha iniziato un nuovo lavoro dopo aver trascorso 10 anni con una società. Poco dopo aver iniziato il nuovo lavoro, era a una riunione in cui stavano discutendo di alcuni problemi tecnici e ha iniziato a offrire la soluzione suggerita. Poi qualcun altro lo interruppe e disse: "Sì, grazie. Bob, che ne pensi?" All'inizio era seccato: conosceva la risposta giusta, ma a nessuno importava! Invece andarono con l'opinione di qualcuno che sapeva molto meno di lui. Ma poi si rese conto, ehi, nel mio vecchio lavoro, avevo costruito la reputazione di qualcuno che sapeva di cosa stava parlando, quindi quando parlavo, la gente ascoltava. Qui, non ho ancora una reputazione, quindi a nessuno importa cosa penso.

Sono stato nel mio lavoro attuale 2 anni ed è solo negli ultimi mesi che la mia opinione ha iniziato ad avere un peso reale. Devi essere paziente.

Il rovescio della medaglia, le nuove persone spesso hanno un milione di suggerimenti per miglioramenti che sono davvero poco pratici, perché non sanno ancora abbastanza sull'organizzazione e quindi non sanno perché le cose vengono fatte così come sono. A volte le persone continuano a fare qualcosa allo stesso modo per 20 anni perché è così che è sempre stato fatto e nessuno ha mai pensato di cercare un modo migliore; ma a volte le persone continuano a fare qualcosa allo stesso modo per 20 anni perché l'esperienza ha dimostrato che è un buon modo per farlo e ogni volta che provano qualcosa di diverso è un disastro. Quindi non essere troppo veloce per concludere che tutte queste persone sono idioti. Scopri perché lo stanno facendo alla vecchia maniera prima di presentare il tuo brillante nuovo suggerimento. Ho avuto molte volte nella mia vita in cui

Trova alleati che vogliono anche migliorare l'azienda.

C'è qualcosa da dire per salvarsi ora e lasciarli marcire. Tuttavia, sarà fantastico sul tuo curriculum se avanzi con successo il controllo della versione e altri miglioramenti.

Usa il Joel Test durante le tue interviste future. Ricorda che stai intervistando anche l'azienda.

Il mio primo consiglio è di non provare a cambiare troppo presto. In primo luogo ottenere una reputazione come un buon sviluppatore affidabile che può fare le cose. In questo momento come novizio, tutto ciò che suggerisci è sospetto; non ti conoscono e ti rispettano ancora. Ottieni quel rispetto come primo passo. Quindi è il momento di iniziare a introdurre modifiche.

Scegli la tua terra con attenzione. Inizia con il controllo della versione non con le nuove tecnologie. Perché davvero questo è il cambiamento più importante. Puoi anche farlo solo con il tuo codice e quindi assicurarti che quando devi tornare a una versione precedente o copmpare per scoprire cosa è cambiato, fai sapere alle persone quanto è stato facile in una conversazione casuale.

Usa le tue conoscenze più attuali per essere la persona che brilla e quindi le persone inizieranno a chiedere come stai facendo questo. Quando i pc sono arrivati ​​sul posto di lavoro, ho lavorato per un'agenzia di revisione governativa. Gli anziani erano tutti contrari a non avere i propri computer (visto che era lavoro per i segretari). I giovani hanno afferrato tutti i primi computer e hanno iniziato a fare cose che gli anziani non potevano fare con Lotus 1-2-3 e Harvard Graphics e all'improvviso, le persone anziane erano interessate perché i loro giovani stavano attirando l'attenzione di dirigenti di alto livello.

Il cambiamento in una cultura organizzativa non è un problema tecnico, è un problema politico. Leggi qualcosa sulla gestione della politica dell'ufficio. Avrai bisogno di sostegno politico ad alto livello.

Ho riscontrato una situazione simile nel mio attuale lavoro. Sono stato assunto direttamente dalla scuola di specializzazione per lavorare in un team composto principalmente da ingegneri che sono qui da più di 15 anni. Apportare modifiche non è stato facile (sto ancora spingendo per alcune cose da fare), ma è possibile.

Ad esempio, il mio team stava mantenendo, aggiornando e utilizzando un'utilità di test DOS a 16 bit. L'utilità è stata una vera seccatura da aggiornare, perché l'app ha spinto i limiti del linker a 16 bit al punto in cui se hai aggiunto il codice, hai dovuto rimuovere qualcos'altro per adattarlo. Alla domanda sul perché stavamo sprecando così tanto tempo ed energia sul codice a 16 bit, la loro risposta è stata "perché ne abbiamo bisogno per funzionare in DOS in modo da poterlo eseguire da un'unità flash avviabile". Ho provato a convincerli a portare l'utilità su Linux a 32 bit, ma il management non voleva investire il tempo per farlo (avevamo già troppo lavoro da fare così com'era). Così, sono andato avanti e ho portato l'utilità nel mio tempo di inattività (15 minuti qua e là a pranzo, nei fine settimana o mentre aspettavo che fosse compilato un altro codice). Nel corso di un paio di mesi, Avevo il porting completo dell'utilità, migliorato con tutti i tipi di cose che l'app originale a 16 bit non poteva gestire e l'avvio da un'unità flash Linux. Le persone hanno notato quando ho iniziato a usarlo e commentavano come potevo fare le cose più velocemente e come la mia utility generasse un migliore output di debug. Molto presto, la direzione ne ha sentito parlare. Una volta che hanno visto i benefici (e, soprattutto, che il lavoro era già stato svolto), non erano più contrari all'idea.

La lezione che ho imparato da questa storia è questa: se pensi di poter migliorare qualcosa, parlane con il tuo manager. Se non vogliono spendere le risorse su di esso, fallo da solo e dimostra loro che la tua idea è valida e utile. È molto più facile dire di no a un'idea che qualcuno propone piuttosto che a qualcosa che vedi di fronte a te che ha un valore evidente.

Una volta che il tuo team / manager implementa la tua idea e inizia a vederne i benefici, sarà molto più probabile che ascolti le tue idee in futuro. Ho usato il "credito di strada" guadagnato dal mio strumento di prova per riscrivere per convincere il mio team che dovevamo abbandonare il nostro attuale sistema di controllo della versione arcaica (che rimarrà anonimo per evitare imbarazzi) e migrare su Subversion. Mi sono offerto volontario per guidare lo sforzo di installazione / migrazione per garantire che la direzione lo approvasse.

È una specie di "un passo alla volta". Probabilmente ci sono un sacco di cose che vorresti cambiare, ma scegli qualcosa di piccolo (ish) per cominciare. Dimostra la qualità delle tue idee in modo che il tuo team e il tuo manager non possano dire di no. Proprio come il tuo account StackOverflow, più buone idee hai, migliore sarà la tua reputazione e più facile sarà per le tue idee essere accettate.

Sicuramente inizia a usare gli strumenti che vorresti avere localmente (dove puoi - alcune aziende sembrano anche controllare ciò che puoi installare sulla tua scatola con un pugno stranamente stretto). Imposta il tuo sistema di controllo versione preferito e inizia a usarlo. In qualsiasi codice che tocchi, apporta piccole modifiche che rendono il codice più pulito, soprattutto dove puoi scrivere qualsiasi nuovo codice. Se ti hanno assunto per il tuo rigore ed esperienza, ciò significa che ti rispettano già.

Di recente ho letto Assumere Ren e Stimpy e ho scoperto che l'esempio di Stimpy è stata una grande sfida. Se segui il suo esempio, finirai per chiedere (piacevolmente) ogni sorta di prospettiva ai tuoi colleghi, preparandoti ad avere la consapevolezza che uno sviluppatore senza passione non lo farà. Trascorrerai tutto il tempo libero che hai immaginando modi per apportare miglioramenti. Se l'azienda vede il tuo lavoro come prezioso, diventerai prezioso. In caso contrario, probabilmente vorrai cercare lavoro.

Molte persone hanno risposto con suggerimenti per concentrarsi su una piccola cosa alla volta e molti hanno suggerito il controllo della versione. Farò un ulteriore passo avanti: creare repository sul computer desktop e lavorare da quei repository. Aggiornali regolarmente da qualsiasi repository principale utilizzato dall'azienda. Quando (non se) c'è una crisi perché qualcuno ha danneggiato il master, digli che puoi tagliare una nuova copia dal tuo repository personale.

Tuttavia, non mettere in nessun caso il codice aziendale su una macchina di proprietà personale o da portare a casa . Perché allora potresti scoprire che, piuttosto che essere un eroe, sei dalla parte sbagliata della scrivania da un avvocato (nel migliore dei casi) o dalle forze dell'ordine (nel peggiore dei casi).

Proveniente da un altro sviluppatore junior ... hai grandi capacità di persone? Hai un eccellente senso di autocontrollo e una comprensione di quando è e non è appropriato proporre un'idea e come venderla al meglio? Anche se lo fai, potresti comunque finire per essere "quel ragazzo" per dire agli altri come fare il loro lavoro senza dimostrare il tuo valore.

È così che ancora costruisco la mia credibilità come sviluppatore junior: identifico un kink / kludge / time waster. Quindi lo aggiusto automatizzandolo (file batch, script PowerShell, programma semplice, nuovo freeware, qualunque sia il fine settimana) senza disturbare nessun altro. Mi assicuro di renderlo parte della mia continua autoeducazione tecnica in modo da poterlo pensare come "dedicare ore extra per insegnarmi una cosa nuova E aiutare l'azienda".

Se la mia correzione è particolarmente ingegnosa, la condivido e dico "Ehi ragazzi, ho creato questo fantastico strumento, automatizza XY e Z e fa velocemente quest'altra cosa". Mantieni il tuo nome su di esso. Ripetere. Problema di credibilità risolto in pochi mesi se sei in un'alta percentuale di artisti per il tuo livello e le persone sopra di te saranno più aperte ai tuoi suggerimenti se sei pronto a spiegare perché la tua idea è buona e come può risolvere i loro problemi.

Di recente sono stato in grado di proporre nuove idee ai dirigenti che sono state accettate, soprattutto perché mi sono preso il tempo di spiegare il mio ragionamento, ascoltare il loro feedback e avere la credibilità del mio lavoro passato.

ADDENDUM: Se il tuo manager mette in dubbio il tuo comportamento ... non fare queste cose a meno che non ritenga che la tua performance rimanga almeno "top 25%", IE assicurati che il tuo capo sia felice con te prima di iniziare a cercare di trovare tutti i tipi di soluzioni intelligenti che ti spingono più in alto in quella percentuale superiore o penserà che stai perdendo tempo. Se stai lanciando nuove utility e soluzioni mentre solleciti un feedback positivo sulle prestazioni, ma insiste ancora sul micromanage, potresti avere un problema che non rientra nell'ambito di questo argomento.

Miscela.

Come hai detto, non vuoi essere la pecora nera. Tuttavia, poiché tu (come me) vuoi aggiungere qualche utile cambiamento:

Aggiungi valore in background.

Imposta cronjobs per controllare il codice delle persone in svn / hg / git .. Crea i tuoi strumenti, nel tuo tempo libero, che possono migliorare in modo dimostrabile gli sforzi di sviluppo. In particolare, vuoi apportare miglioramenti all'azienda che puoi mostrare ai tuoi anziani nel tuo cubicolo. Ed ecco perché:

Wow factor

Se puoi dire "Ehi Alice, sai come ha appena rotto la build Bob? Posso ripristinare la sua modifica e la build funziona di nuovo". E quando il tuo anziano dice merda santa, forse ti sveglierai abbastanza passione da spingerti attraverso, o almeno incoraggiare, le tue nuove pratiche.

Ecco il mio consiglio

Ero in una situazione simile, dovrei prima dirlo, la mia azienda è piuttosto piccola con circa 6 sviluppatori, sono il tipo di programmatore a cui piace usare la nuova tecnologia, i nuovi strumenti e tutto ciò che renderà il mio lavoro più semplice e produrrà software di qualità migliore .

Quando ho iniziato, stavamo usando Visual Studio 2005, quando VS2008 è uscito da un po 'di tempo, ma convincere il mio capo a mettere da parte i soldi con l'aggiornamento di tutti i nostri sviluppatori non è stato facile, ho dovuto portare lentamente l'idea, visto che un "sarebbe bello se potessimo farlo", ma prima che lo portassi al mio capo, si sarebbe assicurato che gli altri sviluppatori sarebbero stati bravi nell'idea, perché sarebbero stati loro a usarlo e avere un gruppo di persone dentro il favore sembrerebbe meno come una decisione di una persona.

Penso che invece di presentare l'idea al tuo capo, magari far apparire lentamente eventuali cambiamenti, perché sento che se suggerisci idee che cambieranno l'azienda in modo migliore, mostra anche che ti preoccupi del tuo lavoro e dimostra che pianifichi su come fare una casa lì.

Ciò dipenderebbe anche dall'ambiente di lavoro in cui ti trovi e dalla personalità del tuo capo, se sono rilassati e ti trattano come una famiglia e ti danno consigli, quindi suggeriscilo, ma se ti trattano come un numero, starei molto attento a come ti avvicini.

Potrebbe essere un'opportunità di vita - cambiando il modo in cui un'azienda lavora a 25 anni. Se resistono e mostrano animosità tutto il tempo, non è il posto per te.

Ricorda, il tuo colloquio è stato un processo a doppio senso. Avresti potuto avere un'idea di quanto fossero arcaici e resistenti al cambiamento.

Ps, ho anche 25 anni e so come ti senti. Probabilmente sei molto più desideroso di imparare e provare cose nuove rispetto ai tuoi colleghi. Comunque, devo tornare a questo lavoro .NET4 che sto introducendo;)

Leggi Come fare le cose quando sei solo un grugnito di Joel Spolsky.

... a volte non hai il potere di creare cambiamenti nella tua organizzazione da parte di dirigenti. Ovviamente, se sei solo un programmatore grugnito nella parte inferiore del totem, non puoi esattamente ordinare alle persone di iniziare a creare programmi o database di bug. E infatti anche se sei un manager, probabilmente hai scoperto che gestire gli sviluppatori è molto simile a mandare i gatti, ma non è così divertente. Dire semplicemente "fallo così" non lo rende così.

Può essere frustrante quando lavori in un'organizzazione con un punteggio basso in The Joel Test . Non importa quanto sia buono il tuo codice, i tuoi colleghi scrivono un codice così cattivo che sei imbarazzato per essere associato al progetto. Oppure il management sta prendendo decisioni sbagliate su quale codice scrivere, quindi sei costretto a sprecare il tuo talento nel debug della versione AS / 400 di un gioco di pianificazione pensionistica per bambini.

... affrontare la vita in una squadra cattiva può essere esasperante. Ma ci sono strategie per migliorare la tua squadra dal basso, e mi piacerebbe condividerne alcuni ...

Lavorare con la direzione; non "impazzire". Lavora nel processo e metti le cose in termini comprensibili, come "l'implementazione di svn ci richiederà spazio su un server, due giorni per l'installazione, e dovremo eseguirne il backup, ma otterremo x, y, z , che può farci risparmiare un sacco di soldi ".

Smettere. Ci sono molti lavori là fuori. Non è il tuo lavoro riparare qualche compagnia casuale che ti è capitato di assumerti. A loro piace come sono, altrimenti assumerebbero un nuovo CTO o qualcosa del genere.