Aspettative dei laureati rispetto alla realtà [chiuso]

Quando scegliamo cosa vogliamo studiare, e facciamo con le nostre carriere e vite, tutti abbiamo alcune aspettative su come sarà. Ora che sono nel settore da quasi un decennio, ho riflettuto un po 'su quello che pensavo (quando stavo studiando Informatica) programmare la vita lavorativa come sarebbe stata e su come sta andando a essere.

I miei due più grandi shock (o dovrei dire, aspettative infrante) sono di gran lunga la quantità di lavori di manutenzione coinvolti nel software e la mancanza generale di professionalità:

1. Manutenzione : in uni ci è stato detto che la maggior parte del lavoro software è la manutenzione di sistemi esistenti. Quindi sapevo aspettarmi questo in astratto. Ma non avrei mai immaginato esattamente quanto sarebbe stato travolgente. Forse è qualcosa su cui ho mentalmente messo a fuoco, e speravo di poter costruire nuove fantastiche cose da zero. Ma è davvero il caso che la maggior parte dei lavori siano in stragrande maggioranza di manutenzione, correzione di bug e supporto orientato.

2. Mancanza di professionalità : in uni, ho sempre avuto l'impressione che il lavoro sul software commerciale fosse molto orientato ai processi e rigorosamente progettato. Avevo immagini di processi ISO, risme di documentazione tecnica, ogni caratteristica e bug rigorosamente documentati e un ambiente generalmente professionale. È stato uno shock enorme rendersi conto che la maggior parte delle società di software non opera diversamente da un team di studenti che lavorano su un grande progetto lungo un semestre. E ho lavorato sia nel piccolo e agile negozio di hacking, sia nella media impresa aziendale. Anche se non direi che è sempre stato "poco professionale", sembra che l'industria del software (nel suo insieme) sia lontana dalla forte disciplina ingegneristica che mi aspettavo.

Qualcun altro ha avuto esperienze simili a questa? Quali sono i modi in cui le tue aspettative su come sarebbe la nostra professione erano diverse dalla realtà?

Ti sento amico. In effetti, mi sono appena laureato poco più di un anno fa, sono saltato sulla prima offerta di lavoro che mi è arrivata e ho avuto il più grande shock della mia vita.

Cose che non mi aspettavo:

Lo stress scolastico e lo stress da lavoro non sono gli stessi - Lo stress di lavorare su un progetto scolastico con gli amici o di lavorare da soli, anche con quella scadenza di tesi incombente o la difesa di un progetto speciale non è paragonabile allo stress di scadenze di lavoro apparentemente irragionevoli, problemi di comunicazione , (un po 'di politica dell'ufficio) e tempi di crisi.

Mancanza di buone pratiche - Come la tua esperienza sulla professionalità. Prima di assumere il mio primo lavoro e durante il mio periodo di formazione, mi sono precipitato a rivedere e leggere le migliori pratiche in ingegneria di programmazione e software. Questi non sono seguiti come dovrebbero per ragioni impraticabili e, per essere giuste, pratiche. E a volte, la tua conoscenza conta molto poco contro gli altri che hanno semplicemente paura dell'ignoto e trattano queste pratiche con disprezzo.

Quello che hanno insegnato a scuola era solo la punta dell'iceberg - Pensando che ciò che ho imparato da autodidatta e dalle lezioni fosse abbastanza per farmi passare, sono rimasto scioccato nel dire il minimo mentre fissavo sbalordito il primo pezzo di codice che ero dovrebbe mantenere. Molte delle competenze che utilizzo ora sono state apprese sul posto di lavoro o durante il mio lavoro che continuo a chiedermi se avrei potuto farcela senza una laurea. XD

L'importanza della comunicazione - Mi ha fatto capire a cosa servivano tutte quelle lezioni di inglese. Prima del mondo reale, non vedevo la rilevanza di avere da tre a quattro diverse classi di inglese al college quando è stato insegnato da quando eravamo in prima elementare. Non sei utile nel tuo lavoro quando puoi parlare con un computer ma non riesci a parlare con le persone.

Gran parte del lavoro che fai non è innovativo

Quando in Uni, ho lavorato su routine di intelligenza artificiale per controllare i robot che giocavano a calcio, ho creato compilatori e violato i kernel del sistema operativo.

Ma nel mondo reale, il 99% ^* dello sviluppo software è in realtà piuttosto noioso. Ho sempre ammirato architetti o costruttori che, alla domanda "cosa fai per vivere?" può puntare a un edificio o di qualsiasi altra cosa e dire "ho fatto che ". Ma la maggior parte degli sviluppatori di software non può farlo. Alla domanda "cosa fai per vivere?" il più vicino a quello che io abbia mai potuto venire è quando lavoravo per una società che costruiva software che elaborava messaggi SMS per stazioni radio e simili ... Potrei dire "sai quando scrivi un messaggio a una stazione radio per votare una canzone, bene ho scritto il software che elabora quei voti e roba del genere ". Ancora non è così bello come essere in grado di indicare un edificio e dire "L'ho costruito io".

Certo, ci sono persone che possono dire "Ho lavorato su Windows" o altro, ma sono sicuro che in realtà non dicono a nessuno che per paura della domanda successiva sia "Non riesco a far funzionare la mia stampante, puoi aggiustarlo per me? "

^* e il 62% di tutte le statistiche è composto in loco

Se guardi il software oggi, attraverso l'obiettivo della storia dell'ingegneria, è certamente una sorta di ingegneria, ma è il tipo di ingegneria che hanno fatto le persone senza il concetto di arco. La maggior parte dei software oggi è molto simile a una piramide egizia con milioni di mattoni accatastati l'uno sull'altro, senza integrità strutturale, ma realizzati solo con la forza bruta e migliaia di schiavi. -Alan Kay, 2004

l'intervista completa: http://queue.acm.org/detail.cfm?id=1039523

Non sono un veterinario del settore; Al contrario, sono un neolaureato ma di una delle migliori scuole di CS negli Stati Uniti. Ma la mia sensazione istintiva è che il modo in cui stiamo costruendo il software sia sbagliato. Piuttosto che premere il pulsante Pausa e riesaminare i fondamenti di come programmiamo, ci siamo semplicemente precipitati in avanti usando modelli datati degli anni '50, '60 aggiungendo continuamente un po 'di zucchero in cima. Se continuiamo così non passeremo mai dove siamo. Gli umani non riescono a gestire la complessità di cose che hanno le dimensioni della base di codice di MS Windows. Abbiamo bisogno di un nuovo modo. Non so cosa sia.

Penso che questo sia il motivo alla base della sensazione che i negozi di software grandi e piccoli sembrano creare software hackerandolo insieme senza una profonda comprensione dei principi fondamentali.

Non mi sono laureato, ma ho preso un po 'di college e biblioteche e laboratori universitari.

• Big Iron - Le tecnologie a cui insegnavano erano principalmente mainframe e minicomputer. Il preside di un college mi ha detto che non sarei riuscito a trovare un lavoro perché non sapevo nemmeno cosa fosse un masterfile. Non avevo intenzione di lavorare su mainframe poiché non potevo permettermene uno, ma non sarei stato così sciocco da non essere leggermente preparato. I VAXen erano fantastici e non vedevo l'ora di essere pagato per il codice sul mio Micro VAX nel mio cubicolo. Che peccato che quel mercato sia completamente imploso. (Si è scoperto che avevo due posizioni lavorando con mainframe ... come appaltatore per IBM.)

• Ingegneria del software - Sulla scia della programmazione strutturata, del SASD e di altre metodologie di progettazione, potresti aver pensato che saremmo stati dei veri ingegneri. L'ho fatto. Ma gli insegnanti davano pochissime indicazioni sulle tecniche di progettazione che ho letto in biblioteca. Gli studenti sono stati lasciati a badare a se stessi e i micro hanno reso troppo facile sbagliare nel codice fino a quando non hanno ottenuto una risposta di cui erano felici. Non mi rendevo conto di quanto fosse peggio nel mercato del lavoro. In qualche modo ho dovuto fare un bel po 'di nuovo codice, quindi non era così noioso. Ma ho anche assunto molto, ed erano abbastanza cattivi, era come un nuovo progetto perché dovevo sistemare molto codice. Era una combinazione di ricerca di funzionalità esistenti e creazione di nuovo codice (la sua sostituzione); scrivere strumenti per semplificare il processo e istituire una migliore gestione dei progetti.

• Carriera ad alta tecnologia - Una cosa è quando le scuole hanno vecchi edifici e attrezzature (l'attrezzatura per le schede perforate è stata sostituita il semestre prima che iniziassi ... nel 1984), ma quando lavori in un magazzino scarsamente illuminato o per un capo che riattacca sui clienti che chiamano la linea di supporto, inizi a capire che la descrizione del tuo lavoro non includerà probabilmente la cottura di popcorn con un laser da 5 megawatt.

• Lo sviluppo è principalmente il lavoro di squadra. Ciò significa che la comunicazione (parlata e letta), la lettura del codice altrui e il riutilizzo dei moduli precedenti (sia interni che esterni) è qualcosa da affrontare quasi ogni giorno. Nel mio college, almeno ho dovuto programmare con più persone in pochissime occasioni, quindi ho pensato che la parte principale del lavoro fosse programmare da solo, nel deserto. Non è.
• Spiegare le cose ai non sviluppatori è difficile (anche coperto per il primo punto), ed è tua responsabilità esprimere i tuoi punti (non dell'altro 99% del mondo).
• Il buon test è il test che fallisce. (almeno la prima volta) E, naturalmente, non esiste un codice privo di bug. Non sei un cattivo programmatore se hai dei bug. I bug sono solo una parte (molto importante e che richiede tempo) del tuo lavoro.
• Non ci sono proiettili d'argento. Ogni tecnologia ha i suoi vantaggi e svantaggi.
• Il college non ti insegna le tecnologie più avanzate. Inoltre, il 90% delle opere utilizza tecnologie piuttosto vecchie. Che, a proposito, a volte è ciò che è necessario.
• Le persone non tecniche prendono decisioni sulle soluzioni tecniche , principalmente per ragioni esoteriche come manutenzione, collaborazione, disponibilità dei lavoratori ...
• Stai appena iniziando , giovane Padawan .

Da allora ho iniziato a rendermi conto del fatto che la codifica è un lavoro che fai in collaborazione con più persone, specialmente ora che l'open source è più importante. Ma quando ero al college (fine degli anni Novanta), ero convinto che avrei fatto le cose da zero e non avrei mai guardato il codice degli altri o non avrei dovuto coordinarmi con gli altri ...

Guardando indietro, per me una delle parti migliori è imparare e insegnare agli altri .

• La programmazione per computer non è fisica e non è intuitiva.
  • Quando un costruttore di case termina il suo lavoro, può camminare e vedere / sentire immediatamente se c'è qualcosa che non va. Un errore di programmazione del computer non può essere scoperto allo stesso modo e può nascondersi nel sistema per mesi o addirittura decenni.
  • Mentre un programmatore può apparire / sentire un pezzo di codice sorgente attraverso la revisione del codice, non è garantito individuare ogni errore contenuto nel codice. Un computer, tuttavia, sarebbe in grado di riprodurre esattamente l'errore ogni volta eseguendo il programma con determinati input. Pertanto, la comprensione umana di un pezzo di codice sorgente è sempre un modello imperfetto dell'essenza di esso come istruzioni per un computer.
• È molto facile codificare un programma che gestisce i casi più comuni, ma non riesce a gestire i casi limite.
  • In altre discipline, è relativamente facile applicare un'azione correttiva dopo il fatto. Potrebbe anche esserci un corpus di conoscenze specificamente dedicato alle azioni correttive. Non esiste nulla di simile nello sviluppo del software.
  • Fortunatamente, lo sviluppo guidato dai test aiuta a codificare i casi limite che il codice dovrebbe gestire.
  • Aggiunto d' altra parte, alcune metodologie di sviluppo software sembrano suggerire che possiamo estrarre valore aziendale (time to market più veloce, ecc.) Scegliendo consapevolmente di non gestire casi limite e di comunicare tali decisioni ai clienti.
• I clienti possono trovare valori aziendali in un software che gestisce solo i casi più comuni, pertanto i fornitori di software non sono troppo preoccupati per la gestione dei casi rari.
  • I clienti imparano semplicemente a evitare i bordi irregolari.

aggiunto

• L'eleganza del codice sorgente non è valutata.
  • I clienti non vedono l'eleganza del codice sorgente. Vedono solo l'eleganza dell'interfaccia utente e delle interazioni.
  • I programmatori, d'altra parte, di solito non apprezzano l'eleganza dell'interfaccia utente e di solito non rimangono in un singolo progetto per un tempo abbastanza lungo da iniziare ad apprezzare un design elegante del software.
  • Poiché né i clienti né i programmatori apprezzano l'eleganza del codice sorgente, né sarà valutato dalle aziende.

aggiunto

I miei due centesimi: abituati.

Immagini di processi ISO, risme di documentazione tecnica, ogni caratteristica e bug rigorosamente documentati e un ambiente generalmente professionale descrivono abbastanza bene la mia azienda. Facciamo prodotti infrastruttura software / hardware critici, però, così, bene, la pressione è su per la qualità (siamo certificati ISO 9001, per esempio).

Dopo la laurea, ho pensato che i responsabili sarebbero stati in grado di riconoscere un buon lavoro da un cattivo lavoro. Dopo aver ricevuto la milionesima copia di "codice davvero eccezionale, il nostro miglior programmatore messo insieme" e averlo simile a questo:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Ho quasi rinunciato a cercare di capire cosa succede tra le orecchie del capo dai capelli a punta. "Grande" significa incubo di mantenimento, "buono" significa crash in una leggera brezza, e "orribile pasticcio" significa quello o una base di codice ben strutturata i cui ingegneri si sono chiaramente rifiutati di rispettare scadenze oscene solo per mantenere la sanità mentale.

Ho sentito dire che tutta l'ingegneria del software dopo la prima riga di codice è mantenuta. E questo sembra certamente corrispondere alla mia esperienza. L'unico codice che ho scritto che non ha avuto la maggior parte dei suoi costi di manutenzione è stato il codice che non ha avuto successo che non è mai stato usato o solo per un breve periodo.

Penso che puoi trovare team di ingegneri disciplinati che sviluppano e seguono processi forti che portano al rilascio di un codice robusto in cui il team può avere un alto livello di fiducia (anche se non lo contenderei con grandi quantità di documentazione). Credo che al momento lavoro in una squadra del genere. Anche se ho sicuramente sperimentato l'altro tipo di sviluppo.

La cosa che ho imparato ad apprezzare è che la sfida non è sempre quella di trovare l'algoritmo perfetto o la soluzione più pulita al problema. Ma spesso negoziando ogni sorta di vincoli (risorse, conoscenze, denaro, tempo, competenze, rischi, formazione preesistente degli utenti, ecc.) Per ottenere il massimo ritorno per l'investimento disponibile. Ciò sta costruendo un sistema che si adatta meglio a tutti quei fattori e non solo alle influenze tecniche.

Un sacco di software non arriva al punto in cui viene usato / acquistato abbastanza. Quando uno lo fa, tende a rimanere in giro ed è solo "incasinato" nella manutenzione.

Le aspettative degli utenti aumentano ogni giorno per le funzionalità, ma in molte aree sono inferiori nelle aree di ingegneria. Supponiamo che il software di transazione bancaria sia solido e progettato professionalmente come un'automobile moderna. La gestione del volume è una meraviglia moderna, ma quale è l'affidabilità di ogni transazione? Non così tanto. Il tuo post sulla prima schifezza del tuo cucciolo sul tappeto è stato abbandonato, e allora. È più come i piccoli sacchetti di plastica al supermercato. Ne fanno miliardi, si strappano e si strappano e vengono gettati via. Alla maggior parte delle persone non importa abbastanza da richiedere una borsa migliore.

Penso che alla fine vengano realizzati software di qualità. Alcuni di questi arrivano sul mercato prima della maggior parte dei prodotti commerciali. Chi arriva a guidare un'auto in Beta?