Combattere l'effetto Einstellung [chiuso]

L' effetto Einstellung si riferisce alla "predisposizione di una persona a risolvere un determinato problema in un modo specifico anche se esistono metodi" migliori "o più appropriati per risolvere il problema".

Come programmatore con una discreta esperienza, come si può combattere questa tendenza ad affrontare sempre la soluzione dei problemi da percorsi "provati e veri" dell'esperienza passata?

Per fare due esempi molto concreti, ho sviluppato applicazioni Web per un lungo periodo, abbastanza a lungo da prevedere un ampio uso di framework Javascript (ad esempio jQuery) e migliori framework di applicazioni Web (ad esempio ASP.NET MVC). Se ho un lavoro client in cui mi trovo in una crisi di tempo o che preme problemi dal dominio del problema o dalle regole aziendali, tendo a usare solo ciò che so per cercare di ottenere una soluzione. Ciò comporta cose molto brutte come

document.getElementById 

o usando ASP.NET con i controlli associati al modello (DataList / Repeater) piuttosto che capire come rearchitect le cose con un approccio ASP.NET MVC.

Una tecnica che ho usato in passato è avere progetti personali che esistono semplicemente per esplorare queste nuove tecnologie, ma questo è difficile da sostenere. Quali altri approcci potrebbero essere raccomandati?

Questa è un'ottima domanda E penso che non siano solo i programmatori senior che si imbattono in questo: affrontarlo presto può essere un ottimo modo per uno studente per accelerare lo sviluppo delle proprie abilità.

Ci sono due lati di questo problema: uno che è cattivo e uno che è effettivamente buono .

Cattivo: scegliere la soluzione sbagliata

Ecco un esempio - come uno sviluppatore inesperto, si può avere solo realmente risolto due problemi prima, problemi di A e B . A questo punto, sai che ci sono problemi che non conosci, ma data la lente della propria esperienza, un sacco di ciò che si vede sembra che potrebbe essere A o B .

Arriva un nuovo problema. A voi, questo nuovo aspetto del problema come problema A , in modo da risolvere nel modo che di solito risolve A . Qualcosa non si sente bene, e ci vuole più tempo, e come si lavora si finisce per rendersi conto che questo è un problema nuovo, C . È una variante di A che non sapevi esistesse.

Quindi cosa fai per non commettere di nuovo questo errore? Due cose:

1. Scopri cosa c'era di diverso in questo nuovo problema. Scopri quali approcci potrebbero aver funzionato diversamente e perché.
2. Catalogare questo problema e passare alla risoluzione di nuovi problemi.

Questo dovrebbe aiutarti a risolvere naturalmente questo problema. Quando hai 10 anni di esperienza, conosci i problemi dalla A alla Z e il tuo repertorio di soluzioni è ampio.

Buono - Efficienza

Nel mondo reale, con scadenze e risorse limitate, usare ciò che sai non è sempre male:

1. All'inizio del processo di risoluzione dei problemi, si confronta il nuovo problema con tutti i problemi che si conoscono.
2. Tenterai di riconoscere i segni e deciderai quale problema sembra avere.
3. Se non è possibile effettuare una corrispondenza al 100%, uno sviluppatore esperto soppeserà il rischio di dedicare più tempo alla scoperta rispetto ai rischi di un'esecuzione eventualmente errata. Se il rischio di perdere tempo è troppo alto, allora vai avanti con quello che sai.

Non è una brutta cosa: utilizza l'analisi del rischio per scegliere l' efficienza con una precisione del 100%. Viene fatto ogni giorno e saremmo tutti legati a cose che non ci portano da nessuna parte se non lo facessimo.

Quindi, per rispondere alla tua domanda:

Come programmatore con una discreta esperienza, come si può combattere questa tendenza ad affrontare sempre la soluzione dei problemi da percorsi "provati e veri" dell'esperienza passata?

1. Continua a cercare e catalogare nuovi problemi
2. Arriva meglio a scegliere la soluzione giusta per il problema; invece di sapere quale soluzione, sapere perché è giusto.
3. Esercitati e affina le tue capacità decisionali. A volte l'efficienza è la scelta giusta e migliorare nel riconoscere quei tempi porterà a vantaggi misurabili nel mondo reale.

Metti da parte il 20% del tuo tempo di lavoro per migliorare le tue abilità / fare le cose nel modo giusto invece che velocemente. Altrimenti, inizi lentamente a rimanere indietro. Ciò potrebbe comportare una riduzione del lavoro a breve termine, ma a lungo termine l'investimento ripagherà.

La parte difficile sta resistendo alla pressione per tagliare gli angoli su questo. Fino a quando l'abitudine non è radicata, non tagliare quell'angolo. Una volta che sei nel punto in cui consideri questo investimento nelle tue abilità "normale", puoi scegliere di correre di tanto in tanto in un progetto. Nel frattempo, non considerare questa volta opzionale e forma le tue stime di conseguenza.

Sviluppo Software, a mio avviso, non è sempre di trovare l' assoluta * * soluzione migliore, ma fare le cose. Quindi forse se non risolvi sempre il problema nel modo migliore, questa non è la fine del mondo.

Tuttavia, se ritieni che fare le cose nel modo migliore sia importante, penso che la scommessa migliore sarebbe quella di svilupparsi come parte di una squadra. Discutere del design ed eseguire revisioni del codice con i colleghi. Poiché le persone hanno normalmente background e preferenze diverse, tra due o tre persone, dovresti avere diversi approcci su problemi e soluzioni.

Come programmatore con una discreta esperienza, come si può combattere questa tendenza ad affrontare sempre la soluzione dei problemi da percorsi "provati e veri" dell'esperienza passata?

Refactor regolarmente. Il refactoring richiede che esaminiamo il codice che abbiamo scritto in passato. Possiamo usare questa volta per visualizzare il vecchio codice con una nuova prospettiva. Finché si tiene il passo con i principali cambiamenti tecnologici, è possibile effettuare gli aggiornamenti che si ritiene necessari.

Se ho un lavoro client in cui mi trovo in una crisi di tempo o che preme problemi dal dominio del problema o dalle regole aziendali, tendo a usare solo ciò che so per cercare di ottenere una soluzione.

Buona. Ti stai concentrando sulle esigenze del cliente piuttosto che sui tuoi obiettivi. Ben fatto.

Ciò comporta cose molto brutte come

document.getElementById

o usando ASP.NET con i controlli associati al modello (DataList / Repeater) piuttosto che capire come rearchitect le cose con un approccio ASP.NET MVC.

Non c'è niente di sbagliato in Webforms. MVC non intende sostituire i moduli Web. Non è nemmeno il momento di imparare una nuova tecnologia. Ricorda il triangolo. Rifattore quando hai tempo. Vedi anche la prima affermazione.

Una tecnica che ho usato in passato è avere progetti personali che esistono semplicemente per esplorare queste nuove tecnologie, ma questo è difficile da sostenere. Quali altri approcci potrebbero essere raccomandati?

Cosa è difficile da sostenere? Spero che tu non stia mantenendo progetti progettati per imparare da te. In tal caso, getta via i progetti di esempio. Non c'è niente di sbagliato nel creare progetti unici a fini di apprendimento. Questa è un'ottima cosa Vedi la prima affermazione.

Provato e vero! = Cattivo. L '"Einstellung Effect" è un po' fuori contesto qui. I test si riferiscono a persone che ottimizzano "l'apertura di un barattolo". I metodi di "apertura di un vaso" delle persone sono limitati e non migliorano nel tempo (escludendo qualsiasi materiale di fantascienza). Nel software, il modo migliore per "raggiungere l'attività X" cambia nel tempo.

Qualcosa che aiuta a pensare fuori dagli schemi è una pratica pratica per farlo. Edward De Bono ha scritto molti libri sul pensiero laterale e argomenti correlati.

Ma in ogni dato punto di decisione, ciò che conta di più è valutare e abbracciare il rischio. Waltzing with Bears di De Marco e Lister è uno dei migliori libri sull'argomento quando applicato allo sviluppo del software.

La programmazione estrema e altre metodologie agili suggeriscono che si dovrebbe semplicemente andare avanti e sperimentare le nuove soluzioni (picco) come una questione di routine. Faccio esperimenti con diverse tecnologie durante l'avvio del progetto, e questo mi ha salvato diverse volte dall'innamorarmi in favore del vero e provato, e talvolta alla scoperta di un nuovo gioiello tecnologico.

Come squadra, puoi cambiare il gruppo riconoscendo la bellezza del modello. Uso spesso nuove persone per questo, perché non sono irritate nel modo normale di fare le cose. Questa è in qualche modo una risposta manageriale - ma anche come ingegnere esperto, penso che tu possa capire che l'opinione di qualcun altro potrebbe essere meno distorta e quindi considerare con una classifica di almeno il peso della tua opinione (forse anche di più).

Sei sicuro che non sia solo quello che vorresti mettere al posto di document.getElementById è davvero una perdita di tempo, non importa quanto sei accomodato?

Modifica: mi sono appena reso conto che entrambi i tuoi esempi riguardano strumenti, questo potrebbe essere dovuto al fatto che pensi di cambiare i tuoi strumenti come la pietra miliare più grande dello sviluppo delle tue abilità. Un buon programmatore ha bisogno di poco più di un linguaggio completo di Turing per fare le sue meraviglie, ciò non significa che gli strumenti non siano importanti, ma quello che stai già usando non è esattamente un set di strumenti di fondo. Se passare da uno strumento a un altro è il progresso più grande che ti viene in mente, allora potresti essere sostanzialmente bloccato nelle aree meno quantificabili.

Come programmatore con una discreta esperienza, come si può combattere questa tendenza ad affrontare sempre la soluzione dei problemi da percorsi "provati e veri" dell'esperienza passata?

Autocoscienza

Sii consapevole delle tue tendenze, delle tue debolezze e dei tuoi punti di forza.

Decisioni consapevoli

Rendi le tue decisioni esplicite e consapevoli. Non saltare a fare qualcosa senza pensare consapevolmente a come lo farai.

Impara e applica

Continua ad apprendere nuove tecniche e considera dove possono essere applicate. Quando ti imbatti in una situazione in cui può essere applicato, fai un'analisi costi-benefici. A volte il vantaggio di provare qualcosa di nuovo supera il vantaggio di una soluzione nota.