Dovrei usare la lingua in cui mi trovo più a mio agio, o la compagnia "standard"

Again, this is only for my plant, and I'm the only one who will ever be supporting it unless I leave the company, and then my replacement would be supporting it. Not someone else already in the company.

1 - Non credere che tu sia l'unico a cui dare supporto. Ti piace il tempo e le vacanze di malattia, giusto? Che cosa succede se è necessario prendere un congedo prolungato per maternità / paternità o qualcosa del genere? Chi sosterrà la tua app allora? Inoltre, cosa succede se ti piacerebbe parlare con qualcuno di problemi tecnici specifici della tua azienda? Cosa succede se ti piacerebbe avere recensioni sul codice? O hai bisogno di aiuto con un bug insidioso? In tutti questi casi aiuta ad essere tra gli altri con informazioni sulla tecnologia che stai utilizzando, in particolare su come può essere applicata per risolvere i problemi specifici della tua azienda.

The company does very little development with their standard anyway.

2 - Solo perché alcuni documenti esistono non significa che siano realmente lo standard o significhi qualcosa. Può semplicemente significare che c'è un gruppo di individui politicamente influenti che difendono questo approccio, e potrebbe girare fuori c'è altri sottogruppi che adottano approcci diversi.

Il tuo problema potrebbe semplicemente essere che lo "standard" si è evoluto in uno stato di fatto, non documentato, in conflitto con lo "standard" documentato. Oppure potrebbero esserci molti piccoli raggruppamenti non ufficiali di persone che usano diversi "standard" - con uno di quei gruppi che riescono a rendere ufficiale il loro "standard". Probabilmente hai bisogno di chiedere in giro per capire che cosa fanno gli altri del tuo gruppo - che potrebbero supportare te e la tua app - le migliori pratiche. Chiedi cosa si sente a tuo agio con te. Mappa il panorama tecnologico reale della tua azienda e scopri dove è il know how. Proprio come ogni buon pezzo di conoscenza tribale in evoluzione, l'unico modo per sapere come procedere è parlare con le persone.

3 - Non perdere opportunità professionali per imparare nuove cose . Devi difenderti dall'essere incasellato in questo settore. Sii agile. Potresti avere l'opportunità di guadagnare un po 'di spazio e imparare un nuovo modo di risolvere un problema. Per non parlare del fatto che stai acquisendo nuove competenze per il tuo curriculum. Solitamente può aiutarti solo a uscire dalla tua zona di comfort per fare qualcosa di nuovo. Detto questo, se la differenza / novità è così estremamente di nicchia che non pensi che tu o qualsiasi futuro datore di lavoro otterrà alcun valore da quelle competenze, allora forse questa non è una grande opportunità. Ma avere la possibilità di essere sia un esperto di ASP.net che di LAMP certamente aprirà gli occhi e potrà solo aiutare la tua carriera. Non c'è niente come un vero progetto con una scadenza per costringerti a imparare davvero qualcosa.

Quindi il mio consiglio, non farlo da solo. Scopri dove si trovano le persone e decidi dove meglio adattarti. Se hai bisogno di uscire dalla tua zona di comfort, usa questa opportunità per crescere professionalmente.

That being said, is it better to violate the company standard and go with the setup that I can support better, or is it better to go with the setup that the company can support better if I ever were to leave, even though no one currently in the company can support their own standard anyway?

È una decisione di gestione. Fagli conoscere le tue preoccupazioni e insisti formalmente sul cambiamento.

Detto questo, una lingua è uno strumento e devi scegliere lo strumento giusto per un lavoro; fagli capire che non avviti una vite con un martello.

Hai delle aspirazioni per la promozione o lavori su altri progetti? Se è così, suggerisco che "fare le tue cose" avrà due effetti negativi che quasi certamente porteranno (parafrasando) "Sarò io a sostenerlo, finché non me ne vado"

1. Poiché hai scelto di non seguire gli standard della compagnia, non sei particolarmente adatto a ruoli più alti, poiché non sei in grado di seguire semplici istruzioni.
2. Poiché hai scelto di non seguire lo standard aziendale, sarà il tuo problema che nessun altro in azienda può supportare il tuo codice.

Se si sceglie di utilizzare lo standard, non sarà responsabilità dell'utente continuare a mantenere il prodotto quando (se) si presenta un'opportunità di promozione o un altro progetto.

L'altro modo di guardare un'analogia ridicola. Mi sposto in un paese in cui guidano a sinistra, tuttavia, sono molto più abituato a guidare a destra, preferisco guidare a destra, per questo sono più bravo e posso guidare più veloce. Dovrei guidare a destra?

Le aziende hanno standard per una ragione, se c'è uno standard formalmente dichiarato che dice di usare x, allora devi giustificarti y.

Questo non significa che non puoi usare y, significa che devi capire il ragionamento alla base dello standard e ottenere l'approvazione prima di violarlo.

Forse dopo aver capito il motivo, non vuoi più violarlo, forse vedrai che deve essere cambiato o scartato, o che non si applica in questa istanza in modo che l'uso di y non sia un problema.

Se si applica, allora a meno che tu non possa cambiarlo, dovresti seguirlo. Gli standard aziendali non sono esattamente allo stesso livello degli ordini diretti, ma il tuo datore di lavoro ha la ragionevole aspettativa di seguire entrambi, a meno che non violino la legge.

Dipende tutto dal licenziamento o meno. Se stai per essere licenziato, non farlo. Se non hai intenzione di essere licenziato, quindi con tutti i mezzi andare avanti con esso.

Penso che puoi anticipare molti dei problemi che potrebbero sorgere da questo e fare un piano dettagliato per se e quando hai mai dovuto lasciare la compagnia.

Un problema che potrebbe intaccare il lavoro sarebbe se tu fossi andato via e le Risorse Umane dovessero cercare il tuo sostituto. Dato che cercano attivamente di capire cosa hai fatto e di assumere in base alle competenze necessarie - oppure guarda semplicemente il documento originale che ha specificato la politica di IIS / ASP.NET / etc. e assoldare ciecamente qualcuno con queste competenze per mantenere il codice LAMP (sul principio "perché lo dice così"), penso che quest'ultimo sia molto più probabile.

La cosa più facile (a lungo termine) è fare ciò che fabianhjr raccomanda e cambiare lo standard. Modificalo per includere sia Microsoft che LAMP se sono resistenti a un'interruzione completa.

In questo caso devi seguire lo standard. Se non sembra che lo standard si applichi, devi parlare con il tuo manager di farlo in una lingua diversa.

Tra tutti gli standard da seguire nello sviluppo, personalmente ritengo che la scelta della lingua sia la più importante . Ignorando la scelta della lingua standard a favore di uno sei più a tuo agio con i collaboratori delle foglie e / oi successori su un torrente senza pagaia, perché potrebbero non avere le competenze per lavorare al tuo progetto. Le decisioni di assunzione di un'azienda sono basate sulla scelta della lingua, pertanto decisioni come queste possono avere un impatto maggiore. L'introduzione di un'altra piattaforma / lingua potrebbe costringere la compagnia a un punto critico quando inizierà ad assumere altre persone.

Oltre la lingua, devi considerare il supporto interno per il server LAMP. Chi amministrerà Apache? Che ne dici di MySQL? Il software dell'azienda viene eseguito su un altro database? Gli amministratori saranno disposti a gestire una nuova piattaforma. Anche se pianifichi di amministrare questi servizi, i doveri potrebbero alla fine cadere su qualcun altro. Se prevedi di amministrare i servizi, gli amministratori di rete / server ti consentiranno di farlo?

Le ramificazioni dell'introduzione di una piattaforma diversa possono essere ampie e profonde. Non seguire lo standard potrebbe finire per interessare molte persone oltre a te stesso. Anche se in LAMP sei più esperto di ASP.NET, costruire su quella piattaforma potrebbe finire per costare molto di più la tua azienda a lungo termine. La chiave qui è comunicare con il tuo manager e comprendere gli effetti del decisione finale.