Cosa devo aspettarmi dal mio primo lavoro di programmazione? [chiuso]


37

Sono appena stato assunto per il mio primo lavoro di programmazione! Ho 25 anni e uso Java accademicamente da 6 anni.

Ora che sono stato assunto sono nervoso che le mie capacità non saranno quelle che il datore di lavoro si aspetta. Temo di essere assegnato a un progetto e devo fare molte domande che i miei colleghi sentiranno dilettanti.

È una paura razionale? Quali sono state le tue prime esperienze lavorative di programmazione? Cosa dovrei aspettarmi? Che consiglio potresti darmi?

Grazie.


16
Non ti preoccupare. La maggior parte dei datori di lavoro comprende che esiste un'enorme curva di apprendimento che si sposta dal mondo accademico all'industria. Sarei preoccupato se non facessi molte domande.
Pemdas,


Secondo me la cosa migliore che puoi fare è chiedere! Se c'è un problema, una domanda veloce è più efficiente di perdere ore mentre si cerca di capire qualcosa. All'inizio potresti chiedere un po 'di più, ma dopo qualche tempo sarai sicuramente in grado di rispondere alle domande dei colleghi "più esperti". Nessuno sa nulla e nessun datore di lavoro dovrebbe aspettarselo. Una comunicazione salutare è importante per un'azienda.
johannes,

Risposte:


57

Ci sono troppe cose che non puoi imparare al college . Ci sono anche molte cose che sono specifiche per l'azienda . In entrambi i casi, puoi scegliere:

  • o chiedi spiegazioni ai tuoi colleghi,
  • o non chiedi niente a nessuno e corri il rischio di sbagliare.

Se assumo qualcuno che non ha un'esperienza professionale, non mi dispiacerebbe se fa molte domande nelle prime settimane o mesi. D'altra parte, se teme di chiedere aiuto e spreca ore a risolvere un problema che un altro sviluppatore potrebbe risolvere in pochi secondi o commette errori stupidi che potrebbero essere facilmente evitati da qualcuno più aperto alla comunicazione con i colleghi, mi disturberà molto di più.

Non evitare domande. È un buon modo per imparare le cose e socializzare con le persone con cui lavorerai. Ma:

  • Non fare domande solo per farle.
  • Ricorda che altre persone hanno il loro lavoro da fare e le loro scadenze. Hanno altre cose da fare oltre a dedicare il loro tempo ad aiutarvi per ogni compito.
  • Non aspettarti che altre persone facciano il tuo lavoro (proprio come non è mai il benvenuto chiedere a Stack Overflow di fare il tuo lavoro).
  • Nota che se disturbi uno sviluppatore, perde dieci o più minuti per concentrarsi di nuovo. Quindi non fare domande se riesci a trovare una risposta in pochi secondi su Internet.

Esempio di domande sbagliate:

  • "Ehi, voglio creare un array come {1, 2, 3, ... n-1, n} in PHP. Puoi aiutarmi?" Qui, mostri solo che non solo non sai come utilizzare la documentazione di PHP, ma non ti preoccupi nemmeno di cercare su Google o pensare per un momento. Va bene se non conosci il rangemetodo in PHP. Non va bene se non riesci a trovarlo da solo.

  • "Sto cercando di implementare plugin, ma non so cosa sia CAS in .NET Framework. Puoi spiegarmi di cosa si tratta?" Sì, è più facile chiedere spiegazioni, ma per quanto riguarda la ricerca di "CAS .NET Framework 4.0" su Google?

  • "Perché mi stai costringendo a utilizzare il controllo versione? Ho sempre lavorato senza di esso e non capisco perché dovrei averne bisogno ora." Bene, i tuoi colleghi non devono spiegare perché devi usarlo. Innanzitutto, è una linea guida della tua azienda. Non sei qui per dettare come lavorare. In secondo luogo, ci sono molti libri, articoli di blog e risposte sui siti Web SE che spiegano perché tutti devono usare il controllo delle versioni. Devi solo cercare.

Esempi di domande che sono ben accette:

  • "Voglio eseguire il commit delle modifiche al controllo versione, ma c'è uno strano messaggio di errore. Dice: [...]. Forse sai cos'è questo?" È probabile che il tuo collega abbia visto questo messaggio dozzine di volte prima, quindi va bene chiedere questo.

  • "Sto leggendo la pagina 9 dei requisiti per questo progetto, parte 4.2.1, ma non sono sicuro: è a me o all'amministratore del database fare questa parte?" È meglio chiedere, piuttosto che passare tre giorni a fare il lavoro che è già svolto dalla DBA.

  • "Ho bisogno di implementare plugin, ma dopo aver letto questo e questo, ancora non capisco cosa sia un sandbox e come questo sia legato alla sicurezza. Potresti spiegarmelo in seguito quando sarai libero?" Hai cercato. Hai fatto uno sforzo. Non hai capito. Va bene non capire tutto e sarebbe meglio chiedere spiegazioni piuttosto che passare un fine settimana a cercarlo.


18
Vorrei sottolineare che, se la società non utilizzasse il controllo della versione, il 99,9% di noi qui sosterrebbe il tentativo di "dettare come lavorare" e di ottenere il controllo del codice sorgente.
whatsisname

" Perché mi stai costringendo a utilizzare il controllo versione? Ho sempre lavorato senza di esso e non capisco perché dovrei averne bisogno ora ." Risposta: "Ok, hai ragione. Lavora senza di essa per alcuni mesi, sulla nostra ampia base di codice tentacolare mentre tutti gli altri lo usano, e ne parleremo allora". Questo problema probabilmente si occuperà di se stesso.
joshin4colours,

1
Non fare domande solo per porle, d'accordo. Ma fai domande per ampliare le tue conoscenze. Se non lo fai, non stai cercando di imparare.
configuratore

Questi sono davvero dei buoni criteri, ma aggiungerei anche che alcune cose che non vale la pena chiedere durante la giornata lavorativa potrebbero essere perfettamente accettabili da chiedere a pranzo (se la cultura aziendale è tale che le persone mangiano insieme e sono d'accordo con la discussione di cose di lavoro ). Ciò impedisce al cambio di contesto aggiuntivo di rispondere alla domanda.
autofago

22

"L'unica domanda stupida è quella che non viene posta."

^ Seriamente. Ricordatelo.

Se sei stato negli accademici per 6 anni, presumo (e spero ) di avere una solida conoscenza dei concetti di ingegneria di base. A meno che tu non ti sia trovato in una brutta situazione con un terribile datore di lavoro, dovrebbero essere consapevoli del fatto che essendo appena usciti dalla scuola nel tuo primo lavoro, avrai una curva di apprendimento davanti a te e ti aspetterai di fare errori lungo la strada .

Se le tue abilità non corrispondessero a ciò che il datore di lavoro stava cercando, non ti avrebbero assunto. Se ti hanno assunto anche se le tue abilità non corrispondono a quello che stanno cercando, molto probabilmente non vorrai lavorare lì.

Più domande fai, più velocemente ti abituerai al tuo nuovo ambiente di lavoro. Detto questo, in genere agli ingegneri non piace essere costantemente infastiditi in quanto impiegano ~ 15 minuti a tornare nell'oscillazione delle cose. Quindi, potrei forse pensare di mettere tutte le tue domande rilevanti in una e-mail e inviarle a qualcuno nel "sapere" alla fine della giornata.

Alcune compagnie ti accoppiano con un mentore, altre no.


+1, preoccupando se il tuo collega penserà che una domanda sia stupida o meno, che costa tempo che potrebbe essere speso per porre la domanda e implementarla.
Nicholas Smith,

+1, ma una piccola nota sulla parte corrispondente alle abilità. A volte un datore di lavoro assumerà una persona entry level senza le competenze esistenti che mostrano un buon potenziale per acquisire tali competenze attraverso la formazione. In entrambi i casi, porre domande finisce per essere la soluzione.
Joel Etherton,

8

Smetti di preoccuparti così tanto. Nessuno è di classe mondiale il loro primo giorno.


8

Il mio primo lavoro di programmazione è stato quello di assumere un sito Web scritto in lingue che non conoscevo nemmeno. Ero l'unico sviluppatore e non avevo nessuno a cui chiedere aiuto. Avevo molta paura che non sarei durato a lungo (se non fosse stato per i forum, probabilmente non avrei avuto). Quindi cosa ho fatto? Ho fatto un sacco di domande sui forum. Tonnellate. Mi sentivo come se stessi facendo così tante domande "amatoriali" che ho reso il mio avatar "Sono stupido" (è ancora là fuori ... da qualche parte).

Il punto è che la paura è naturale ma la supererai e farai molte domande amatoriali. È il modo migliore per imparare. Almeno nel mio caso lo era, e lo è ancora.

Anche quando ero nella mia formazione informatica in campo militare, hanno brevemente approfondito ogni concetto e hanno detto che "Imparerai il tuo lavoro nella tua prima stazione di servizio .. questo è solo per avere una certa familiarità con qualsiasi cosa accada."


2

Se fai domande stupide, ma fai solo una volta, i tuoi pari non ti odieranno. Ma se non impari mai, diranno al tuo capo di licenziarti.

Il tuo sich è fuori dal tuo controllo. O sarai con persone buone che vorranno che tu abbia successo, o sarai con il male che vorranno che tu fallisca.

Cerca di non essere nervoso e fai solo quello che puoi. E dedica molto lavoro all'apprendimento della lingua e delle app aziendali.



1

Il mio primo lavoro di programmazione è stato in un linguaggio e un framework / piattaforma che non avevo mai toccato prima (Visual C ++ / MFC, e ho studiato in C su Unix con un po 'di Java).

Morale dell'aneddoto: quando non hai esperienza commerciale, il primo datore di lavoro che ti assume di solito ti vede più o meno come una lavagna pulita. Guardando indietro ora, anche se fossi stato assunto per un ruolo in C su Unix, il 95% + della curva di apprendimento all'inizio di quel primo lavoro sarebbe stato molto più incentrato su competenze trasversali, controllo delle fonti, politica / gestione dell'ufficio e altri simili cose per le quali l'esperienza accademica non può davvero prepararti. Dal punto di vista tecnico, generalmente si aspettano che tu sia molto traballante in piedi il primo o due mesi: lo shock al sistema dalle sole cose non tecniche è abbastanza una distrazione. Lo sanno, quindi probabilmente non si aspettano molto.

MainMa ha dei buoni consigli : in pratica cerca di non disturbare le persone con il tipo di domande che sono facili per Google e che dovrebbero venire con il territorio per qualcuno con 6 anni di esperienza accademica. Una buona regola empirica è che le conoscenze di programmazione generiche dovrebbero essere ricercate prima di chiedere, mentre le conoscenze interne specifiche dell'azienda / dominio sono molto più sicure da chiedere dopo uno scavo minimo.


1

Sono un neolaureato al college e sto sviluppando software da circa un anno. Temi anche le stesse cose esatte che temevo, quindi non sei solo. Mi sento come se avessi passato quello che stai descrivendo qui. Il miglior consiglio che posso darti è il seguente:

  1. Circondati di persone più intelligenti di te e disponibili a fare da mentore. Sii il più educato possibile, leggi le persone e scopri le tue alleanze. Non tutti saranno aperti per aiutarti, ma capirai facilmente chi sono le "persone giuste" e quelle con cui vorresti essere amico.
  2. Poni le domande il più possibile se ritieni che Google non possa rispondere.
  3. Renditi conto che ci sono molti che non vanno a scuola da un po 'di tempo, ed è probabile che possano vederti come una nuova mente per le idee. Non abbiate paura di sparare idee e non abbiate paura di non essere d'accordo con gli altri.

È una linea sottile, ma scoprirai dove attraversarla e dove no. La cosa migliore che puoi fare è essere entusiasta di apprendere e circondarti di persone che sanno più di te riguardo allo sviluppo del software.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.