Presupposti di programmazione errati e di lunga durata [chiuso]

Sto facendo delle ricerche sugli errori comuni e le ipotesi sbagliate fatte da ingegneri del software junior (e forse senior).

Qual è stata la tua ipotesi più lunga che alla fine è stata corretta?

Ad esempio, ho capito male che la dimensione di un numero intero non è uno standard e invece dipende dalla lingua e dal target. Un po 'imbarazzante affermare, ma eccolo qui.

Sii franco; quale ferma convinzione avevi e all'incirca per quanto tempo hai mantenuto l'assunto? Può trattarsi di un algoritmo, un linguaggio, un concetto di programmazione, test o qualsiasi altra cosa sulla programmazione, sui linguaggi di programmazione o sull'informatica.

Per molto tempo ho ipotizzato che tutti gli altri avessero questa super-padronanza di tutti i concetti di programmazione (modelli di progettazione, l'ultimo linguaggio nuovo, complessità computazionale, espressioni lambda, tu lo chiami).

Leggere blog, Stack Overflow e libri di programmazione mi è sempre sembrato di essere dietro la curva delle cose che tutti i programmatori devono solo conoscere intuitivamente.

Mi sono reso conto nel tempo che sto effettivamente confrontando le mie conoscenze con le conoscenze collettive di molte persone, non un singolo individuo e che è un livello piuttosto alto per chiunque. La maggior parte dei programmatori nel mondo reale ha una cache di conoscenza necessaria per svolgere il proprio lavoro e ha più di alcune aree di cui sono deboli o completamente ignoranti.

Che la gente sapesse cosa voleva.

Per molto tempo ho pensato di parlare con le persone, avrebbero descritto un problema o un flusso di lavoro e lo avrei inserito nel codice e automatizzato. Viene fuori ogni volta che succede, quello che pensavano di voler non era in realtà quello che volevano.

Modifica: sono d'accordo con la maggior parte dei commenti. Questa non è una risposta tecnica e potrebbe non essere ciò che l'interrogatore stava cercando. Non si applica solo alla programmazione. Sono sicuro che non è nemmeno il mio presupposto più lungo, ma è stata la cosa più sorprendente che ho imparato in 10 anni brevi che ho fatto questo. Sono sicuro che sia stato puro ingenuo da parte mia, ma il modo in cui il mio cervello è / è stato cablato e l'insegnamento e le esperienze che ho avuto prima di entrare nel mondo degli affari mi hanno portato a credere che avrei fatto quello che ho risposto; che sarei in grado di usare codice e computer per risolvere i problemi delle persone.

Immagino che questa risposta sia simile a quella di Robin sulla comprensione / cura dei non programmatori di ciò di cui sto parlando. Si tratta di apprendere il business come un processo agile, iterativo e interattivo. Si tratta di imparare la differenza tra essere un programmatore di codice-scimmia ed essere uno sviluppatore di software. Si tratta di rendersi conto che esiste una differenza tra i due e che essere davvero bravi sul campo, non è solo sintassi e velocità di battitura.

Modifica: questa risposta è ora community-wiki per placare la gente turbata da questa risposta che mi dà rappresentante.

Che io sappia dove si trova il problema delle prestazioni senza profilazione

Che avrei dovuto avere solo un punto di uscita da una funzione / metodo.

Che i non programmatori capiscono di cosa sto parlando.

Quel software privo di bug era possibile.

Le variabili del membro privato erano private dell'istanza e non della classe.

Pensavo che la digitazione statica fosse ferma sulla tastiera.

Che puoi comprendere appieno un problema prima di iniziare a sviluppare.

Le persone intelligenti sono sempre più intelligenti di me.

Posso davvero picchiarmi quando commetto errori e spesso mi viene sgridato per autoironico. Guardavo sbalordito molti sviluppatori e spesso supponevo che poiché sapessero più di me su X , sapessero più di me.

Mentre ho continuato a fare esperienza e incontrare più persone, ho iniziato a rendermene conto spesso, mentre loro conoscono più di me in una materia particolare, non sono necessariamente più intelligenti di me / te.

Morale della storia: non sottovalutare mai ciò che puoi portare in tavola.

Per molto tempo ho pensato che la cattiva programmazione fosse qualcosa che accadeva ai margini ... che fare le cose correttamente fosse la norma. Non sono così ingenuo in questi giorni.

Ho pensato che avrei dovuto passare all'astrattismo il più possibile. Sono stato colpito alla testa con questo, a causa di troppe piccole funzionalità intrecciate.

Ora provo a mantenere le cose il più semplice e disaccoppiate possibile. Rifattorizzare per rendere qualcosa di astratto è molto più facile che prevedere come devo astrarre qualcosa.

Quindi sono passato dallo sviluppo del framework che li governa tutti, a frammenti di funzionalità che portano a termine il lavoro. Non ho mai guardato indietro, tranne quando penso al momento in cui ho ingenuamente pensato che sarei stato quello a sviluppare la prossima grande cosa.

Che le donne trovino i programmatori di computer sexy ...

Che la qualità del software porterà a maggiori vendite. A volte lo fa, ma non sempre.

Che tutte le lingue siano (principalmente) create uguali.

Per molto tempo ho pensato che il linguaggio scelto non facesse davvero la differenza nella difficoltà del processo di sviluppo e nel potenziale di successo del progetto. Questo non è assolutamente vero.

La scelta della lingua giusta per il lavoro è importante / critica come qualsiasi altra decisione sul singolo progetto che viene presa.

Che un ampio rapporto commento / codice sia una buona cosa.

Mi ci è voluto un po 'di tempo per capire che il codice dovrebbe essere auto-documentato. Certo, un commento qui e là è utile se il codice non può essere reso più chiaro o se c'è un motivo importante per cui si sta facendo qualcosa. Ma, in generale, è meglio dedicare quel tempo al commento a rinominare le variabili. È più pulito, più chiaro e i commenti non vengono "fuori sincrono" con il codice.

Quella programmazione è impossibile.

Non scherzando, ho sempre pensato che la programmazione fosse qualcosa di impossibile da imparare, e mi sono sempre tenuto lontano da esso. E quando mi sono avvicinato al codice, non sono mai riuscito a capirlo.

Poi un giorno mi sono seduto e ho letto alcuni tutorial di base per principianti, e da lì ho lavorato. E oggi lavoro come programmatore e adoro ogni minuto.

Per aggiungere, non penso che la programmazione sia facile, è una sfida e amo imparare di più e non c'è niente di più divertente che risolvere un problema di programmazione.

"On Error Resume Next" era una sorta di gestione degli errori

Quel software di programmazione richiede una solida base nella matematica superiore.

Per anni prima di iniziare a scrivere codice mi è sempre stato detto che per essere un buon programmatore devi essere bravo in algebra, geometria, calcolo, trigma avanzata, ecc.

Dieci anni dopo e ho dovuto fare una sola volta qualcosa che un alunno di terza media non poteva.

Che ottimizzazione == riscrittura in linguaggio assembly.

Quando ho capito per la prima volta assembly (proveniente da BASIC) mi è sembrato che l'unico modo per rendere il codice più veloce fosse riscriverlo in assembly. Ci sono voluti alcuni anni per rendersi conto che i compilatori possono essere molto bravi nell'ottimizzazione e soprattutto con CPU con previsione delle succursali ecc. Possono probabilmente fare un lavoro migliore di quello che un essere umano può fare in un ragionevole lasso di tempo. Inoltre, spendere del tempo per ottimizzare l'algoritmo è probabile che ti dia una vittoria migliore rispetto al passare il tempo a passare da un linguaggio di livello alto a basso. Anche quell'ottimizzazione prematura è la radice di tutti i mali ...

• Che i dirigenti dell'azienda si preoccupino della qualità del codice.
• Che meno righe sia meglio.

Direi che memorizzare l'elemento dell'anno di una data come 2 cifre era un presupposto che affliggeva un'intera generazione di sviluppatori. Il denaro investito su Y2K è stato davvero orribile.

Che qualsiasi cosa diversa dall'inserimento / ordinamento a bolle era semplicemente magia oscura.

Quell'XML sarebbe un formato di dati veramente interoperabile e leggibile dall'uomo.

Quel C ++ era in qualche modo intrinsecamente migliore di tutte le altre lingue.

Questo l'ho ricevuto da un amico un paio di anni prima di me al college. L'ho tenuto con me per un tempo imbarazzante (sto arrossendo proprio ora). Fu solo dopo aver lavorato con esso per circa 2 anni prima che potessi vedere le crepe per quello che erano.

Nessuno - e niente - è perfetto, c'è sempre spazio per migliorare.

Credevo che la creazione di programmi sarebbe esattamente come ciò che è stato insegnato in classe ... ti siedi con un gruppo di persone, vai su un problema, trovi una soluzione, ecc. Invece, il mondo reale è "Ecco il mio problema, ho bisogno di risolverlo, vai "e dieci minuti dopo ne ottieni un altro, non lasciandoti tempo reale per pianificare la tua soluzione in modo efficiente.

Ho pensato che i modelli di progettazione tradizionali fossero fantastici, quando sono stati introdotti in una classe CS. Avevo programmato circa 8 anni come hobby prima di allora, e non avevo davvero una solida comprensione di come creare buone astrazioni.

I modelli di design sembravano magici; potresti fare cose davvero ordinate. In seguito ho scoperto la programmazione funzionale (via Mozart / Oz, OCaml, in seguito Scala, Haskell e Clojure), e poi ho capito che molti dei modelli erano solo piatti o complessità aggiuntiva, perché il linguaggio non era abbastanza espressivo.

Naturalmente ci sono quasi sempre alcuni tipi di schemi, ma sono di livello superiore nei linguaggi espressivi. Ora sto facendo un po 'di codifica professionale in Java, e sento davvero il dolore quando devo usare una convenzione come modello visitatore o comando, invece di corrispondere al modello e funzioni di ordine superiore.

Per i primi anni che stavo programmando non ho capito che 1 Kbyte era tecnicamente 1024 byte, non 1000. Sono sempre stato un po 'perplesso dal fatto che le dimensioni dei miei file di dati sembravano leggermente diverse da ciò che mi aspettavo essere.

Tale condizione verifica come:

if (condition1 && condition2 && condition3)

vengono eseguiti in un ordine non specificato ...

Che la mia programmazione sarebbe più veloce e migliore se la eseguissi da sola.