L'ordine di una società di passare a un determinato IDE è una bandiera rossa? [chiuso]

Di recente mi sono unito a una startup in rapida crescita. Negli ultimi 3 mesi il team di sviluppo è cresciuto da 4 a 12. Fino ad ora erano molto diligenti su ciò che gli sviluppatori facevano il loro lavoro. In effetti una delle cose che inizialmente ho trovato interessante per la società è che la maggior parte dei programmatori utilizzava Linux, o qualsiasi sistema operativo ritenessero più adatto ai propri sforzi.

Ora gli ordini, senza discussione, sono giunti al punto che tutti devono passare a Eclipse. Un ottimo editore. Preferisco SublimeText2, ma è solo un mio gusto personale.

Giusto per essere chiari: siamo un team JS che utilizza Backbone ed Eclipse non è bravo a comprendere il codice Backbone. Ciò significa che coloro che fanno parte del team che usano un / good / IDE (PHP Storm), devono tornare a fare un sacco di cose da cercare-trovare-oh-aspettare-dove-ero-io-tre-passi-fa invece di semplicemente ctrl + clic e uso indietro / avanti - probabilmente diminuendo la produttività del 15% e godendo del 50% ...

Questa è una bandiera rossa? Sembra capriccioso e irragionevolmente controllato dire agli sviluppatori (non MS) quali IDE o set di strumenti usare se sono già sistemati e produttivi.

"Ora gli ordini, senza discussione , sono giunti al punto che tutti devono passare a Eclipse."

Penso che questa sia la vera bandiera rossa. Il tuo team è l'esperto nello sviluppo di software e quello che sarà influenzato dalla decisione, eppure non sei riuscito a dire una parola nella discussione che ha portato a questo ordine?

Sembra un eccesso di gestione da parte di capi dai capelli a punta. La persona / il team decisionale dispone di informazioni rilevanti per tale decisione?

Dato che i decisori sono sufficientemente qualificati per tale decisione, non chiedere l'opinione del team di sviluppo ha almeno due carenze:

• Il team non si sente coinvolto. Coinvolgere il team dovrebbe essere una priorità per la gestione. Non vorrei lavorare come sviluppatore da qualche parte in cui la mia opinione su questioni centrali come IDE non è valutata abbastanza per essere nemmeno richiesta. Concesso che chiedere l'opinione di qualcuno e poi decidere di no potrebbe essere peggio, ma in tal caso mi aspetterei una solida logica per quella decisione.

• La gestione, per quanto esperta, non funziona al 100% con lo sviluppo di questo codice specifico. Supponendo che le persone che non hanno affatto una visione interessante sarebbero ingenue. Naturalmente può essere che i manager abbiano pensato a tutto ciò che gli sviluppatori escogitano, ma l'unico modo per sapere è chiedere.

È ragionevole che quando lavori insieme su un progetto comune, che su ogni workstation hai tutti gli strumenti disponibili per modificare / costruire / eseguire il debug del tuo software e che gli strumenti principali per fare circa il 90% dello sviluppo siano noti a tutti Il gruppo. Questo obiettivo è più difficile da raggiungere se la tua squadra sta crescendo e tutti usano il suo set di strumenti preferito personale: più persone, più opinioni. E anche il lavoro amministrativo diventa più semplice se non si lascia che il numero di strumenti cresca più del necessario.

Naturalmente, se uno sviluppatore insiste nell'utilizzare il suo editor preferito personale, ciò potrebbe andare bene finché può assicurarsi che la fonte non abbia un aspetto o un comportamento diverso nell'editor principale del team (nel tuo caso Eclipse), quindi se dev B deve modificare la fonte dello sviluppatore A, lo sviluppatore B non dovrebbe essere costretto ad apprendere l'editor preferito personale di A per poter cambiare efficacemente la fonte. Ma attenzione, se i due devono lavorare di tanto in tanto di fronte allo stesso display (o fare un po 'di programmazione di coppia), le cose sono spesso più facili se l'editor scelto è ben noto da entrambi.

Per motivi di programmazione in coppia, è bello se entrambe le parti davanti allo schermo hanno le stesse abilità quando si usa la tastiera. È anche bello sapere che, se il tuo progetto ha esigenze di configurazione speciali nell'IDE, è configurato allo stesso modo per tutti. Avvio di un nuovo sviluppatore è più semplice quando gli strumenti sono uguali per tutti.

Ma se lo confronti con il solo tentativo di essere più efficace, non ne vale davvero la pena

Sì, è un po 'una bandiera rossa che la direzione si considera un giudice migliore di quali strumenti saresti più efficiente di te.

Non è una bandiera rossa in sé.

A volte la direzione deve prendere decisioni . Qualsiasi problema che richieda la standardizzazione su qualcosa tende a rientrare in quella categoria. Una volta ho lavorato presso un cliente che aveva permesso agli standard di andare alla deriva per alcuni anni e avevano oltre 20 strumenti SCM diversi. Ciò che è iniziato come scelta indipendente da diversi team di sviluppo si è trasformato in un incubo logistico che ha ostacolato gravemente la condivisione delle competenze e la collaborazione sul codice all'interno dell'organizzazione. Build integrato erano ..... ehm ... non molto integrato .....

Inoltre, non è pratico o necessario consultare tutti per ogni decisione . La misura in cui ciò deve essere fatto dipende dalla cultura dell'organizzazione e dall'importanza / complessità della decisione. In genere, sceglieresti una di queste opzioni meno pesanti per la consultazione:

1. Prendi la decisione da solo, se hai una conoscenza sufficiente dei pro / contro e non è una decisione abbastanza importante richiedere un'ampia consultazione.
2. Consultare alcune persone chiave (che probabilmente sarebbero gli sviluppatori senior più qualificati per prendere la decisione).
3. Solleva il fatto che stai prendendo una decisione per tutti coloro che potrebbero essere interessati (e-mail, riunione del municipio, riunioni del team). Di 'ciò che ritieni sia la decisione giusta ma che sei disposto a cambiarla se emergono nuove prove al contrario. Invita le persone a farsi avanti individualmente se hanno delle opinioni importanti
4. Invita le persone a formare un sotto-team per rivedere le opzioni e raccomandare una decisione. Buona opzione se si tratta davvero di una telefonata ravvicinata, non si conosce la risposta e si desidera che le persone coinvolte vengano acquisite nella decisione.

Per qualcosa come gli strumenti per sviluppatori (che è un problema potenzialmente controverso) probabilmente farei 2 seguito da 3 o 4. vale a dire ci sarebbero sicuramente alcune persone con cui non parlerei personalmente sul problema, ma d'altra parte la maggior parte delle persone chiave avrebbe la possibilità di contribuire al processo decisionale.

Per me la vera bandiera rossa sarebbe in giro se ritieni fortemente che sia stata presa la decisione sbagliata (errato == danneggia l'azienda piuttosto che non è stato scelto solo il tuo strumento preferito). Come reagisce il management quando sollevi questo problema:

• Una buona gestione ascolterà il tuo argomento, grazie sinceramente per il feedback e riconsidererà la loro posizione nel caso in cui tu abbia sollevato nuove intuizioni . Potrebbero ancora non essere d'accordo con te e attenersi alla loro decisione, ma apprezzeranno il fatto che tu l'abbia sollevato con loro e ti faccia la cortesia di dire perché stanno rispettando la loro decisione. Potrebbero anche cambiare il modo in cui prendono tali decisioni in futuro, e se hai fatto dei buoni punti potrebbero includerti nel loro elenco di "persone intelligenti da chiedere".
• La cattiva gestione diventerà difensiva, diciamo che "la decisione è presa" e altre tattiche simili per evitare di affrontare il fatto che potrebbero aver preso una decisione sbagliata. Potrebbero vederti come un "piantagrane". L'azienda soffre, così come la tua fiducia nella gestione. Questa è una vera bandiera rossa! Esci finché puoi!

Se stai usando Maven o qualcosa di simile, non dovrebbe importare quale IDE stai usando. Potrebbero esserci casi in cui uno è legato a un IDE specifico come eclipse, se ci sono plugin su cui fare affidamento.

Penso che dovresti essere in grado di scegliere il tuo IDE, l'IDE in cui sei più produttivo. Tuttavia, come ho già detto, ci sono casi in cui ha senso usare un IDE standard.

Avrei installato l'IDE "mandato aziendale", ma avrei comunque svolto la maggior parte del mio lavoro in qualunque IDE desiderassi - non è come se qualcuno potesse dire quale IDE è stato usato per modificare un file sorgente.

Sul fronte IDE vs. editor ... per quasi tutte le lingue, preferisco fortemente un IDE (IntelliJ) perché c'è molto di più che può fare per te rispetto a un editor. Ci sono alcune cose per cui torno a ST2 o Emacs, ma per la codifica quotidiana, nonostante quanto mi piacciano sia ST2 / Emacs, l'IDE vince quasi sempre.

Ogni team in cui abbia mai avuto una moltitudine di IDE e redattori: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - non è mai stato un problema. Mai.

Per me questo parla di un malinteso ai livelli alti dell'organizzazione, per quanto riguarda ciò che conta davvero. Ciò che conta è lasciare che i bravi programmatori facciano ciò che devono fare e utilizzare gli strumenti che li rendono più comodi. L'uniformità dell'IDE ha ben poco a che fare con la vera comunicazione che ha luogo sulle questioni essenziali dell'architettura degli oggetti, unit test, algoritmi, ecc.

Avere lo stesso IDE del prossimo ragazzo significa solo che entrambi sappiamo come sfogliare il codice con le stesse scorciatoie e come è impostata la nostra compilazione / configurazione. Nessuno dei quali conta quando si parla di problemi con il codice reale.

Guarda, è vivibile, a seconda di altri fattori dell'azienda. Puoi sempre utilizzare il tuo editor preferito per le cose quotidiane. E forse il tuo gruppo sta facendo altre grandi cose che creano una grande cultura. Ma gli IDE obbligati sono un enorme passo falso IMO. Per me se io fossi intervistando con una società e mi hanno informato che IDE mi è stato permesso di usare, io li ringrazio gentilmente per il loro tempo.

Nel nostro negozio di Ruby c'è una forte raccomandazione di utilizzare l'IDE di cui gode la maggior parte del team (RubyMine), perché sappiamo che fa il suo lavoro e possiamo insegnarci a vicenda scorciatoie ecc.

Gli sviluppatori sono liberi di utilizzare un IDE diverso, ma è necessario che abbiano solide competenze in quell'editore se lo desiderano. Se vediamo qualcuno che fatica a navigare nel proprio progetto o a modificare il testo nella sua FooEdit personalizzata, RubyMine per loro lo è.

Se un programmatore è un esperto in un determinato IDE, allora dovrebbe usarlo. Se non sono esperti in alcun IDE, probabilmente ce ne sono uno o due molto comuni nel tuo linguaggio di programmazione o all'interno del tuo team, e probabilmente ha senso per loro impararlo.

Essere costretti a standardizzare su un IDE sembra un'idea terribile.

Dovrebbero essere esaminati i motivi per cui una società impone un particolare editor o software in generale ai propri sviluppatori. La parte paranoica (forse non la parola che sto cercando) di me pensa che potrebbe esserci una sorta di monitoraggio della produttività aggiunto all'eclissi che stanno chiedendo agli sviluppatori di installare. Un pensiero molto meno paranoico (di nuovo) sarebbe che hanno trascorso del tempo ad aggiungere strumenti di creazione del prodotto a questo IDE che renderebbe le cose molto più semplici se tutti premessero lo stesso pulsante per testare e costruire il proprio ramo di codice.

Comunque quello che sto cercando di dire è probabilmente più che una semplice burocrazia o un metodo per fare casino con i responsabili degli sviluppatori.

Questa è una grande bandiera rossa. Ogni azienda ha alcune idee così stupide, ma se altre bandiere rosse continuano ad arrivare, vattene e basta.

È facile perdersi la motivazione alla base di alcune decisioni, specialmente con un team in rapida crescita. La motivazione per passare a Eclipse potrebbe essere semplicemente il fatto che la maggior parte degli sviluppatori sembra perdere molto tempo a configurare l'IDE e che la propria azienda ha una competenza limitata.

Vorrei solo prendere l'ordine di spostarmi su Eclipse per significare che dovresti avere Eclipse nel caso fosse necessario, ma continuare il tuo lavoro nel tuo editor preferito. (Potrebbe essere necessario passare a Eclipse gradualmente se la tua azienda inizia a implementare strumenti interessanti all'interno di Eclipse.)

Bandiera rossa: aspetterei se ci fossero altri ordini così irrazionali prima di essere preoccupato.

Una startup sta generalmente cercando di rimanere agile abbastanza a lungo per capire un modello di business sostenibile. Una volta individuata la parte monetaria, la direzione si sposta per ampliare il business. Questo è generalmente quando tutti i primi dipendenti della tecnologia iniziano ad andarsene, man mano che i processi di ingegneria vengono rafforzati.

Come sai, non sai quale codice farà effettivamente fino a quando non lo eseguirai. Turing lo ha dimostrato nei primi tempi dell'informatica. Ciò significa che non esiste una misura significativa della produttività quando si tratta di scrivere software. Tuttavia, affinché il management faccia il proprio lavoro, la produttività deve essere leggibile. Poiché non è possibile misurare il codice (e le persone hanno provato, ad esempio righe di codice), misureranno ciò che possono vedere. I programmatori sono più leggibili del software che sviluppano. Il tipico team di gestione tenta di controllare i programmatori al fine di rendere leggibili queste cose (invece di fare il loro vero lavoro: togliersi di mezzo). E poiché misurano le cose sbagliate, non funziona molto bene.

Detto questo, puoi ancora fare molta strada con una squadra debolmente accoppiata. Il team di sviluppo di Github ha circa 50 persone e infrange ogni regola nei manuali di gestione aziendale. Sembrano fare tutto bene. I bug vengono corretti (eventualmente). Le funzionalità vengono aggiunte. Gli incendi si spengono.

Ciò che è una grande bandiera rossa è se stanno cercando di ridimensionare le cose senza aver capito come fare soldi. A quel punto, ti devi chiedere quanto valgono davvero le tue opzioni e le tue sovvenzioni non investite.

Sicuramente questa è una cattiva idea. È inevitabile che il team diventi meno produttivo poiché devono imparare a usare nuovi strumenti. E anche allora non saranno così efficaci come con gli strumenti che già affannano .

Da quando ho provato vari strumenti da solo, ho sempre avuto la sensazione "Accidenti, questo editor mi dà fastidio con <inserire qualche bug / differenza dallo strumento preferito>". Quindi sarà anche uno svantaggio morale.

Ma ovviamente ci sono anche dei professionisti che chiedono a un intero team di utilizzare gli stessi strumenti. Condivisione di configurazioni, script, plugin e tutto quel genere di cose. Ciò non sarebbe possibile con una varietà di set di strumenti.

D'altra parte ... quell'ultimo pezzo non sarebbe necessario se tutti usassero il loro software preferito. ;)

Puoi "usare" Eclipse mentre stai ancora digitando SublimeText2.

Ciò significa avere Eclipse installato e configurato per i tuoi progetti e metterti al passo con esso in modo da sentirti a tuo agio nell'usarlo se, per esempio, abbini la programmazione. A nessuno (o almeno dovrebbe interessare) quale editor hai effettivamente usato per digitare un pezzo di codice che hai commesso, purché il mantenimento della tua configurazione parallela non richieda una quantità eccessiva di tempo e non ti tagli fuori dal ambiente di sviluppo standard.

Se stai usando Git e la tua diramazione non è attiva, non dovresti comunque utilizzare gli editor degli altri. Puoi semplicemente spingere un ramo e fare in modo che un altro sviluppatore lo tiri per farlo funzionare se davvero non riesce a capire il tuo set di strumenti. Costringere tutti a usare lo stesso editor suona come un ordine di un responsabile aziendale che vuole apparire intelligente ma non capisce davvero come operi.

Se ci pensate da un punto di vista gestionale, il motivo per cui potrebbero farlo è per la conformità legale. La società è responsabile di garantire che ogni strumento utilizzato venga utilizzato legalmente e inoltre non ostacolerà il prodotto in fase di sviluppo. (Alcuni editor sono gratuiti per uso personale, ma non per altri scopi, ecc.) Controllare ogni strumento che ogni sviluppatore potrebbe voler utilizzare può essere costoso. Ho visto che nei progetti in cui le linee temporali sono strette, la gestione sarà cauta su quali strumenti / librerie / ecc. Vengono utilizzati per ridurre al minimo le modifiche successive nel progetto che sono dirette dalle persone giuridiche.

Sui progetti di sicurezza più elevata c'è anche la preoccupazione di dove gli IDE archiviano i file temporanei e quali informazioni siano archiviate tra le sessioni.

Tutto dipende dai motivi per cui devono raccomandare Eclipse. Se gli sviluppatori hanno problemi a configurare i propri ambienti perché tutti organizzano le cose in modo diverso, potrebbe esserci un motivo per raccomandare una camicia di forza. Se, tuttavia, tutti erano felici e produttivi usando ciò che volevano, ci sono poche ragioni per imporre un cambiamento a qualcosa di così profondamente coinvolto nel processo creativo.

Eclipse è molto più di un semplice editor: potresti continuare a utilizzare il tuo editor preferito per modificare il codice e fare affidamento su Eclipse per il controllo del codice sorgente, il debug e qualsiasi altra cosa il flusso di lavoro obbligatorio aziendale desideri venga utilizzato.

Un'ultima cosa: applicare il processo in questo livello può indicare che l'azienda intende espandere il team di sviluppo e desidera disporre di una certa struttura in modo che i nuovi compagni di squadra possano diventare produttivi più velocemente. Se pensi che Rails (o Django) sia un framework "supponente", ti renderai conto che avere una struttura aiuta a capire più facilmente le nuove applicazioni.

La bandiera rossa non è tanto che un singolo IDE / editor viene forzato su ogni sviluppatore, ma che questa decisione, e in particolare la decisione su quale IDE / editor debba essere utilizzato, non è stata presa da tutti gli sviluppatori, e forse nessuno dei loro!?!

Certamente sarebbe meglio per gli sviluppatori raggiungere un consenso, soprattutto perché sono ovviamente i più qualificati per la decisione (almeno su quale editore / IDE). Potrebbero esserci buone ragioni per conformarsi e tale decisione dovrebbe pesare sulle preferenze della direzione, ma quale editor / IDE avrebbe dovuto essere la decisione di tutti gli sviluppatori.

Ottenere 12 sviluppatori per esprimere alcuni voti sarebbe facile. Certamente c'era abbastanza tempo per farlo! La conclusione sarebbe stata dolorosa per alcuni in ogni caso e alla fine avrebbe anche potuto essere Eclipse, ma etichettare il requisito come "bandiera rossa" in quel caso sarebbe molto più discutibile.