Quali sono gli errori non programmabili che un programmatore dovrebbe evitare? [chiuso]

7

Le persone commettono errori, anche nella vita reale ... Che dovremmo, noi programmatori geniali, evitare?

    
posta Tom Wijsman 18.09.2010 - 23:00
fonte

17 risposte

31

Scopri che ciò che costituisce "Un grado accettabile di precisione" per te è "Fastidioso dannato accaparramento" per la maggior parte del mondo.

    
risposta data 09.09.2010 - 20:00
fonte
29

Scopri come ascoltare le persone (o gli utenti del tuo prodotto).

Troppi programmatori sono veloci per passare a "questo utente è un idiota" invece di ascoltare ciò che la persona o l'utente ha da dire. C'è qualcosa da imparare da tutti in questo mondo.

    
risposta data 09.09.2010 - 19:51
fonte
17

Il più grande errore non di programmazione che abbia mai visto:

Non impara a comunicare in modo efficace, sia oralmente che per iscritto.

Prendi due programmatori con pari capacità di programmazione, uno con buone capacità di comunicazione e uno senza. Il primo andrà più lontano, più veloce ogni. singolo. tempo.

    
risposta data 09.09.2010 - 22:53
fonte
14

Risparmia le persone normali da qualsiasi dettaglio tecnico non necessario. A loro non interessa.

E non sbavare sui tuoi colleghi di sesso femminile.

    
risposta data 09.09.2010 - 20:39
fonte
10

Ergonomia. Ottieni un vero professionista per valutare la tua workstation e consiglia il posizionamento di monitor, tastiera e sedia.

Estrai le mani, i polsi e le braccia delicatamente prima di iniziare una lunga sessione di tastiera. Presta attenzione anche alla tua postura.

Ho iniziato a soffrire di dolore al polso nel 1998 e ho dovuto cambiare alcune delle mie abitudini. Ad oggi indosso un paio di bretelle mentre lavoro al computer (utilizzo IMAK SmartGlove).

Non giocare troppi videogiochi, questo aumenta le ore che passi a torturare mani e polsi.

Inoltre, bere molta acqua ed esercitarsi regolarmente. Smaltisci le bibite.

    
risposta data 13.09.2010 - 16:51
fonte
9

Non apprendere tanto sul dominio aziendale, sugli utenti, sul contenuto per cui stai scrivendo il software.

    
risposta data 13.09.2010 - 16:31
fonte
8

Non mangiare mai niente più grande della tua testa

    
risposta data 09.09.2010 - 19:52
fonte
8

I programmatori e gli sviluppatori Geeky dovrebbero evitare di dire loro cosa pensano veramente di project manager, tester del controllo qualità, DBA e altri non programmatori.

In sostanza sii carino .

    
risposta data 09.09.2010 - 19:54
fonte
6

Trattare tutti gli altri che incontri come un programmatore. Devi capire che non tutti quelli che ti stanno intorno hanno a cuore i computer quanto te. È una pillola dura da inghiottire, ma sfortunatamente è molto reale.

    
risposta data 09.09.2010 - 19:58
fonte
4

Comprendi che se sei in un ambiente di sviluppo a cascata, i documenti sui requisiti, i BRD, ecc. sono, in generale, fiabe. I requisiti e i progetti software nel loro insieme sono in costante stato di flusso ed è estremamente raro avere una serie di requisiti che non cambiano durante l'intero ciclo di vita del progetto. Gli uomini d'affari sono pignoli e amano cambiare idea molto. Detto questo, la maggior parte dei negozi di software operano ancora con una mentalità a cascata. C'è un movimento in crescita che supporta le metodologie Agile (il cambiamento è inevitabile e dovrebbe essere accettato), ma personalmente non ho mai visto né sentito parlare di un moderno progetto di sviluppo aziendale che avesse requisiti, pratiche, ecc. Concreti per tutta la sua vita. La chiave del take-away è che le cose cambiano quasi sempre. Nella mia esperienza, il grado probabile in cui le cose cambiano è direttamente proporzionale alla lunghezza del progetto ... che è anche in uno stato costante di flusso.

    
risposta data 19.09.2010 - 01:30
fonte
3

"Funziona sulla mia macchina!" è una scusa che non può che andare così lontano. Assicurati di considerare più ambienti imparziali. La tua macchina di sviluppo, sfortunatamente, è ben costruita per far funzionare qualsiasi programma su di essa!

    
risposta data 02.11.2011 - 19:51
fonte
2

Impara ad ammettere ciò che non sai. Se non conosci la risposta, dillo. Non cercare di inventare qualcosa solo per poter dare una risposta. Ciò ti porterà nei guai a lungo termine.

    
risposta data 19.09.2010 - 01:12
fonte
2

Pensando che sarai abbastanza ricompensato per i tuoi sforzi. In altre parole, potresti pensare che sarai ricompensato per aver lavorato sodo e aver fatto un buon codice e che sarai punito per aver speso tutto il giorno su stackexchange.

Ma non è questo il caso. In molti casi, lavorerai con / per persone clueless che semplicemente indovineranno quanto lavori, quale sia il tuo valore e ti condiscenderanno.

    
risposta data 02.11.2011 - 21:20
fonte
1

Impara a stimare.

    
risposta data 09.09.2010 - 19:55
fonte
1

Un "errore di programmazione" che vedo le persone fare (in particolare il tizio nello specchio) è "stubbing your toe".

Con questo, voglio dire, eccitarsi eccessivamente per un piccolo errore, come lo sfregamento del dito del piede. Quindi prendendo una reazione negativa eccessiva. La frustrazione alla fine le palle di neve e un sacco di piccoli problemi finiscono per causare l'enorme dolore al cuore e dolore. Quando qualcosa va storto, fai una breve pausa, respira e riprendi.

  • Rimani bloccato su un bug, fai una pausa.
  • L'app funziona su 3 server, ma non il 4, fai una pausa di 5-15 minuti.
  • L'IDE si arresta in modo casuale, fai una pausa.
  • I bambini non smetteranno di rimbalzare sui muri, fare una pausa. (magari ridurre anche lo zucchero)

Nel primo decennio circa della mia carriera, mi è successo tutto il tempo. Ero il mio peggior nemico il più delle volte. Sono ancora vittima di questa trappola, ma molto meno frequentemente.

    
risposta data 02.11.2011 - 20:14
fonte
1

"Assumption is the mother of all f**kups."

- Under Siege 2: Dark Territory (1995)

    
risposta data 02.11.2011 - 20:30
fonte
1

Evita di essere eccessivamente drammatico quando si verificano errori. Un errore non è la fine del mondo. Solo perché un compito è durato un po 'più di quanto inizialmente stimato non è la cosa peggiore possibile. Il racconto del miracolo di Norden sarebbe un esempio in cui, mentre qualcuno aveva una buona idea e buone intenzioni nel creare un nuovo dispositivo, ci possono essere varie altre cose che accadono per ridurre l'efficacia della nuova cosa creata. Sicuramente un racconto di ammonimento che spera di ottenere dietro di lui la salsa di spaghetti a partire da febbraio 2004.

    
risposta data 02.11.2011 - 21:24
fonte

Leggi altre domande sui tag