Graduate aspettative contro realtà [chiuso]

Ti sento uomo. Mi sono appena diplomato poco più di un anno fa, infatti, sono saltato sulla prima offerta di lavoro che mi è capitata e ho avuto il più grande shock della mia vita.

Cose che non mi aspettavo:

Lo stress della scuola e lo stress da lavoro non sono gli stessi - Lo stress di lavorare su un progetto scolastico con gli amici, o lavorare da solo, anche con quella scadenza di tesi o una difesa speciale del progetto non è paragonabile allo stress di scadenze lavorative apparentemente irragionevoli, problemi di comunicazione, (un po 'di politica dell'ufficio) e crunch volte.

Mancanza di best practice - Come la tua esperienza sulla professionalità. Prima di intraprendere il mio primo lavoro e durante il mio periodo di formazione, mi sono precipitato a recensire e leggere le migliori pratiche sia nella programmazione che nell'ingegneria del software. Questi non sono seguiti come dovrebbero per motivi pratici e, per essere giusti, pratici. E a volte, la tua conoscenza conta molto poco contro gli altri che hanno semplicemente paura dell'ignoto e trattano queste pratiche con disprezzo.

Ciò che insegnavano a scuola era solo la punta dell'iceberg - Pensando che quello che imparavo da autodidatta e dalle classi era sufficiente per farmi passare, rimasi scioccato a dir poco, mentre fissavo interdetto al primo pezzo di codice che avrei dovuto mantenere. Molte delle abilità che uso ora sono state acquisite durante il lavoro o durante il mio lavoro e continuo a chiedermi se potrei averlo fatto 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 riuscivo a vedere l'importanza di avere da tre a quattro classi di inglese diverse 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 riescono a parlare con le persone.

La maggior parte del lavoro svolto non è rivoluzionario

Quando ero a Uni, ho lavorato su routine AI per controllare i robot che giocavano a calcio, ho compilato compilatori e ho hackerato i kernel del sistema operativo.

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

Ovviamente, sono persone che possono dire "Ho lavorato su Windows" o altro, ma sono sicuro che in realtà non lo dicono a nessuno per timore che la prossima domanda sia " Non riesco a far funzionare la mia stampante, puoi aggiustarla per me? "

^* e il 62% di tutte le statistiche sono compilate in loco

If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -Alan Kay, 2004

l'intervista completa: link

Non sono un veterinario del settore; Al contrario, sono un neolaureato ma da una scuola CS superiore negli Stati Uniti, ma la mia sensazione istintiva è che il modo in cui stiamo costruendo software è sbagliato. Piuttosto che premere il pulsante di pausa e riesaminare i fondamenti di come programmiamo, ci siamo solo affrettati a utilizzare modelli datati degli anni '50 e '60, aggiungendo continuamente un po 'di zucchero. Se continuiamo così, non andremo mai oltre a dove siamo. Gli umani non sono in grado di gestire la complessità di cose che sono 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 del sentimento che negozi di software grandi e piccoli sembrano fare software hackerandolo insieme senza una profonda comprensione dei principi fondamentali.

Non ho conseguito la laurea, ma ho imparato un po 'da college e biblioteche universitarie e laboratori.

• Big Iron - Le tecnologie che stavano insegnando erano principalmente mainframe e minicomputer. Il decano 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 perché non me ne potevo permettere uno, ma non sarei stato così sciocco da non essere un po 'preparato. VAXen era bello, e non vedevo l'ora di essere pagato per il codice sul mio Micro VAX nel mio box. Che peccato che il mercato sia completamente imploso. (Come risultato ho avuto due posizioni di lavoro con mainframe ... come un appaltatore per IBM.)

• Ingegneria del software - Sulla scia della Programmazione strutturata, SASD e altre metodologie di progettazione, avresti potuto pensare che saremmo diventati dei veri ingegneri. L'ho fatto. Ma gli insegnanti hanno dato pochissime indicazioni sulle tecniche di progettazione che ho letto in biblioteca. Gli studenti sono stati lasciati in balia di se stessi e micros ha reso troppo facile scandagliare il 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 dovevo fare un bel po 'di nuovo codice, quindi non era così noioso. Ma ho anche preso molto, e sono stati abbastanza brutti è stato come un nuovo progetto perché ho dovuto sistemare un sacco di codice. Era una combinazione di ricerca di funzionalità esistenti e creazione di nuovo codice (la sua sostituzione); strumenti di scrittura per semplificare il processo e istituire una migliore gestione del progetto.

• Carriera high-tech - Una cosa è quando le scuole hanno vecchi edifici e attrezzature (l'attrezzatura per le schede perforate è stata sostituita nel semestre prima di iniziare ... nel 1984), ma quando sei lavorando in un magazzino scarsamente illuminato o per un capo che riaggancia sui clienti che chiamano la linea di supporto, si inizia a realizzare che la descrizione del proprio lavoro non includa probabilmente la cottura di popcorn con un laser da 5 megawatt.

• Lo sviluppo è principalmente lavoro di squadra. Ciò significa che la comunicazione (parlata e letta), la lettura del codice degli altri e il riutilizzo dei moduli precedenti (sia interni che esterni) è qualcosa da affrontare quasi ogni giorno. Nel mio college, almeno ho dovuto codificare più persone in pochissime occasioni, quindi ho pensato che la parte principale del lavoro era codificare da soli, nel deserto. Non lo è.
• Spiegare le cose ai non sviluppatori è difficile (coperto anche per il primo punto), ed è tua responsabilità rendere i tuoi punti (non del resto il 99% del mondo).
• Il buon test è il test che fallisce. (la prima volta, almeno) 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 dispendiosa in termini di tempo) del tuo lavoro.
• Non ci sono pallottole d'argento. Ogni tecnologia ha i suoi vantaggi e svantaggi.
• Il college non ti insegna tecnologie allo stato dell'arte. Ma anche il 90% delle opere utilizza tecnologie piuttosto antiche. Che, a proposito, a volte è ciò che è necessario.
• Le persone non tecniche prendono decisioni sulle soluzioni tecniche , principalmente per ragioni esoteriche come manutenzione, partnership, disponibilità dei lavoratori ...
• Hai appena iniziato , giovane padawan .

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

Guardando indietro, per me una delle parti migliori è apprendimento e insegnamento ad altri .

• La programmazione per computer non è fisica e non è intuitiva.
  • Quando un costruttore di case finisce il suo lavoro, può camminare e vedere / sentire immediatamente se c'è qualcosa di sbagliato. Un bug di programmazione del computer non può essere scoperto allo stesso modo e potrebbe nascondersi nel sistema per mesi o addirittura decenni.
  • Mentre un programmatore può guardare / 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 un determinato input. Quindi, la comprensione umana di un pezzo di codice sorgente è sempre un modello imperfetto della sua essenza essendo le istruzioni per un computer.
• È molto facile codificare un programma che gestisce i casi più comuni, ma non riesce a gestire completamente i casi limite.
  • In altre discipline, è relativamente facile applicare un'azione correttiva post-fatto. Potrebbe anche esserci un corpo di conoscenze specificamente dedicato alle azioni correttive. Non c'è nulla di simile nello sviluppo del software.
  • Fortunatamente, lo sviluppo basato sui test aiuta a codificare i casi limite che il codice deve gestire.
  • Aggiunto D'altro canto, alcune metodologie di sviluppo del software sembrano suggerire che possiamo estrarre valore aziendale (time-to-market più veloce, ecc.) scegliendo consapevolmente di non trattare casi limite e di comunicare tali decisioni a i clienti.
• I clienti possono trovare valori aziendali in un software che gestisce soltanto i casi più comuni, pertanto i fornitori di software non sono troppo preoccupati di gestire i casi rari.
  • I clienti imparano semplicemente ad evitare gli spigoli.

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 sufficientemente lungo per iniziare ad apprezzare un design elegante del software.
  • Perché né i clienti né i programmatori apprezzano l'eleganza del codice sorgente, né saranno valutati dalle aziende.

Aggiunto

I miei due centesimi: ci si abitua.

Immagini di processi ISO, risme di documentazione tecnica, ogni funzionalità e bug sono rigorosamente documentati e un ambiente generalmente professionale descrive abbastanza bene la mia azienda. Facciamo prodotti software / hardware di infrastruttura critica, quindi, beh, la pressione è on per la qualità (siamo certificati ISO 9001, ad esempio).

Dopo la laurea ho pensato che i responsabili sarebbero stati in grado di riconoscere il buon lavoro da un cattivo lavoro. Dopo aver ricevuto la milionesima copia del "codice veramente grande che il nostro codificatore principale ha messo insieme" e averlo assomigliare 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 della manutenzione, "buono" significa che si blocca con una brezza leggera, e "pasticcio orribile" significa o quello o una base di codice ben strutturata i cui ingegneri si sono chiaramente rifiutati di rispettare scadenze oscene solo per mantenere il loro equilibrio.

Ho sentito affermare che tutta l'ingegneria del software dopo la prima riga di codice è la manutenzione. E questo sicuramente sembra corrispondere alla mia esperienza. L'unico codice che ho scritto che non ha finito per mantenere la maggior parte del suo costo è stato il codice che è stato così insoddisfacente che non è mai stato usato solo per poco tempo.

Penso che tu possa trovare team di ingegneri disipiati che sviluppano e seguono processi forti che portano al rilascio di codice robusto su cui il team può avere un alto livello di fiducia (sebbene non lo contorcessi con una grande quantità di documentazione) . Credo di lavorare in una squadra del genere al momento. Anche se ho certamente sperimentato l'altro tipo di sviluppo.

La cosa che ho imparato ad apprezzare è che la sfida non è sempre trovare l'algoritmo perfetto o la soluzione più pulita al problema. Ma spesso negoziare tutti i tipi di vincoli (risorse, conoscenza, denaro, tempo, abilità, rischio, formazione degli utenti preesistenti, ecc.) Per ottenere il massimo ritorno per l'investimento disponibile. Questo sta creando un sistema che è più adatto 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 lo si fa, tende ad aggrapparsi ed è solo "incasinato" con la manutenzione.

Le aspettative degli utenti aumentano ogni giorno per le funzionalità, ma in molte aree sono inferiori nelle aree dell'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 quanto manca all'affidabilità di ogni transazione? Non così tanto. Il tuo post sulla prima merda del tuo cucciolo sul tappeto è stato eliminato, quindi cosa? È più come i piccoli sacchetti di plastica al supermercato. Ne fanno miliardi, strappano e strappano e vengono gettati via. Alla maggior parte delle persone non interessa abbastanza per richiedere una borsa migliore.

Penso che il software di qualità venga realizzato, alla fine. Alcuni di questi arrivano sul mercato prima della maggior parte dei prodotti comemercial. Chi arriva a guidare un'auto in Beta?