Trattare con Fanboys [chiuso]

Probabilmente abbiamo incontrato qualcuno come questo, quello sviluppatore che sa solo che la sua lingua è l'unica vera lingua e non sta zitta. Come tratti una persona come questa? Non voglio offendere nessuno (soprattutto perché il fanboy nel mio posto di lavoro è lo sviluppatore senior). Ma voglio essere in grado di usare la mia scelta del linguaggio di scripting quando devo scrivere uno script usa e getta che non arriva mai al repository e nessun altro deve sapere che esiste.

Pensieri che dovevo affrontare questo:

1. Ridi - "Ah ah sì forse la lingua X è un po 'più semplice, immagino di essere un masochista!"
2. Vai con esso - Preferirei davvero evitarlo poiché non posso permettermi il calo di produttività associato alla scelta di una nuova lingua.
3. Nascondi la mia lingua - Diventa un programmatore di armadi e nascondi il mio monitor ogni volta che scrivo o automatizzo qualcosa.

Cosa suggeriresti per questa situazione?

Poche cose stanno saltando fuori dalla domanda.

• È davvero una sceneggiatura usa e getta? Se lo è, è strano che si stia discutendo.
• Sei sicuro che lo script usa e getta rimarrà com'è? Un sacco di roba di produzione è stata una sceneggiatura usa e getta in qualche momento.
• Stai per riscrivere lo script se è promosso e necessita di integrazione nel sistema?
• La scelta della lingua è puramente sintattica o è una lingua di un'altra sfera?

In un certo senso capisco la parte del fan-boy, perché da un lato mi comporto un po 'come un fan-boy a volte, proteggendo le mie poche lingue di scelta. E ho anche avuto a che fare con altri fan-boy che cercano di portare nuove cose.

La mia opinione su questa situazione è così:

• Se è una nuova lingua, appartiene a un cestino.
• Se è un linguaggio testato nel settore, può essere utilizzato se è specializzato per l'attività.
• Se è un linguaggio molto impopolare, appartiene a un bidone della spazzatura, anche se è super cool e super veloce.

È perché nessuno sa come scrivere software sicuro e veloce in una lingua sconosciuta, e ha tutti i trucchi che gli sviluppatori devono imparare. La stupida sceneggiatura dovrà essere supportata per oltre 20 anni o riscritta. In 20 anni, almeno 50 sviluppatori cambiano in un negozio medio. Se ognuno scrive pochi script elaborati in una nuova lingua, sono necessari 50 runtime linguistici, 50 competenze diverse nel team e la base di codice ha un codice errato in 50 lingue. E alcune delle lingue non sono più supportate su Windows o Linux. E ha bisogno di quel server personalizzato di 10 anni senza patch, senza parti di ricambio disponibili, 24/7.

Inoltre, nessuno vuole davvero supportare lingue morte come VB, Silverlight, D, ecc., Quando la base di codice probabilmente sopravviverà alla lingua stessa.

Decide cosa usi in base alla politica aziendale? Appellagli il tuo caso; se decide ancora di non farlo, stai zitto e fai il tuo lavoro con gli strumenti che il tuo capo dice che dovresti usare.

Ci lavori , non ci giochi. Alla fine è fuori dalle tue mani.

Anche se non è il tuo capo, prenderei in considerazione tutti gli angoli qui. Ti piacerebbe se conoscesse Fortran e un giorno ereditassi tutto il suo codice. Dovresti imparare una nuova lingua da zero al volo , che è terribilmente stressante. Ora immagina il suo lato, potresti scrivere i tuoi script usando Cobol e potrebbe non conoscere Cobol.

Usa qualcosa che la maggior parte della tua squadra sa.

"2. Vai con esso"

Questa è l'unica risposta ragionevole. Hai una grande opportunità qui.

• Usa i commenti del programmatore senior per incoraggiare la tua azienda a pagare per tempo e / o un corso e / o certificazione per imparare la nuova lingua. Scenario peggiore: la certificazione e la lingua miglioreranno entrambi il tuo curriculum, potresti ricevere una buona raccomandazione per essere un giocatore di squadra e puoi ridere fino a un lavoro migliore altrove.

• Ho acquisito preziose informazioni sulla programmazione da ogni lingua che ho imparato. Anche il linguaggio meno pratico ( tosse XSLT tosse ) aveva il suo punto debole ed era pieno zeppo di interessanti opportunità di apprendimento (e ha pagato le mie bollette per diversi anni). L'apprendimento costante è uno dei grandi vantaggi di essere un programmatore.

• Tutti i progetti interessanti usano probabilmente la lingua preferita dello sviluppatore senior. Conoscere quella lingua ti mette nel pool di talenti che possono lavorare su quei progetti.

• Qualcuno probabilmente ti sta pagando per fare un certo lavoro in un certo modo. Qualsiasi altra risposta è probabilmente insubordinazione ed è probabile che finisca male.

Lo sviluppatore / architetto senior sceglie normalmente la lingua principale utilizzata in un negozio e garantisce che tutti la utilizzino. In questo modo, un'azienda crea una base di conoscenza in determinate tecnologie in modo che un dipendente (te) possa prendere le vacanze e qualcun altro può raccogliere il codice e correggerlo mentre non ci sei. Inoltre, la società può attirare talenti di formazione pertinenti e il reparto risorse umane saprà quali parole chiave cercare sui curriculum.

Imparando la sua lingua e utilizzandola per il lavoro, accumuli il capitale politico di cui hai bisogno per difendere efficacemente la tua lingua preferita. Molte aziende hanno un linguaggio di infrastruttura ufficiale e un linguaggio di scripting ufficiale per i report. Prepara un elenco di pro e contro che mostra dove eccelle la sua lingua e dove fa la tua, anche dove ognuno non è all'altezza. È necessario mantenere questo elenco nel contesto di un'applicazione specifica, ad esempio i report che si stanno scrivendo. Pianifica un momento con lui per mostrargli l'elenco in privato e rispettosamente e discuterne con lui. Annota le sue obiezioni, cercale dopo l'incontro e, se hai buone argomentazioni contrarie, organizza una riunione di follow-up.

In bocca al lupo!

Mostra che in un contesto specifico, un'altra lingua è una scelta più pragmatica.

Se la persona è appassionata di C ++ e stai lavorando a un progetto di applicazione web, non sarebbe troppo difficile. Allo stesso modo, alcuni contesti sono molto inclini alla programmazione funzionale e l'uso di un linguaggio non funzionale non sarebbe molto saggio.

Appunti:

• Evita le situazioni in cui la tua e la sua lingua preferita sono molto simili.

  Ad esempio, difficilmente immaginerei un contesto in cui Java sarebbe "migliore" di C #, o C #, "migliore" di Java.

• Ricorda che la scelta di una lingua è molto spesso soggettiva ed è spiegata più dalla precedente esperienza di uno sviluppatore piuttosto che da alcuni elementi basati sull'evidenza.

  Ad esempio, se mi viene chiesto di fare una domanda relativa al settore finanziario, utilizzerei comunque C # anziché Haskell, anche se trovo Haskell più appropriato e davvero eccitante. Il motivo di questa scelta è che ho anni di esperienza con C #, ma quando si tratta di Haskell, ho letto solo alcuni tutorial e non l'ho mai usato in modo professionale.

La risposta è 2) Vai con esso.

1. L'unico modo per zittire il fanboy è diventare fluente (in una certa misura) nella sua lingua preferita.
2. La perdita di produttività non è un problema. Stai facendo come richiesto dal tuo senior, quindi i cambiamenti di produttività devono essere adattati dal progetto.
3. Imparare una nuova lingua renderà il tuo cervello migliore.
4. Imparare ad essere aperti sull'apprendimento di nuove lingue ti renderà ancora più buono.

È win-win-win-win. Godere!

La risposta è che non ce la fai. Discutere con loro trascina l'arguer fino al loro livello (dove ti battono con esperienza) ed è in definitiva non costruttivo perché hanno una mentalità ristretta.

Ignora ogni argomento che danno a favore o contro la loro lingua e decidi. Usa le solite tecniche come evitare il contatto visivo, rispondere monosillabicamente e passare a un nuovo argomento quando il silenzio lo assicura. Allenali invece a infastidire la persona accanto a te.

La sfida qui è che il fan boy associa la lingua alla sua identità e ogni negatività associata a quella lingua è personale. Non attaccare o difendere. Ignora e basta.

Pochissime cose in un lavoro sono davvero script usa e getta. Finisco per mettere molte cose del genere nella wiki o nel repository, in caso di necessità.

Anche le cose che penso siano al di sotto del livello di condivisione, i miei compagni di squadra spesso si sentono diversamente. Ad esempio, ho un alias rgrep nel mio .profile. È solo un'istruzione find con un parametro poiché non ho accesso a rgrep reale su quel server. Un compagno di squadra ha avuto il vento e lo ha voluto sul wiki. Sì, la frase a una riga. Ovviamente non abbiamo avuto un dibattito sul linguaggio di implementazione - doveva essere UNIX. Ma sottolinea la necessità di fare cose che gli altri membri del team possono capire.

Un altro giro è che è possibile che lo sviluppatore senior abbia un motivo che non conosci per l'utilizzo di quella lingua. Hai chiesto?

Forse prova a fare lo stesso copione in entrambe le lingue una volta per mostrare perché il tuo è migliore.

Dovresti provare ad appannare . Questo significa essere d'accordo con tutto ciò che dice il fanboy (in parte o in tutto), ma fai le tue cose se non esplicitamente incaricato di fare diversamente.

Le opzioni passive-aggressive 1,3 portano a un maggiore disagio emotivo, quindi dammi un 2) prendilo sul mento.

Alcuni consigli generali per la strada: 4) Se non riesci ad ascoltare in modo più intelligente l'anziano, fai il tuo studio nella progettazione del linguaggio / compilatore. Scegli una lingua e impara quali pensieri ci sono entrati. Qual è il compromesso tra funzionalità, prestazioni e potenza espressiva. Quali altre opzioni ci sono. Solo questo ti garantirà superpoteri di programmazione disumani. Impara anche NBL , sarà enorme.

Affermarsi spingendo opinioni sugli altri inibisce la produttività e la comunicazione. Le persone possono pensare che rinunciare all'impulso emotivo sia utile, ma è solo un cerotto sulla loro insicurezza.

Essere umili e gentili con i consigli e migliorare te stesso farà meraviglie per esprimere i tuoi sentimenti viscerali a livello tecnico. Ti sentirai meglio e vedrai le cose per quello che sono, perché sarai in grado di ragionare. Difficile arrabbiarsi quando esternalizzi le critiche a un contesto tecnico.