it-swarm.it

Gestire la frustrazione quando le cose non funzionano

Hai mai provato a implementare qualcosa di semplice ma per qualche strana ragione non funziona.

Quindi provi una possibile soluzione ma poi qualcos'altro non funziona. Continui a provare soluzioni alternative diverse ma ogni volta che qualcosa di diverso non funziona.

Ogni volta che ti avvicini di un passo, ottieni anche uno (o più) un passo in più dalla risoluzione di questo problema e ora sono passate 3 ore quando questo avrebbe dovuto impiegarti 10 minuti. E ancora non è risolto.

Non c'è nessuno nella tua azienda che possa aiutarti e stai per mettere il pugno sullo schermo.


A questo punto sei così frustrato che non riesci più a pensare chiaramente al problema. Cosa dovresti fare a questo punto? O cosa puoi fare per evitare di raggiungere questo punto?

63
JD Isaacks

Sebbene questo sia un vero problema, non è specifico per la programmazione. Tuttavia, è IMHO così importante che merita un posto su questo forum.

I miei suggerimenti: fare una pausa. Fai una passeggiata, medita, dormi, fai attività fisica * - fai qualcosa di completamente diverso da consenti al tuo cervello di rilassarsi ed uscire dalla routine mentale, lasciando che il tuo subconscio lavori sul problema in pace. Di solito fornisce risultati sorprendentemente veloci - deve solo farti sapere. Ma mentre la tua mente cosciente sta ripetendo disperatamente gli stessi cicli di pensieri più e più volte, non sarà in grado di ascoltare nient'altro.

cosa puoi fare per evitare di raggiungere questo punto?

Le tecniche di rilassamento e consapevolezza sono la chiave per superare le reazioni allo stress e consentire alla mente di concentrarsi chiaramente. E la pratica di questi paga davvero. Quando qualcuno ha esperienza in questi, può già notare che il livello di stress aumenta prima che la frustrazione possa prendere il sopravvento. Quindi si può interrompere il ciclo dei pensieri ad es. facendo alcuni respiri profondi o facendo un paio di minuti di pratica di rilassamento. Questo può essere tutto ciò che è necessario a quel punto.

* bacia il tuo partner, accarezza il tuo animale domestico - suggerimenti di mia moglie :-)

70
Péter Török

sono passate 3 ore quando questo avrebbe dovuto impiegarti 10 minuti.

La parola magica è dovrebbe. Colpiscilo dal tuo vocabolario.

Chi ha detto che dovrebbe richiedere 10 minuti? Chi in particolare? Qual era la base fattuale per la loro richiesta?

Se l'hai già fatto 3 volte prima e ogni volta che eri vicino a 10 minuti, hai una base razionale per un dovrebbe.

Se non l'hai mai fatto prima, dicendo dovrebbe ti stai solo preparando per il fallimento. Dovresti smettere di usare dovrebbe oggi.

35
S.Lott

Trova qualcuno da usare come cassa di risonanza

Anche se nessuno ha esperienza su ciò su cui stai lavorando, è una buona idea parlare di queste cose frequentemente. Solo il semplice atto di usare qualcuno come cassa di risonanza può far girare la tua mente. Ti ritroverai a pensare a nuove cose da provare. Allevierà anche lo stress a sfogare un po 'e potenzialmente fare nuove amicizie. È anche salutare in generale per il team sentirsi a proprio agio nel condividere e commiserare tra loro per generare un'atmosfera orientata al team per risolvere questo tipo di problemi.

22
Doug T.

Allontanati un po 'e fai qualcos'altro. Dormi bene la notte e torna al problema al mattino.

Inoltre, non ti picchiare. La tua stima di dieci minuti non è chiaramente corretta e ciò accade sempre.

9
jprete

Ho qualche passo quando raggiungo questo punto. Normalmente riesco a trovare una soluzione se mi prendo il tempo di fare un passo indietro e riflettere.

Passaggio 1: allontanati dal problema e schiarisci la testa. Torna quando non sei frustrato e puoi guardarlo con una mente fresca.

Passaggio 2: torna al codice e verifica se hai perso qualcosa. Chiedi a qualcuno di venire e di essere un secondo paio di occhi se non riesci proprio a capirlo o fare la coda.

Passaggio 3: rimuovere il codice dall'equazione. Qual è il problema che stai cercando di risolvere? Scrivilo su un pezzo di carta o lavagna. Parla del problema con qualcuno per ottenere le sue opinioni sul problema e sulla soluzione.

Passaggio 4: contatta la community per vedere se hanno una soluzione o se qualcun altro ha mai colpito lo stesso muro.

Fondamentalmente, questi possono essere riassunti come "Smettere di hackerare e allontanarsi dal codice".

9
Tyanna

Vorrei porre una domanda qui e chiedere alla community di aiutarti a risolverlo. Meno stressante in questo modo.

2
Bernard

Ho un nome speciale per questo tipo di situazione: epica battaglia di programmazione.

Se non ho avuto almeno uno epica battaglia di programmazione con un linguaggio o uno strumento di programmazione specifico e ho risolto il problema, non posso dire a me stesso che posso usare tale linguaggio o strumento di programmazione.

Quindi c'è la mia soluzione: mentalizzalo come una lotta e una prova di coraggio e resistenza. Se non riesco a risolvere il problema, allora "vivo per combattere un altro giorno".

Può sembrare un po 'ridicolo, ma sarà più divertente e gratificante pensarci in questi termini (come se fosse una sorta di gioco che devi vincere) invece di soffrire fino in fondo perché devi affrontare fatto che non sai tutto.

1
dukeofgaming

Ho un diverso tipo di soluzione - SLEEPING !!

Quando sei frustrato da un problema, non puoi facilmente uscirne. Quindi è meglio se sei così stanco che cerchi di risolvere il problema e poi ti addormenti.

Al risveglio avrai una sensazione fresca e di nuovo puoi pensare chiaramente al problema. Lo faccio a volte.

1
ruben

Trovare qualcosa per aiutare a ricostruire un po 'di fiducia è ciò che tendo a fare quando raggiungo questo punto. Potrebbe trattarsi di risolvere un enigma di Sudoku o Kenken, fare qualche semplice compito amministrativo insensato come compilare il mio foglio di lavoro o uscire a fare una passeggiata. La chiave qui è per me avere un senso di realizzazione in qualunque cosa questa piccola distrazione laterale sia di aiutarmi a pomparmi abbastanza da tornare sul cavallo e cavalcare nel selvaggio blu laggiù, per mescolare lì alcune metafore.

Per evitare di diventare così cattivo, probabilmente suggerirei di avere qualche strategia di roba di time-boxing in modo che se credi che qualcosa duri 10 minuti ed è improvvisamente un'ora dopo senza molti progressi, mi fermerei e avrei una piccola pausa piuttosto che cercare di continuare a sbattere la testa contro il muro.

1
JB King

Beh ... penso che tu abbia bisogno di una nuova carriera o di una serie completamente nuova di aspettative. Anche se certamente non frequente, impiegare 3, 4, 8, 10 o 40 ore per fare quello che inizialmente pensavi fosse un lavoro di 10 minuti non è certamente raro nel settore del software. Sono sicuro che la maggior parte degli sviluppatori che lavorano su qualcosa di anche di moderata complessità hanno avuto attività di 2 giorni trasformate in attività di 1 mese una volta che hanno approfondito e compreso il problema.

Parte dell'essere un buon sviluppatore implica essere pazienti, altrimenti il ​​computer vincerà e finirai per incorporare una sorta di hack rapido che a malapena sembra funzionare ma inevitabilmente romperà qualcosa a cui non hai pensato. Se ritardi minori ti causano così tanto stress, probabilmente non dovresti essere in questa linea di lavoro.

0
Dunk

Due suggerimenti:

  1. La persona più intelligente che conosco, che ha due dottorati di ricerca e ha il titolo di lavoro "Research Fellow", in una piccola azienda privata, dice questo

    Se ci hai pensato per 15 minuti e non hai la risposta, stai sbagliando.

    Smetti di pensarci.

    Fai un pisolino. (fare una passeggiata o qualcosa del genere)

    La risposta sarà lì quando ti svegli.

  2. Ottieni il libro di David J Agan "Debugging". Probabilmente ti insegnerà di più sul debug in modo che quando le cose non funzionano, puoi eseguirne il debug rapidamente.

0
Tim Williscroft

Ogni volta che mi trovo di fronte a qualcosa che non funziona, ricordo sempre questa citazione:

Quando sei all'inferno, continua a camminare perché è la cosa migliore che puoi fare a quel punto.

Fai una pausa, cerca di rinfrescarti e concentrati sul problema con un nuovo livello di energia.

0
Rachel

facendo eco alle raccomandazioni degli altri:

  • questa situazione è quasi sempre qualcosa di banale che tu semplicemente non vedi; fare una pausa
  • un altro paio di occhi o anche solo spiegare il problema al tuo gatto può aiutare

e aggiungendo:

  • riesamina i tuoi presupposti, in particolare quelli non dichiarati; è probabile che abbai abbaiando l'albero sbagliato
  • invertire la situazione: supponiamo che l'attuale comportamento sia il risultato desiderato, quindi cosa dovresti fare al codice per farlo accadere?
  • scrivere un codice di prova (asserzioni o registrazioni, o punti di interruzione condizionali - mantienilo semplice) per verificare i tuoi presupposti lungo il percorso di esecuzione
0
Steven A. Lowe

La fatica o la mancanza di sonno non sono mai un problema per me. Sono più frustrato dalla mancanza di organizzazione nel settore nel suo insieme e, nel complesso, dai bassi standard che ci siamo prefissati. Ecco cinque cose che mi frustrano:

  1. API complicate nella progettazione. È come imparare un linguaggio di programmazione completamente nuovo. In effetti alcune API sono molto più difficili da imparare rispetto all'apprendimento di nuovi linguaggi di programmazione. Ammiro la tua intelligenza, ma avresti potuto risparmiarmi tempo inserendo la documentazione che mi serviva un dottorato in ingegneria del software o informatica per capirlo.

  2. Mancanza di buona documentazione. Non riesco mai a superare il fatto che così tanti progettisti di API passano molto tempo a creare un'API solo per rilasciarla con una documentazione minima. Grazie, ma come posso usarlo? Cosa fare in questa situazione? eccetera.

  3. Implementazioni proprietarie. Alcune implementazioni proprietarie vanno bene, ma se esistono degli standard, per il bene dell'umanità, si prega di seguire tali standard. Niente di più frustrante di passare il tempo a chiedersi perché qualcosa non funziona solo per scoprire l'implementazione non segue gli standard normali.

  4. Ambienti sandbox/Restrizioni. Ok, forse questo aiuta a tenere fuori le persone cattive, ma secondo me le restrizioni su ciò che un programmatore può fare limita solo la creatività e il progresso tecnologico. Molte delle grandi idee che ho avuto sono state spazzate via dopo aver scoperto che non mi è permesso fare qualcosa. L'industria della programmazione è fatta apposta per sfornare applicazioni quotidiane, non software innovativi innovativi. Quindi, se decidi di diventare un programmatore, stai davvero scegliendo di essere un grugnito moderno, a meno che tu non voglia diventare un accademico solitario.

  5. Discussioni moderne Le persone oggi discutono ancora sulla bruttezza della parentesi LISP, sul merito della pulizia dei Python o su come alcune lingue come Cobol o Fortran si stiano estinguendo, ecc. Ecc. Davvero persone? Questo è ciò di cui discutiamo? Parliamo di parallelismo, o modi migliori per progettare sistemi più sicuri, o in che modo la programmazione logica può migliorare la nostra vita. Smettiamola di pensare come programmatori e cominciamo a pensare come designer del mondo di domani.

Quindi personalmente non programmo più molto a causa di queste frustrazioni. Fino a quando l'industria non deciderà di voler fare di più che creare il prossimo Facebook o reinventare il word processor che ho impostato. Lascio a voi ragazzi. Sinceramente senza offesa, è un buon prezzo.

0
annoying_squid

A volte, è meglio non solo provare a risolvere un problema. Prenditi del tempo e scrivi in ​​pseudo codice cosa devi fare. So che c'è una pressione per fare le cose il più velocemente possibile, ma da quello che ho visto, quello stile di codifica porta al tipo di situazione che descrivi. Se qualcuno scrive un codice che funzionerà solo con un piccolo insieme di condizioni e che cambierà, il codice si romperà o farà cose inaspettate.

Inoltre (odio ammettere che i miei professori avevano ragione su questo ...), la documentazione e i test unitari aiutano. Ciò renderebbe più semplice sapere quale parte di una sezione di codice verrà pubblicata, dato l'insieme di input. Quindi, sarebbe più facile vedere quale effetto provocherà un cambiamento nell'input di quelle sezioni.

0
John