Equilibrio tra "strumento giusto per il lavoro" e familiarità [chiuso]

Wow, questa è una domanda MOLTO difficile quando viene tolto dal mondo della teoria e nel mondo della produzione.

In Theory

Semplice. Utilizza sempre lo strumento migliore per il lavoro e impara semplicemente cosa è necessario.

In pratica

Non solo la questione della tua scioltezza ci sono una serie di altre domande aziendali che devono essere poste prima di poter rispondere a questa domanda:

• Costo dell'acquisto di "tooling corretto"
• Costo del supporto: le persone devono essere addestrate
• Costo della curva di apprendimento
• Costo di integrazione con altri prodotti (ora e in futuro)
• ... ecc.

Al di fuori della teoria ci sono serie implicazioni per la tua scelta tecnologica.

Ora non sto dicendo di non scegliere lo strumento corretto, ma assicurati che lo strumento corretto sia in grado di andare in pari con le sue implicazioni sui costi.

Se si tratta di un progetto personale, utilizza sempre lo strumento "corretto", quindi quando ti trovi di fronte a questa decisione nel contesto aziendale puoi effettuare una chiamata più informata.

Penso che la familiarità non abbia abbastanza credito. La tua familiarità influenza molto bene qual è lo strumento giusto. Devi usare lo strumento per completare il tuo progetto. Inoltre, l'uso di qualcosa che ti piace può senza dubbio superare qualsiasi carenza nella sua forma fisica, perché sarai più entusiasta di portare a termine il lavoro e otterrai risultati migliori.

link

Questo non è realmente risolvibile tranne che come una domanda aziendale. Tuttavia, vengono fatte molte domande commerciali solo guardando i numeri a breve termine, che è un errore con cose come questa.

Il mio approccio generale:

1. Se si tratta di una cosa piccola o di breve durata, scrivilo sempre negli strumenti familiari.
2. Se si tratta di una grande cosa a lungo termine, guarda al compromesso costi-benefici dell'apprendimento di un nuovo strumento.
3. Se non sei sicuro, trattalo come una cosa a breve termine finché non avrai la prova che è una cosa a lungo termine. Poi vai e guarda di nuovo la decisione.

Tre cose da tenere a mente quando si pensa a costi e benefici: uno, le persone in fretta tendono a cambiare il futuro. Due, i costi di manutenzione sono la parte del leone dei costi per qualsiasi sistema di successo. Tre, bravi sviluppatori amano imparare e tenere felici i tuoi sviluppatori è un buon investimento a lungo termine.

Ottima domanda! Come ha detto whatsisname nella sua risposta, "la familiarità non viene data abbastanza credito". Uno strumento diverso, una struttura diversa, un linguaggio diverso potrebbe essere un lotto migliore di quello che sei abituato a usare, e saresti ancora molto meno produttivo con la prima volta mentre imparavi le corde .

Ho lavorato per alcuni anni come sviluppatore ASP.NET in agenzie digitali in cui abbiamo un mix di grandi progetti, piccoli progetti, progetti serrati, progetti ben imbottiti, ecc. Cosa proviamo a fare, ad espandere le nostre competenze, sono alla ricerca di "obiettivi soft", progetti più piccoli che non hanno scadenze dolorose e rigide, e li usano come un'opportunità per utilizzare nuove tecnologie che potrebbero essere superiori. .NET 2.0, 3.5, 4.0, ASP.NET MVC, Linq to SQL, Entity Framework: tutti, ho utilizzato per la prima volta in un progetto di questo tipo.

Se riesci a cogliere le tue opportunità in questo modo, allora spero che sarai pronto con una suite più ampia di opzioni per scegliere lo strumento giusto senza soffrire di mancanza di familiarità. Proprio come nell'esempio di Julio: hanno trovato un obiettivo in cui potevano aggiungere Ruby al loro repertorio, e ora andando avanti possono scegliere tra Java e Ruby.

Ma se la scadenza è breve e solida e il progetto è importante, ti consiglierei di attenersi agli strumenti familiari. Qualcosa di diverso potrebbe essere più adatto, ma in progetti come questo, si tratta di rischio .

Questo dipende da alcune cose:

1. Quanto sei bravo ad apprendere nuove lingue o strumenti.

Se sei uno studio veloce, la barriera all'apprendimento di nuove lingue o strumenti è più bassa. Questo ti dà l'opportunità di aggiungere un altro strumento alla casella degli strumenti.

2. In che modo la lingua e lo strumento sono indipendenti dal tuo ambiente di lavoro.

Se il tuo flusso di lavoro dipende molto dallo strumento, le barriere all'apprendimento di lingue diverse sono più alte. Se sei legato a un particolare IDE, passare da una lingua all'altra implica molto più dell'apprendimento di una lingua, poiché la modifica del testo ti renderà sicuramente frustrante.

Qualcuno che usa vim o emacs non ha questo problema. Tutto quello che devono fare è imparare la nuova lingua.

3. Realtà aziendale

Imparare nuovi strumenti / lingue richiede tempo. Quella volta ha un costo. Ma quel costo ha il potenziale per essere un investimento che paga più della spesa iniziale. Inoltre, una soluzione sgraziata di solito impiegherà più tempo per essere implementata e sarà più difficile da mantenere. Se è qualcosa di più grande di un piccolo progetto, e gli strumenti nella mia cassetta degli attrezzi esistente non sembrano adattarsi al problema, cercherò su quali strumenti ADATTA al problema. Ho anche investito in un ambiente per soddisfare un approccio generalista, imparando a usare vim come editor preferito.

Un'altra cosa: qual è la distanza più breve tra due punti? Se qualcun altro ha scritto qualcosa che fa quasi ciò che voglio fare, di solito è più veloce modificarlo in base alle mie esigenze.

Se c'è una nuova lingua che ti incuriosisce e tu (e l'azienda) puoi permetterti, perché non concederti un paio di settimane a un mese per esplorarlo?

Questo è il modo in cui ho imparato il rubino. Il mio compagno di codice aveva 7 anni di esperienza con Java. Ho avuto 11 anni di esperienza in Java. Nessuno di noi sapeva nulla di rubino, solo che volevamo provarlo.

Ho convinto lui e il resto dell'azienda a provare il rubino per un mese (questo sarebbe stato un progetto di 6-8 mesi). Nel peggiore dei casi, avremmo avviato questa volta utilizzando Java.

Fortunatamente dopo una settimana siamo stati catturati, quindi è andato tutto bene. Forse puoi provare qualcosa di simile? Verifica se è possibile creare qualcosa da zero in un altro linguaggio, ma chiarendo al business perché lo stai facendo e, cosa meno importante, quale sia il piano B nel caso in cui l'esperimento fallisca.

Ovviamente non esiste un'unica risposta a questa domanda che si applichi a tutte le situazioni. Ma ecco un aspetto che non credo sia già stato menzionato. Se sei uno sviluppatore, dovresti anche tener conto della tua commerciabilità. Se viene scelta la lingua X per il tuo progetto, come sarà il tuo curriculum? Potrebbe essere una buona idea scegliere una lingua che non ti è familiare, in modo da avere una ragione per impararla, ampliare i tuoi orizzonti intellettuali e rendere le tue competenze più attraenti per i futuri datori di lavoro.

Direi che la familiarità con una lingua è anche un aspetto di "essere uno strumento giusto per un lavoro". Non riesco a immaginare una situazione in cui il Prolog sarebbe lo strumento giusto per il mio lavoro, data la mia totale ignoranza della lingua.

La mia versione è quella di "usare lo strumento giusto a mia disposizione" per il lavoro. Essere "disponibili" significa che sono in grado di usarlo, non solo quello che posso acquistare / ottenere il compilatore e // o il runtime.

In quasi ogni scenario di vita reale, dato un problema, hai un tempo molto limitato per risolverlo. Non credo che tu possa veramente imparare una nuova lingua in un tempo molto breve . Imparare una lingua significa effettivamente leggere libri, esaminare il codice di altre persone, capire come funziona e la filosofia che sta dietro. Si potrebbe semplicemente leggere un tutorial dal web (che è perfettamente buono come punto di partenza), e ottenere l'hacking. Ma questo porterebbe a un codice terribile e probabilmente staresti meglio scrivendo un codice migliore in una lingua che conosci in un tempo molto più breve.

Nonostante i pregi del proverbio "strumento giusto per il lavoro", le lingue più diffuse sono in realtà di uso generale. Possono avere punti di forza in certe aree e non essere bravi come altri in altre aree, ma possono ottenere la maggior parte dei lavori. Non conoscere una lingua significa praticamente che lo strumento non è disponibile per te.

Non sto dicendo di imparare solo una (o anche due o tre) lingue e usarle per tutti i progetti e non imparare nient'altro. È importante imparare altre lingue, per acquisire più strumenti da aggiungere alla tua casella degli strumenti. Ma di fronte a un problema, è meglio attenersi agli strumenti che conosci piuttosto che aumentare le tue preoccupazioni utilizzando tecnologie non familiari. Ma continua ad imparare altre lingue in modo che la prossima volta la scelta sia più semplice.