Combattere l'effetto Einstellung [chiuso]

Questa è una grande domanda. E penso che non siano solo i programmatori esperti a occuparsi di questo: affrontarlo in anticipo può essere un ottimo modo per uno studente di accelerare il proprio sviluppo delle competenze.

Ci sono due lati di questo problema - uno che è cattivo e uno in realtà buono .

Cattivo: scelta della soluzione sbagliata

Ecco un esempio: in qualità di sviluppatore inesperto, potresti aver già risolto due problemi prima, problemi A e B . A questo punto, sai che ci sono problemi che non conosci, ma dato l'obiettivo della tua esperienza, molte delle cose che vedi potrebbero essere A o B .

Arriva un nuovo problema. Per te, questo nuovo problema sembra un problema A , quindi lo risolvi nel modo in cui risolvi in genere A . Qualcosa non sembra giusto e richiede più tempo e, mentre lavori, ti rendi conto che questo è un nuovo problema, C . È una variante di A che non sapevi esistesse.

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

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

Questo dovrebbe aiutarti naturalmente a risolvere questo problema. Quando hai 10 anni di esperienza, hai familiarità con i problemi A fino a Z e il tuo repertorio di soluzioni è ampio.

Buono - Efficienza

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

1. All'inizio del processo di risoluzione dei problemi, confronti il nuovo problema con tutti i problemi che conosci.
2. Tenterai di riconoscere i segni e decidi quale problema ha l'aspetto.
3. Se non è possibile effettuare una corrispondenza del 100%, uno sviluppatore esperto sopporterà il rischio di dedicare più tempo alla scoperta contro i rischi di un'esecuzione potenzialmente errata. Se il rischio di perdere tempo è troppo alto, allora vai avanti con quello che sai.

Questa non è una cosa negativa: sta utilizzando l'analisi dei rischi per scegliere efficienza oltre il 100% di accuratezza. È fatto ogni giorno e saremmo tutti legati a cose che non ci porterebbero da nessuna parte se non lo facessimo.

Quindi, per rispondere alla tua domanda:

As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?

1. Continua a cercare e catalogare nuovi problemi
2. Migliora selezionando 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 ottenere un riconoscimento migliore in quei momenti 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 giuste invece che veloci. Altrimenti, inizi lentamente a restare indietro. Ciò potrebbe comportare un minor lavoro a breve termine, ma a lungo termine che l'investimento pagherà.

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

Lo sviluppo del software, a mio avviso, non è sempre quello di trovare la soluzione assoluta * migliore *, ma di fare le cose. Quindi forse se non risolvi sempre il problema nel modo migliore, non è la fine del mondo.

Tuttavia, se ritieni che fare le cose nel modo migliore sia importante, allora penso che la migliore scommessa si svilupperebbe come parte di una squadra. Discutere sulla progettazione e fare revisioni del codice con i colleghi. Dal momento che le persone hanno normalmente sfondi e preferenze diverse, tra due o tre persone, dovresti avere diverse prese su problemi e soluzioni.

As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?

Refactor regolarmente. Il refactoring richiede che esaminiamo il codice che abbiamo scritto in passato. Possiamo usare questo tempo per visualizzare il vecchio codice con una nuova prospettiva. Fintanto che continui a seguire le principali modifiche tecnologiche, puoi apportare gli aggiornamenti come ritieni necessario.

If I have client work where I am under a time crunch or pressing issues from the problem domain or business rules, I tend to just use what I know to try to achieve a solution.

Buona. Ti stai concentrando sulle esigenze del cliente piuttosto che sui tuoi stessi obiettivi. Strada da percorrere.

This involves very ugly things like

document.getElementById

or using ASP.NET with template bound controls (DataList/Repeater) rather than figuring out how to rearchitect things with an ASP.NET MVC approach.

Non c'è niente di sbagliato in Webforms. MVC non intende sostituire Webforms. Non è nemmeno il momento di imparare una nuova tecnologia. Ricorda il triangolo. Refactor quando hai tempo. Inoltre, vedi la prima dichiarazione.

One technique I've used in the past is to have personal projects which exist simply for exploring these new technologies but this is difficult to sustain. What other approaches could be recommended?

Che cosa è difficile da sostenere? Spero che tu non mantenga progetti progettati per te da cui imparare. In tal caso, butta via i progetti di esempio. Non c'è niente di sbagliato nella creazione di progetti singoli per scopi di apprendimento. Questa è una cosa molto buona. Vedi la prima affermazione.

Provato e vero! = Cattivo. L'effetto "Einstellung" è preso un po 'fuori contesto qui. I test si riferiscono alle persone che ottimizzano "aprendo un barattolo". I metodi di "apertura di un barattolo" 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 sta avendo una pratica effettiva per farlo. Edward De Bono ha scritto molti libri su pensiero generale e argomenti correlati.

Ma in ogni punto decisionale, ciò che conta di più è la valutazione e l'adozione del rischio. Waltzing with Bears di De Marco e Lister è uno dei migliori libri sull'argomento quando applicato allo sviluppo di software.

Le Programmazione estrema e altre agile metodologie propongono di procedere e sperimentare le nuove soluzioni (a punta) come una questione di routine. Faccio esperimenti con diverse tecnologie durante le startup di progetto, e questo mi ha salvato diverse volte dal cadere per l'hyped a favore del vero e provato, ea volte per scoprire un nuovo gioiello tecnologico.

Come squadra, puoi cambiare il gruppo riconoscendo la spaventosa sfarzosità. Io uso spesso nuove persone per questo, perché non sono rotti 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 la visione di qualcun altro potrebbe essere meno prevenuta e quindi prendere in considerazione una classifica almeno tanto importante quanto la tua opinione (forse anche di più).

Sei sicuro che non è solo quello che metterei al posto di document.getElementById è davvero una perdita di tempo, non importa quanto ti accontenti di farlo?

Modifica: mi sono appena reso conto che entrambi i tuoi esempi riguardano gli strumenti, perché potresti considerare la possibilità di cambiare i tuoi strumenti per essere la pietra miliare del tuo sviluppo di abilità. Un buon programmatore ha bisogno di poco più di un linguaggio completo di Turing per lavorare con le sue meraviglie, non è per dire che gli strumenti non sono importanti, ma quello che stai già usando non è esattamente un set di strumenti. Se passare da uno strumento a un altro è il più grande progresso che si può pensare, allora potrebbe essere che si è sostanzialmente fermati nelle aree meno quantificabili.

As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?

Auto-consapevolezza

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.

Apprendi e applica

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