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

Sembra che man mano che l'esperienza con l'insieme specifico di strumenti con cui devi lavorare cresce, l'incentivo a provare nuove cose si indebolisce.

Quando ero nuovo in questo lavoro di programmazione, provare cose nuove, fare ricerche online, mi rendeva più produttivo, perché spesso trovavo un modo (o una libreria) che rendeva il compito più semplice che il framework del codice fosse già in atto. Quindi usare qualcosa di nuovo - sia per me che nel contesto della base di codice fornita - mi ha reso più produttivo.

Ora ho notato che ci sono sempre più casi in cui, per un dato problema, so che probabilmente esiste una soluzione migliore "là fuori", e trovandola migliorerebbe - presumibilmente - il codice. Tuttavia, data la mia ormai intima conoscenza della base di codice, è di gran lunga più facile usare gli strumenti non ottimali che abbiamo e ottenere una soluzione (compresi i test) in esecuzione piuttosto che trovare qualcosa di nuovo e "migliore" e "migliorare" la base di codice.

Quindi c'è questa tensione: "fallo correttamente" vs. "fai il lavoro decentemente ".

È qualcosa che succede a molti sviluppatori? È un problema specifico noto? (Dopo tutto, è un vero problema?) Ha effettivamente a che fare con livelli crescenti di esperienza?

Oh, e nota: mi piace ancora il mio lavoro e mi piace mantenerlo. È solo che sembra il - sempre interessante! - la parte di ricerca diventa più piccola quando apprendo la base di codice e i set di problemi che affrontiamo con la nostra app.

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

1. Sottovalutare quanto utile sia la cosa bella / nuova / elegante. Vediamo alcuni esempi interessanti, alcuni codici lanciati online. Pensiamo molto bene. Molto bello! In XI posso eseguire l'attività 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 antiuomo in attesa lungo la strada.

2. Sottovalutare quanto sono utili gli strumenti / il framework / il software / le cose esistenti. Spesso non eravamo presenti al momento della costruzione del sistema attuale. Non apprezziamo i delicati compromessi che sono stati fatti. È facile giocare a quarterback del lunedì mattina su un sistema esistente, ma funziona . Probabilmente ha ottenuto un sacco di stranezze a causa di compromessi molto specifici tra il mantenerlo mantenibile, il lavoro e le prestazioni buone. Sì certo, è strano. Forse soprattutto, il team è un esperto della stranezza attuale e sa come aggirare la stranezza. Conoscono le mine antiuomo e le trappole e le insidie ​​da evitare. In realtà è proprio perché vediamo tutte le verruche nel modo attuale di fare cose che siamo persino 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 camminare con attenzione, ma se non riusciamo a capire come costruire la migliore trappola per topi, i nostri concorrenti un po 'più disposti a provare qualcosa di nuovo arriveranno e lanceranno calci! Agire in modo conservativo e non riuscire ad evolversi può comportare inevitabile rovina soprattutto in un mercato competitivo.

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

Succede sempre . L'ho detto in altri post, ma il più delle volte non sei nel business dello sviluppo di un codice elegante, sei nel business della spedizione di un prodotto. Pertanto, ti verrà difficile trovare un manager che è disposto a dedicare nore affinché tu possa sistemare qualcosa che non è rotto e davvero (alla fine della giornata) non migliora notevolmente l'esperienza dell'utente finale. Sarà altrettanto difficile trovare un manager disposto a dedicare nore alla ricerca (senza un chiaro obiettivo finale) diverso da "probabilmente c'è qualcosa là fuori che è meglio" di quello che viene fatto.

Detto questo, se nella tua applicazione ci sono strozzature che hai scoperto usando strumenti di profilazione e simili e puoi chiaramente quantificare il miglioramento dell'esperienza utente prevista che porterebbe a correggerli, allora dovresti (abbastanza facilmente) avere tempo per fare un po 'di ricerca e sviluppo lavorare per ottimizzarli usando tecniche che puoi trovare da varie fonti.

Penso che in parte dipenda dall'esperienza e da una conoscenza più approfondita di come risolvere con successo alcuni problemi.

Quando sei nuovo, anche tutti i problemi sono nuovi e devi cercare come risolverli. Ma poiché hai risolto ripetutamente lo stesso tipo di problema, la necessità di ricercare diminuisce quando conosci una soluzione di successo a quella.

Quindi si tende 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 guasti. 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 si presentano e hai scoperto attraverso l'esperienza che molte volte la nuova tecnica non vive fino al suo hype e crea più problemi di quanti ne abbia risolti. In questo modo diventi meno propenso a utilizzare nuovi strumenti e tecniche quando in realtà non ti servono 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 quando sono appropriati.

Ecco alcuni dettagli:

1. Ci sono delle scadenze : i programmatori dovrebbero avere in anticipo tutti i dettagli necessari disponibili degli strumenti che sta usando. Leggere un sito Web, trovare nuove cose interessanti e quindi utilizzarlo 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, imparalo sei mesi o un anno prima di usarlo.
2. Assicurati di conoscerlo correttamente prima di usarlo : alcuni nuovi e simpatici strumenti possono essere divertenti da usare, ma cercare su google soluzioni e poi usarle senza impararle correttamente può essere molto male. Non hai abbastanza esperienza con esso. Se hai bisogno di cercarlo su Google per capirlo, significa che non lo conosci abbastanza bene da risolverlo quando si rompe metà del sistema.
3. L'uso delle cose più recenti non lo fa correttamente : le nuove cose non sono una tecnologia collaudata. L'anno prossimo probabilmente la tecnologia sarà completamente sparita, sarai l'unico al mondo a usarla ancora. Tutti gli altri hanno notato che semplicemente non funziona. Ci vuole un duro lavoro per evitare il nuovissimo proiettile d'argento, ma ne vale la pena.
4. Concentrati sulle tecniche che sono le tue conoscenze di base : ogni programmatore conosce solo una piccola parte dell'intera conoscenza di programmazione disponibile nel mondo. La parte in cui il programmatore è abbastanza comodo da usarlo è ancora più piccola. La parte che funziona effettivamente è ancora più piccola. Usa solo le conoscenze che hai appreso correttamente e sai che funziona. Ciò rende il programmatore più veloce e consente di ottenere un codice migliore.
5. Non modificarlo all'infinito : il codice perfetto è un buon obiettivo, ma ciò non significa che prima scrivi qualche schifezza e poi lo modifichi all'infinito per renderlo progressivamente migliore. Scrivilo perfettamente la prima volta usando tutte le buone conoscenze che hai. Credi in te stesso. Non fidarti del mondo. Nessun altro conosce esattamente le stesse cose che fai. La loro opinione non ha importanza. Sei il programmatore, devi farlo funzionare. Il mondo non può farlo per te. Una volta fatto, fermati. Non toccarlo fino a quando qualcuno non si lamenta.
6. Trascorrere del tempo per imparare cose nuove : tutti hanno bisogno di imparare continuamente cose nuove. Da ciò dipende il nostro futuro. Rifiuta solo di usarlo! Scopri nuove cose, ma non usarle fino a quando non sei sicuro che funzioni davvero. Avrai la possibilità di usarlo il prossimo anno, una volta che è stata dimostrata la tecnologia. O te ne sei semplicemente dimenticato, come tutti gli altri - rimane solo la roba buona ...
7. Non perdere le cose buone : una volta che hai costruito con successo grandi sistemi e risolto tutti i problemi in loro, e imparato alcune belle tecniche, la cosa peggiore che puoi fare è semplicemente scaricare quella conoscenza e cercare 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 le nuove tecnologie : uno dei nuovi sistemi avrà successo. Ha qualcosa di fondamentalmente migliore di qualsiasi altra cosa sul mercato. Semplicemente non sai quale sia il proiettile d'argento. Se non riesci a trovarlo in tempo, le tue conoscenze saranno obsolete. Il mondo può farti perdere tutte le cose buone rimuovendo l'accesso ai vecchi sistemi.

Sì, l'ho fatto succedere. Di solito è necessario eseguire un'analisi dei rischi su quanto tempo sarà necessario per apprendere la nuova tecnica e è possibile recuperare e utilizzare una tecnica più vecchia nel caso in cui la nuova tecnica non riesca a soddisfare le aspettative. Preferisco imparare nuove tecniche quando posso, ma quando la pressione è attiva e non posso permettermi di passare il tempo a provare cose nuove che potrebbero fallire, mi attengo a metodi collaudati.

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

Sì, nuove cose hanno danneggiato la produttività

Sì, naturalmente. Anche nel migliore dei casi, le cose nuove richiedono tempo aggiuntivo perché non hanno familiarità. Spesso può costare molto più tempo.

No, le nuove tecniche possono migliorare la produttività

Qualsiasi nuova tecnica che ti consente di esprimere più facilmente la soluzione migliorerà la tua produttività. Questo può essere semplice come passare da grandi if-elseifcondizioni a una tabella di spedizione.

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

Le ci è voluto 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 saresti comunque meglio applicare le tue conoscenze esistenti all'attività e nel complesso farlo più velocemente. Chi se ne frega di trovare e apprendere una nuova biblioteca, se è possibile scrivere la propria in meno tempo.

Non dimenticare anche che spesso farlo decentemente con gli strumenti esistenti è una soluzione migliore rispetto a inserire le nuove cose. Ogni volta che aggiungi nuove cose, aumenti la superficie di manutenzione richiesta, che a sua volta rallenta tutti gli altri (e può rendi il tuo codice piuttosto disordinato - Penso ai livelli della "nuova" tecnologia che sono passati nel tempo ma sono ancora nel nostro codice a rendere le cose orribili. Guardando indietro, sarebbe stato meglio usare solo i vecchi modi C invece di aggiungere tutto quel COM e tutto quel VB e tutto quel .NET e ora spalando anche HTML in esso)