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

Quindi, quando si sceglie quale lingua utilizzare per un progetto, in un mondo ideale viene scelta la lingua perché è lo strumento giusto per il lavoro. Tuttavia, spesso preferisco usare una lingua in cui parlo fluentemente piuttosto che in una lingua che dovrei imparare o in cui sto solo conversando. Naturalmente la fluidità della lingua implica anche la conoscenza delle librerie applicabili nella lingua. Solo perché mi piace molto un linguaggio abbastanza generico come Java non significa che dovrei sempre usarlo, ma allo stesso tempo non significa che dovrei lanciare qualcosa come Perl ogni volta che c'è dell'elaborazione del testo da fare. Come si trova l'equilibrio qui?

Wow, questa è una domanda MOLTO difficile se portata fuori dal mondo della teoria e nel mondo della produzione.

In teoria

Semplice. Usa sempre lo strumento migliore per il lavoro e impara cosa devi fare.

In pratica

Non solo c'è la domanda della tua padronanza, ma ci sono molte altre domande di business che devono essere poste prima di poter rispondere a questa domanda:

• Costo per l'acquisto della "strumentazione corretta"
• Costo per sostenere questo - le persone devono essere addestrate
• Costo della curva di apprendimento
• Costi di integrazione con altri prodotti (ora e nel futuro)
• ... eccetera

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

Ora non sto dicendo di non scegliere lo strumento giusto: assicurati solo che lo strumento corretto sia in grado di superare anche 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 meglio informata.

Penso che la familiarità non abbia abbastanza credito. La tua familiarità influenza molto bene quale sia lo strumento giusto. Devi usare lo strumento per completare il tuo progetto. Inoltre, usare qualcosa che ti piace può senza dubbio superare le carenze della sua forma fisica perché sarai più entusiasta di lavorare e otterrai risultati migliori.

http://headrush.typepad.com/creating_passionate_users/2006/08/when_the_best_t.html

Questo non è davvero risolvibile se non come una domanda commerciale. Tuttavia, molte domande commerciali vengono fatte solo guardando ai numeri a breve termine, il che è un errore con cose come questa.

Il mio approccio generale:

1. Se è una cosa piccola o di breve durata, scrivila sempre negli strumenti familiari.
2. Se è una cosa importante a lungo termine, guarda il compromesso costi-benefici dell'apprendimento di un nuovo strumento.
3. Se non sei sicuro, trattalo come una cosa a breve termine fino a quando non avrai la prova che è una cosa a lungo termine. Quindi vai e guarda di nuovo la decisione.

Tre cose da tenere a mente quando si pensa ai costi e ai benefici: Uno, le persone che vanno di fretta tendono a cambiare brevemente il futuro. Due, i costi di manutenzione sono la parte principale dei costi per qualsiasi sistema di successo. Tre, ai bravi sviluppatori piace imparare le cose e rendere felici i tuoi sviluppatori è un buon investimento a lungo termine.

Ottima domanda! Come ha detto whatsisname nella sua risposta, "alla familiarità non viene dato credito sufficiente". Uno strumento diverso, un quadro diverso, un linguaggio diverso potrebbe essere molto meglio di quello a cui sei abituato a usare, e saresti ancora molto meno produttivo con esso per la prima volta mentre imparavi le corde.

Lavoro da alcuni anni come sviluppatore ASP.NET in agenzie digitali in cui abbiamo un mix di grandi progetti, piccoli progetti, progetti ristretti, progetti ben integrati, ecc. Cosa cerchiamo di fare per espandere le nostre competenze, è alla ricerca di "obiettivi morbidi", progetti più piccoli che non abbiano scadenze dolorosamente rigide e rigide e li utilizzino 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 loro, li ho usati per la prima volta in un simile progetto.

Se riesci a cogliere le tue opportunità in quel modo, allora, si spera, 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 possono scegliere tra Java e Ruby.

Ma se la scadenza è breve e solida e il progetto è importante, ti consiglierei di seguire gli strumenti familiari. Qualcosa di diverso potrebbe essere più adatto, ma in progetti del genere, si tratta di rischio .

Questo dipende da alcune cose:

1. Quanto sei bravo a imparare nuove lingue o strumenti.

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

2. Come lingua / strumento indipendente rendi il tuo ambiente di lavoro.

Se il flusso di lavoro dipende in larga misura dagli strumenti, le barriere all'apprendimento di lingue diverse sono più elevate. Se sei legato a un particolare IDE, passare da una lingua all'altra implica molto di più che apprendere una lingua, poiché la modifica del testo ti frustrerà sicuramente.

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

3. Realtà aziendale

L'apprendimento di nuovi strumenti / lingue richiede tempo. Quel tempo ha un costo. Ma quel costo ha il potenziale per essere un investimento che ripaga di più della spesa iniziale. Inoltre, una soluzione sgraziata richiede di solito più tempo per essere implementata ed è 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ò quali strumenti SONO adatti al problema. Ho anche investito in un ambiente per soddisfare un approccio generalista, imparando a usare vim come il mio editor preferito.

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

Se c'è una nuova lingua di cui sei curioso e te (e gli affari) te lo puoi permettere, perché non concederti un paio di settimane o un mese per esplorarla?

È così che ho imparato il rubino. Il mio partner di programmazione aveva 7 anni di esperienza con Java. Ho avuto 11 anni di esperienza con Java. Nessuno di noi sapeva nulla del rubino, solo che volevamo provarlo.

Ho convinto lui e il resto dell'azienda a provare Ruby per un mese (questo sarebbe stato un progetto di 6-8 mesi). Nel peggiore dei casi, ricominciare da capo usando Java.

Fortunatamente dopo una settimana siamo stati catturati, quindi è andato tutto bene. Forse puoi provare qualcosa di simile? Vedi se riesci a costruire qualcosa da zero in un'altra lingua, ma chiarendo al business perché lo stai facendo, e almeno altrettanto importante, quale piano B è nel caso in cui l'esperimento fallisca.

Ovviamente non esiste una risposta unica a questa domanda che si applichi a tutte le situazioni. Ma ecco un aspetto che non credo sia stato ancora menzionato. Se sei uno sviluppatore, dovresti anche tenere conto della tua commerciabilità. Se la lingua X viene scelta per il tuo progetto, come sarà il tuo curriculum? Potrebbe essere una buona idea scegliere una lingua che non hai familiarità in modo da avere un motivo per impararla, espandere i tuoi orizzonti intellettuali e rendere le tue abilità più interessanti 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, per esempio, Prolog sarebbe uno strumento giusto per il lavoro per me, data la mia completa ignoranza della lingua.

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

In quasi tutti gli scenari della vita reale, dato un problema hai un tempo molto limitato per risolverlo. Non credo che tu possa davvero imparare una nuova lingua in pochissimo tempo . Imparare una lingua significa in realtà leggere libri, leggere 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 ciò porterebbe a un codice terribile e probabilmente staresti meglio scrivendo un codice migliore in una lingua che conosci probabilmente in tempi molto più brevi.

Nonostante i meriti del proverbio "strumento giusto per il lavoro", le lingue più popolari sono in realtà scopi generali. Possono avere punti di forza in alcune aree e non essere buoni come gli altri in altre aree, ma possono svolgere la maggior parte dei lavori. Non conoscere una lingua praticamente significa che lo strumento non è disponibile per te.

Non sto dicendo solo imparare una (o anche due o tre) lingue e usarle per tutti i progetti e non imparare nient'altro. È importante imparare altre lingue, acquisire più strumenti da aggiungere alla tua cassetta degli attrezzi. 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.