Iniziare un nuovo lavoro ingegneristico può essere ansiogeno, ma uno dei nostri più recenti assunti ha dei consigli su come acclimatarsi al tuo nuovo ambiente.
Quando si inizia in una nuova azienda, è comune che un nuovo assunto sperimenti un po' di shock culturale. Gli uffici diversi, le persone, i processi, ecc. possono tutti essere sconcertanti. Tuttavia, gli ingegneri saranno spesso sottoposti a un ulteriore tipo di shock durante il loro onboarding. Chiamo questo shock culturale del codice.
Lo shock culturale del codice è specifico per chi lavora in un nuovo codice sorgente dove le cose potrebbero essere completamente diverse da quello a cui un ingegnere è abituato: cose come strutture di cartelle, modelli impiegati, configurazioni di test, librerie utilizzate, processi CI/CD, ecc. Anche piccole differenze come le regole lint e le configurazioni di formattazione possono essere uno shock.
Aggiungi a questo le differenze nelle preferenze personali tra i membri del team e tutto ciò può risultare piuttosto sconcertante. Tuttavia, c'è un lato positivo a questo shock. Porta a una situazione unica di cui sia i nuovi ingegneri che i membri del team esistenti dovrebbero essere pronti a trarre pieno vantaggio.
Massima potenzialità di feedback
Dopo che lo shock iniziale svanisce, c’è una piccola finestra di tempo in cui il potenziale per feedback onesti e imparziali è al suo massimo: prima che la prospettiva cambi da un esterno ingegneristico a un membro del team.
Questo punto dolce si verifica poco dopo che un ingegnere si è acclimatato al codice sorgente, ma prima che accettino ciò che vedono come 'così si fa'. È durante questa finestra che hanno la possibilità di sfruttare questo potenziale e offrire idee uniche sia al team che all'organizzazione più grande.
Ci sono alcuni modi chiave per sfruttare questo sentimento come nuovo ingegnere:
💪️ Rifiuta l'impostore
Ce l'hai fatta attraverso i colloqui, hai accettato l'offerta e ora sei pronto a fare il lavoro, ma c'è questa sensazione fastidiosa che forse sei in alto mare. Il codice sorgente e i processi ti sono estranei. Eri un esperto nel tuo ultimo lavoro e conoscevi i sistemi a menadito, eppure ora sei perso e ti stai interrogando.
Rilassati, andrà tutto bene! Sei stato assunto per il tuo potenziale di apprendimento e contributo. Nessuno si aspetta che tu sia un esperto dopo appena poche settimane. La sindrome dell'impostore è reale. Riconoscilo, ma poi metti da parte questi sentimenti e immergiti nel tuo nuovo ruolo.
☀️ Metti da parte i pregiudizi
Porta la tua conoscenza, esperienza e nuovo punto di vista e lascia i pregiudizi alle spalle. Noterai differenze nel codice sorgente rispetto a quello a cui sei abituato: del resto è tutto nuovo per te — ma fai attenzione a equiparare "diverso" a "sbagliato".
"Come lo avrei fatto io" non è lo stesso di "come dovrebbe essere fatto". Questa è la bellezza del codice: ci possono essere più soluzioni a un problema. Riconosci che, anche se a volte il tuo modo sarebbe stato migliore, spesso è solo diverso.
🛠️ Rompi le cose
C'è un motivo per cui non sviluppiamo in produzione e non c'è modo migliore per imparare un nuovo codice sorgente che sporcarsi le mani. Cambia qualcosa e guarda cosa succede. Vedi dello spazio per miglioramenti? Fallo.
Le probabilità sono che il tuo carico di lavoro sia probabilmente ancora leggero abbastanza da avere il tempo di fare esperimenti con nuove idee. Non preoccuparti se i cambiamenti non si rivelano. Uscirai comunque con una comprensione più profonda del codice in cui andrai a vivere.
📓 Documenta tutto
Catalogare qualsiasi cosa che sembri strana o diversa e annotare le domande che sorgono. Non è raro chiedersi perché l'hanno fatto in questo modo? Non assumere che il codice che stai vedendo sia perfetto così com'è. Ancora non conosci la storia di perché le cose siano come sono.
Potrebbe essere che il pezzo che stai guardando sia stato affrettato e che si siano tagliati angoli, intendendo rivederlo in un altro momento. I modelli e le librerie cambiano rapidamente e il codice diventa obsoleto prima che te ne accorga. Va bene, se non ci si aspetta, che tu faccia notare queste cose. Ricorda, se il codice fosse perfetto, non saresti stato assunto per lavorarci.
🤝 Condividere è prendersi cura
Una volta che ti senti a tuo agio, contatta il tuo team o il tuo manager e condividi il tuo feedback. Si rendono conto che sei nella posizione unica di offrire pensieri e idee fresche e lo accolgono.
Tutti stanno lavorando verso lo stesso obiettivo di creare il miglior prodotto per i nostri clienti. Il modo in cui raggiungiamo questo è ascoltando e imparando gli uni dagli altri.
Vuoi assicurarti di ricordare sempre i fantastici consigli in questo post? Non preoccuparti, abbiamo messo tutto in una scheda Guru!
Quando si inizia in una nuova azienda, è comune che un nuovo assunto sperimenti un po' di shock culturale. Gli uffici diversi, le persone, i processi, ecc. possono tutti essere sconcertanti. Tuttavia, gli ingegneri saranno spesso sottoposti a un ulteriore tipo di shock durante il loro onboarding. Chiamo questo shock culturale del codice.
Lo shock culturale del codice è specifico per chi lavora in un nuovo codice sorgente dove le cose potrebbero essere completamente diverse da quello a cui un ingegnere è abituato: cose come strutture di cartelle, modelli impiegati, configurazioni di test, librerie utilizzate, processi CI/CD, ecc. Anche piccole differenze come le regole lint e le configurazioni di formattazione possono essere uno shock.
Aggiungi a questo le differenze nelle preferenze personali tra i membri del team e tutto ciò può risultare piuttosto sconcertante. Tuttavia, c'è un lato positivo a questo shock. Porta a una situazione unica di cui sia i nuovi ingegneri che i membri del team esistenti dovrebbero essere pronti a trarre pieno vantaggio.
Massima potenzialità di feedback
Dopo che lo shock iniziale svanisce, c’è una piccola finestra di tempo in cui il potenziale per feedback onesti e imparziali è al suo massimo: prima che la prospettiva cambi da un esterno ingegneristico a un membro del team.
Questo punto dolce si verifica poco dopo che un ingegnere si è acclimatato al codice sorgente, ma prima che accettino ciò che vedono come 'così si fa'. È durante questa finestra che hanno la possibilità di sfruttare questo potenziale e offrire idee uniche sia al team che all'organizzazione più grande.
Ci sono alcuni modi chiave per sfruttare questo sentimento come nuovo ingegnere:
💪️ Rifiuta l'impostore
Ce l'hai fatta attraverso i colloqui, hai accettato l'offerta e ora sei pronto a fare il lavoro, ma c'è questa sensazione fastidiosa che forse sei in alto mare. Il codice sorgente e i processi ti sono estranei. Eri un esperto nel tuo ultimo lavoro e conoscevi i sistemi a menadito, eppure ora sei perso e ti stai interrogando.
Rilassati, andrà tutto bene! Sei stato assunto per il tuo potenziale di apprendimento e contributo. Nessuno si aspetta che tu sia un esperto dopo appena poche settimane. La sindrome dell'impostore è reale. Riconoscilo, ma poi metti da parte questi sentimenti e immergiti nel tuo nuovo ruolo.
☀️ Metti da parte i pregiudizi
Porta la tua conoscenza, esperienza e nuovo punto di vista e lascia i pregiudizi alle spalle. Noterai differenze nel codice sorgente rispetto a quello a cui sei abituato: del resto è tutto nuovo per te — ma fai attenzione a equiparare "diverso" a "sbagliato".
"Come lo avrei fatto io" non è lo stesso di "come dovrebbe essere fatto". Questa è la bellezza del codice: ci possono essere più soluzioni a un problema. Riconosci che, anche se a volte il tuo modo sarebbe stato migliore, spesso è solo diverso.
🛠️ Rompi le cose
C'è un motivo per cui non sviluppiamo in produzione e non c'è modo migliore per imparare un nuovo codice sorgente che sporcarsi le mani. Cambia qualcosa e guarda cosa succede. Vedi dello spazio per miglioramenti? Fallo.
Le probabilità sono che il tuo carico di lavoro sia probabilmente ancora leggero abbastanza da avere il tempo di fare esperimenti con nuove idee. Non preoccuparti se i cambiamenti non si rivelano. Uscirai comunque con una comprensione più profonda del codice in cui andrai a vivere.
📓 Documenta tutto
Catalogare qualsiasi cosa che sembri strana o diversa e annotare le domande che sorgono. Non è raro chiedersi perché l'hanno fatto in questo modo? Non assumere che il codice che stai vedendo sia perfetto così com'è. Ancora non conosci la storia di perché le cose siano come sono.
Potrebbe essere che il pezzo che stai guardando sia stato affrettato e che si siano tagliati angoli, intendendo rivederlo in un altro momento. I modelli e le librerie cambiano rapidamente e il codice diventa obsoleto prima che te ne accorga. Va bene, se non ci si aspetta, che tu faccia notare queste cose. Ricorda, se il codice fosse perfetto, non saresti stato assunto per lavorarci.
🤝 Condividere è prendersi cura
Una volta che ti senti a tuo agio, contatta il tuo team o il tuo manager e condividi il tuo feedback. Si rendono conto che sei nella posizione unica di offrire pensieri e idee fresche e lo accolgono.
Tutti stanno lavorando verso lo stesso obiettivo di creare il miglior prodotto per i nostri clienti. Il modo in cui raggiungiamo questo è ascoltando e imparando gli uni dagli altri.
Vuoi assicurarti di ricordare sempre i fantastici consigli in questo post? Non preoccuparti, abbiamo messo tutto in una scheda Guru!
Scopri il potere della piattaforma Guru in prima persona - fai il nostro tour interattivo del prodotto
