L'uso di nuove tecniche danneggia la produttività? [chiuso]

Spesso è rischioso provare nuove cose. A volte ci troviamo nei guai perché tendiamo a fare due cose:

1. Sovrascrivi quanto sia utile la cosa cool / new / snazzy. Vediamo qualche esempio interessante, qualche codice lanciato online. Molto bello, pensiamo. Molto bello! In X posso eseguire l'operazione Y dieci volte più velocemente. È chiaramente superiore. Non vediamo ancora tutte le "incognite sconosciute". Non siamo stati inciampati dai problemi che i venditori della nuova cosa omettono. Non abbiamo abbastanza esperienza nella nuova cosa per vedere le mine terrestri in attesa.

2. Sottovaluta l'utilità degli strumenti / framework / software / elementi esistenti. Spesso non eravamo presenti quando il sistema attuale è stato inizialmente creato. Non apprezziamo i delicati compromessi che sono stati fatti. È facile giocare a quarterback di lunedì mattina su un sistema esistente, ma funziona . Probabilmente ha un sacco di stranezze a causa di compromessi molto specifici tra mantenerlo funzionante, funzionante e performante. Sì certo è strano. Forse la cosa più importante è che il team è un esperto dell'attuale stranezza e sa come aggirare la stranezza. Conoscono le mine antiuomo e le trappole e le insidie da evitare. Infatti è proprio perché vediamo tutte le verruche nel modo attuale di fare cose che siamo anche interessati a giocare con cose nuove.

Ma non riuscire a provare cose nuove e agire in modo troppo conservativo è probabilmente ancora più pericoloso. Certo, dobbiamo procedere con cautela, ma se non capiamo come costruire la migliore trappola per topi, i nostri concorrenti un po 'più disposti a provare qualcosa di nuovo arriveranno e prenderanno a calci i mozziconi! Agire in modo conservatore e non riuscire a evolversi può comportare inevitabilmente una catastrofe, soprattutto in un mercato competitivo.

Quindi sì, dobbiamo bilanciare il mantenimento e la spedizione della cosa attuale con un certo livello di sperimentazione giocosa / educativa con nuovi modi per risolvere i problemi tenendo presente che molti di questi nuovi modi sono senza sbocco mentre altri possono ripagare. IMO Questa è una buona ragione per cui molte aziende hanno il 20% di tempo per giocare con cose nuove. Sanno un sacco di volte che non funzionano, ma molte delle idee che escono dal 20% di tempo diventano gangbusters. Senza tempo per giocare e sperimentare, puoi facilmente ristagnare come azienda e davvero rovinarti.

Succede sempre . L'ho detto in altri post, ma più che mai, non sei nel business dello sviluppo di codice elegante, sei nel business della spedizione di un prodotto. Pertanto, ti verrà difficile trovare un manager disposto ad allocare n ore affinché tu possa correggere qualcosa che non sia rotto e in realtà (alla fine della giornata) non migliora notevolmente l'esperienza dell'utente finale . Sarai altrettanto difficile trovare un manager disposto a destinare n ore alla ricerca (senza un obiettivo finale chiaro) diverso da "probabilmente c'è qualcosa che è meglio là fuori" rispetto a quello che è stato fatto.

Detto questo, se nella tua applicazione ci sono dei colli di bottiglia che hai scoperto utilizzando strumenti di profilazione e simili e puoi chiaramente quantificare l'aumento di esperienza utente previsto che la soluzione avrebbe portato, allora dovresti (abbastanza facilmente) avere tempo per fai del lavoro di R & D per ottimizzarli usando tecniche che puoi trovare da varie fonti.

Penso che parte di esso dipenda dall'esperienza e dalla conoscenza più approfondita su come risolvere con successo alcuni problemi.

Quando sei nuovo, anche tutti i problemi sono nuovi e devi cercare come eseguirli. Ma come hai risolto lo stesso tipo di problema, il bisogno di ricerca va ripetuto come sai una soluzione di successo a quello.

Quindi tendi solo a ricercare i nuovi problemi o quelli in cui il vecchio provato e vero non funziona più (essendo stato deprecato) o sta causando un problema di prestazioni o di insuccesso. Quando inizi a comprendere un sistema complesso in modo più approfondito, sai che non hai il tempo di usare realisticamente le nuove tecniche ogni volta che arrivano e hai scoperto attraverso l'esperienza che molto spesso la nuova tecnica non vive fino al suo hype e crea più problemi di quanti ne abbia risolti. Così diventi meno incline a usare nuovi strumenti e tecniche quando non ne hai davvero bisogno per risolvere il problema.

Ma meno incline non dovrebbe significare che smetti di imparare o non usi mai una nuova tecnica, solo che sei più giudizioso su quando sono appropriati.

Ecco alcuni dettagli:

1. Ci sono scadenze : i programmatori dovrebbero prima avere tutti i dettagli necessari disponibili degli strumenti che sta usando. Leggere un sito web, trovare qualcosa di nuovo e poi usarlo nell'ambiente di produzione è un grande no-no. Non hai abbastanza esperienza con lo strumento e, cosa ancora più importante, non hai il tempo necessario per iniziare a imparare qualcosa di nuovo. Se vuoi qualcosa di nuovo, impara almeno un anno o mezzo prima di usarlo.
2. Assicurati di conoscerlo correttamente prima di utilizzarlo : alcuni nuovi e interessanti strumenti possono essere divertenti da usare, ma cercare su Google e poi usarli senza appropriarli correttamente può essere molto brutto. Non hai abbastanza esperienza con esso. Se hai bisogno di google per capirlo significa che non lo sai abbastanza bene da risolverlo quando si rompe metà del sistema.
3. L'utilizzo delle cose più nuove non lo fa correttamente : le nuove cose non sono dimostrate tecnologiche. L'anno prossimo la tecnologia probabilmente è completamente sparita, tu sei l'unica al mondo a usarla ancora. Tutti gli altri hanno notato che non funziona. Ci vuole un duro lavoro per evitare il più recente proiettile d'argento, ma ne vale la pena.
4. Concentrati sulle tecniche che sono la tua conoscenza principale : ogni programmatore conosce solo una piccola parte dell'intera conoscenza della programmazione disponibile nel mondo. La parte in cui il programmatore è abbastanza comodo usarlo è ancora più piccola. La parte che funziona effettivamente è ancora più piccola. Usa solo la conoscenza che hai appreso correttamente e sai che funziona. Questo ti rende programmatore più veloce e produce un codice migliore.
5. Non ottimizzarlo all'infinito : il codice perfetto è un buon obiettivo, ma ciò non significa che prima devi scrivere alcune cazzate e poi modificarlo all'infinito per migliorarlo in modo incrementale. Scrivilo perfettamente la prima volta usando tutta la buona conoscenza che hai. Credi in te stesso. Non fidarti del mondo. Nessun altro sa esattamente le stesse cose che fai tu. La loro opinione non ha importanza. Sei il programmatore, devi farlo funzionare. Il mondo non può farlo per te. Una volta finito, ferma. Non toccarlo finché qualcuno non si lamenta.
6. Trascorri del tempo per imparare nuove cose : tutti hanno bisogno di imparare continuamente nuove cose. Da ciò dipende il nostro futuro. Basta rifiutare di usarlo! Impara nuove cose, ma non usarle finché non sei sicuro che funzioni effettivamente. Avrai la possibilità di usarlo l'anno prossimo, una volta che sarà collaudato. O l'hai appena dimenticato, come tutti gli altri: solo le cose buone restano ...
7. Non perdere le cose buone : una volta che hai costruito con successo grandi sistemi e risolto tutti i problemi, e hai appreso alcune belle tecniche, la cosa peggiore che puoi fare è scaricare questa conoscenza e andare avanti qualcosa di nuovo. Sai già come funziona, quali problemi ci sono e come risolverli. Buttarlo via è solo una perdita di tempo.
8. Resta al passo con la nuova tecnologia : uno dei nuovi sistemi avrà successo. Ha qualcosa di fondamentalmente migliore di qualsiasi altra cosa sul mercato. Semplicemente non sai qual è il proiettile d'argento. Se non riesci a trovarlo in tempo, la tua conoscenza sarà superata. Il mondo può farti perdere tutte le cose buone rimuovendo l'accesso ai vecchi sistemi.

Sì, è successo così. Di solito devi fare analisi del rischio su quanto tempo avrà bisogno di imparare la nuova tecnica e puoi recuperare e usare una tecnica più vecchia nel caso in cui la nuova tecnica non sia all'altezza delle aspettative. Preferisco apprendere nuove tecniche quando posso, ma quando la pressione è accesa e non posso permettermi di sprecare tempo a provare cose nuove che potrebbero fallire, rimango con i metodi provati e veri.

In generale, trovo che il momento migliore per imparare nuove tecniche sia all'inizio di un nuovo progetto. Di solito non c'è troppa pressione e se trovi qualcosa di nuovo che funzioni bene, puoi facilmente integrarlo con il resto del progetto, andando avanti. Il peggiore tempo di provare e apprendere nuove cose è l'ultimo paio di frenetiche settimane prima di una grande distribuzione.

Sì, le novità fanno male alla produttività

Sì, certo. Anche nel migliore dei casi, le nuove cose richiedono un tempo aggiuntivo perché non sono familiari. Spesso può costare molto più tempo.

No, nuove tecniche possono migliorare la produttività

Qualsiasi nuova tecnica che ti permetta di esprimere più facilmente la soluzione migliorerà la tua produttività. Può essere semplice come passare da condizioni di if-elseif di grandi dimensioni a una tabella di distribuzione.

Sì, può danneggiare la produttività. Alla mia ex è stato chiesto di fare un lavoro di elaborazione dei dati noioso una volta, così ha deciso che sarebbe stato meglio scrivere un programma lungo per gestire i dati e poi eseguirlo - il che avrebbe risolto il problema in pochi secondi.

Ci sono voluti una settimana per scriverlo, ovviamente, ma il problema è stato risolto in pochi secondi.

Penso che lo stesso valga per la tua domanda: sì, puoi aumentare la tua produttività imparando cose nuove, ma sarebbe comunque meglio applicare le tue conoscenze esistenti al compito e, nel complesso, farlo in modo più rapido. A chi importa trovare e imparare una nuova biblioteca, se puoi scrivere la tua in meno tempo.

Non dimenticarlo pure, spesso ottenerlo in modo decente con gli strumenti esistenti è una soluzione migliore rispetto a inserire nuovi elementi. Ogni volta che aggiungi nuovi, aumenti la superficie di manutenzione che è necessaria, il che a sua volta rallenta tutti gli altri (e può rendere il tuo codice abbastanza disordinato - penso agli strati di "nuova" tecnologia che sono passati in eredità nel tempo ma sono ancora nel nostro codice che rende le cose orribili. Guardando indietro, sarebbe stato meglio usare solo i vecchi modi C invece di aggiungere tutto ciò che è COM e tutto ciò che è VB e tutto ciò che è .NET e ora spalando anche l'HTML in esso)