Perché l'uso delle astrazioni (come LINQ) è così tabù? [chiuso]

Sono un appaltatore indipendente e, come tale, intervisto 3-4 volte all'anno per nuovi concerti. Sono nel bel mezzo di quel ciclo e sono stato rifiutato per un'opportunità, anche se ho sentito che l'intervista è andata bene. La stessa cosa mi è successa un paio di volte quest'anno.

Ora, non sono un ragazzo perfetto e non mi aspetto di essere adatto per ogni organizzazione. Detto questo, la mia media in battuta è inferiore al solito, quindi ho cortesemente chiesto al mio ultimo intervistatore un feedback costruttivo e mi ha dato!

La cosa principale, secondo l'intervistatore, era che mi sembrava troppo incline all'utilizzo delle astrazioni (come LINQ) piuttosto che agli algoritmi di livello inferiore, coltivati ​​biologicamente.

In apparenza, questo ha un senso - in effetti, ha anche avuto senso anche gli altri rifiuti, perché ho parlato di LINQ anche in quelle interviste e non sembrava che gli intervistatori sapessero molto di LINQ (anche se erano .NET ragazzi).

Quindi ora mi rimane questa domanda: se dovremmo essere "in piedi sulle spalle dei giganti" e usare le astrazioni a nostra disposizione (come LINQ), allora perché alcune persone lo considerano così tabù? Non ha senso estrarre il codice "dallo scaffale" se raggiunge gli stessi obiettivi senza costi aggiuntivi?

Mi sembra che LINQ, anche se è un'astrazione, è semplicemente un'astrazione di tutti gli stessi algoritmi che uno scriverà per ottenere esattamente lo stesso fine. Solo un test delle prestazioni potrebbe dirti se il tuo approccio personalizzato era migliore, ma se qualcosa come LINQ ha soddisfatto i requisiti, perché preoccuparsi di scrivere le tue classi in primo luogo?

Non intendo concentrarmi su LINQ qui. Sono sicuro che il mondo JAVA ha qualcosa di paragonabile, vorrei solo sapere perché alcune persone si sentono così a disagio con l'idea di usare un'astrazione che loro stessi non hanno scritto.

AGGIORNARE

Come ha sottolineato Euphoric, non c'è nulla di paragonabile a LINQ nel mondo Java. Quindi, se si sta sviluppando nello stack .NET, perché non provare sempre a utilizzarlo? È possibile che le persone non capiscano completamente cosa fa?

Non credo sia discutibile l'uso di astrazioni in sé. Ci sono altre due possibili spiegazioni. Uno è che le astrazioni perdono tutte una volta o l'altra. Se dai l'impressione, corretta o no, di non comprendere i fondamenti di base, ciò potrebbe riflettersi male in un'intervista.

L'altra possibile spiegazione è l'effetto fanboy. Se parli eccitato di LINQ e lo riproponi ripetutamente in un'intervista con una società che non lo utilizza e non ha in programma di farlo, ciò dà l'impressione che non saresti soddisfatto o addirittura scontento di lavorare con le tecnologie più vecchie. Può anche dare l'impressione che il tuo entusiasmo per un prodotto ti abbia reso cieco alle alternative.

Se veramente pensi che sarebbe felice in un negozio non LINQ, prova a chiedere a quello che fanno uso, e adattare le risposte di conseguenza. Mostra loro che, mentre preferisci LINQ, sei competente usando tutti gli strumenti a tua disposizione.

Ad alcuni programmatori .NET, in particolare quelli che provengono da un classico VB / ASP o da uno sfondo C ++, non piacciono le novità come LINQ, MVC ed Entity Framework.

Sulla base di ciò che ho osservato, è probabile che gli ex VB di questo gruppo utilizzino ancora livelli di accesso ai dati e altro codice originariamente scritto più di 10 anni fa. Utilizzeranno anche vecchie parole d'ordine come "n-tier" e simili e non capiranno davvero nulla di tutto oltre a .NET Framework 2.0 né vogliono imparare nulla al riguardo.

Gli utenti del C ++ tendono ad essere programmatori orientati al mondo accademico che adorano codificare algoritmi interessanti, anche se ciò significa reinventare la ruota. Odiano a seconda di tutto ciò che non hanno scritto a mano. Alcune di queste persone si divertono anche a far sentire gli intervistati inferiori, specialmente quelli con un background meno tradizionale.

Probabilmente ti imbatterai in organizzazioni come questa quando intervisterai. Ma incontrerai anche alcuni che stanno usando metodi più recenti. Non lasciarti sfuggire alcune cattive interviste.

Microsoft ha una lunga storia di nuove tecnologie accese e di dimenticarsene dopo 5, 10 o 20 anni. LINQ potrebbe apparire come un altro per alcune persone. Noteranno che Microsoft non può deprecare SQL, ma LINQ potrebbe seguire Silverlight . Quindi potresti vedere la paranoia derivante da una dura esperienza, o solo persone che sono state lasciate indietro dalla tecnologia moderna e che si risentono.

Non ha senso estrarre il codice "dallo scaffale" se raggiunge gli stessi obiettivi senza costi aggiuntivi?

C'è sempre un costo aggiuntivo.

La curva di apprendimento per roba pronta all'uso è sempre lì. Il dolore di ottenere aggiornamenti (e dipendenze) è sempre lì. L'incapacità di rovinare le budella è sempre lì.

Per LINQ, il primo vale davvero. Molte persone considerano il codice dall'aspetto "strano" come difficile da leggere e più difficile da eseguire il debug. La sintassi di tipo sql è praticamente persona-non-grata ogni concerto professionale da cui lavoro da quando è uscito. LINQ to SQL (e altre origini dati) hanno un numero di gotcha e opzioni di ottimizzazione limitate.

Questi sono gli argomenti generali contro strumenti di terze parti e LINQ in particolare. Detto questo, LINQ è uno strumento dannatamente utile e dovrebbe essere preferito nella maggior parte delle situazioni. Piangere non inventato qui, e le astrazioni non dovrebbero essere favorite in modo forte rispetto alla dissonanza cognitiva .

Non sanno / non possono imparare LINQ, ma sono "ovviamente" buoni sviluppatori, quindi LINQ non deve valerne la pena. È una trappola comune.

Qualcos'altro che dovresti considerare è che il tuo entusiasmo per una nuova tecnologia interessante può semplicemente far sentire le persone a disagio e non volerti intorno. Non li stai "potenziando", perché sei tu che conosci questa tecnologia, non loro. Anche se loro stessi non se ne rendono conto, potrebbero cercare candidati in grado di rafforzare ciò in cui hanno già investito così tanto tempo.

Vuoi presentare un atteggiamento che dice "Qualunque cosa tu stia facendo, voglio aiutarti a raggiungerlo", piuttosto che dare un sottotesto che dice "Potresti fare le cose in modo cattivo, e avere me in giro dimostrerà esso ".

La mia opinione su questo (e TBH indovino perché nessuno di noi può dire cosa pensavano quegli intervistatori) è che spesso vai a un'intervista per spiegare perché dovrebbero assumerti per adattarsi alla loro squadra, al loro modo di lavorare .

Puoi essere lo sviluppatore perfetto, un dio del codice di partenza rock, ma ciò non significa assolutamente nulla se ciò che vuoi fare (enfatizzato da te parlando in modo eccessivo e troppo entusiasta di alcune gubbin tecnologiche interessanti) semplicemente dice loro di te, e che non lo faresti adattarsi a ciò che vogliono. Se hanno un sistema di accesso ai dati vecchio stile, che non può essere aggiornato per nessun motivo, non hanno bisogno di qualcuno che abbia dimenticato come mantenerlo. Se stanno sviluppando nuove cose e vuoi davvero mettere questa nuova fantastica tecnologia ovunque, allora è ovvio che avranno un grosso problema con la futura manutenzione del codice e / o la formazione del personale.

Come libero professionista, questo è molto più un problema che se assumessero un permesso. Con un permesso, la formazione e lo sviluppo di nuovi modi di lavorare non sono cose cattive, nell'ambito del codice e delle pratiche esistenti: rimarrai lì a lungo per migliorare le cose. Con un libero professionista, in realtà non danno uno spasso quello che vuoi, sei lì solo per fare il loro lavoro nel modo in cui lo desiderano, e non è il tuo lavoro fare altro. (non sono d'accordo - diventa un dipendente permanente)

Probabilmente non ha nulla a che fare con LINQ stesso, ho rifiutato un candidato che si è presentato e ha spiegato quanto sarebbe stato meglio scrivere tutto in Haskell. Non facciamo Haskell. Lo stesso vale per qualsiasi tecnologia che non viene utilizzata dalla società, di solito non è un problema se lo menzioni come qualcosa di buono. Il problema sorge quando sei troppo entusiasta e appassionato.

C'è una preoccupazione valida che ho sentito da coloro che non usano Linq, ed è una che mi viene in mente: "Solo perché non puoi vedere l'implementazione non significa che non sia costoso".

Prendi il frammento seguente:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

I LINQ avviati qui sono il cringing. Perché? Perché solo perché questo codice sembra carino ed elegante non significa che non sia terribilmente inefficiente. Count (), con un predicato, valuta ogni elemento del suo enumerabile padre e riassume le volte in cui il predicato è tornato vero. Quindi, non è solo questo N ^ 2 (quando inputList e otherInputList sono di cardinalità N approssimativamente uguale), è il caso peggiore in assoluto N ^ 2; OGNI elemento di otherInputList viene attraversato per OGNI elemento di input. Invece, il primo passo è usare Any () invece di Count, perché è proprio quello che vuoi sapere, e si chiuderà non appena la risposta sarà "sì". L'impostazione di un HashSet che memorizza valori distinti otherInputListObject.OtherPropertypotrebbe essere d'aiuto; l'accesso diventa O (1) anziché O (N),complessità nel caso peggiore anziché complessità quadratica nel caso migliore .

Quindi vediamo che questi bei metodi eleganti hanno costi seri dietro di loro, e se non sai quali sono questi costi, puoi facilmente codificare un algoritmo di complessità O (mio GD) nel file server centrale ad alte prestazioni del tuo potenziale datore di lavoro o alla pagina del portale di destinazione principale la prossima volta che potrebbero aver bisogno di una modifica. Licenziarti dopo aver fatto ciò non annulla quello che hai fatto, ma non assumerti se pensano che lo faresti lo impedirebbe. Quindi, per evitare questo, devi dimostrare che si sbagliano; discutere cosa fanno questi metodi (nel senso che devi conoscere te stesso) e la loro complessità, e come arrivare alla risposta in un tempo efficiente (NlogN o migliore).

Un'altra preoccupazione è il buon vecchio argomento "Quando il tuo unico strumento è un martello". Mettiti al posto dell'intervistatore intervistando questo fan di Linq. Al candidato piace Linq, vuole usarlo, pensa che sia la cosa migliore di sempre. Potrebbe anche sembrare che il candidato non possa codificare senza di esso, poiché ogni problema di programmazione fornito è stato risolto con Linq. Bene, cosa succede quando non può essere utilizzato? Un sacco di codice .NET 2.0 è ancora là fuori, che se fosse aggiornato richiederebbe dolorosi aggiornamenti a server, stazioni di lavoro degli utenti, ecc. Ecc., In modo da poter usare i tuoi fantasiosi metodi di estensione. Come intervistatore, proverei a farti mostrare che potresti codificare un ordinamento efficiente o utilizzare i metodi di ordinamento 2.0 se dovessi, non importa quanto potrei essere d'accordo con te sul fatto che le librerie Linq e metodi di estensione simili sono piuttosto dolce. Un intervistatore che non vede il punto potrebbe non preoccuparsi nemmeno di farti mostrare attitudine per qualsiasi altra cosa; presumeranno che tu non ce l'abbia e andranno avanti.

Questo è diventato un po 'lungo, ma potrebbe essere utile a qualcuno, quindi lo lascerò.

In realtà ho incontrato qualcosa di simile, passando attraverso poco più di 20 interviste il mese scorso (un mix di telefono e faccia a faccia). Sicuramente stava succedendo qualcosa di inaspettato che non riuscivo a capire.

Una delle cose che ho notato è che le cose che di solito sono state il punto centrale dei cicli di intervista degli ultimi cinque o sei anni non sono state decisamente discusse o concesse a breve termine. Cose come i fondamenti di analisi / progettazione OOP, modelli (sia di progettazione che architetturali), alcune delle funzionalità .net più avanzate / orientate all'astrazione (inclusi lambda o LINQ in particolare, generici, serializzazione / associazione dati e simili), e persino il argomento solitamente caldo della metodologia preferita (a nessuno sembrava interessarsi molto dell'agile vs waterfall o del tipo di agile) e degli strumenti o della scelta di ORM o dei mezzi preferiti di collaborazione o gestione del controllo delle fonti. In alcuni casi non menzionato affatto, in quasi tutti i casi apparentemente non preoccupano.

Ciò che ha attirato l'attenzione, in più interviste e varie aziende non correlate in settori non correlati, è stato così:

• Una strana fissazione su convenzioni obsolete / superate e limitazioni "ritorno all'età della pietra". Come lo sviluppo di un'app Web primitiva in VS2003 con un elenco di assurde restrizioni che proibiscono ulteriormente l'utilizzo di funzionalità esplicite all'interno di quell'era di .net ... come se quello fosse un vero indicatore di una capacità moderna degli sviluppatori ... la capacità di ricordare il paradigma e i limiti di 9 anni fa ulteriormente paralizzati da vincoli non realistici / arbitrari. Un altro posto era molto perseguitato sul tema delle collezioni personalizzate, circa le collezioni pre-generiche. Un altro posto ha oscurato un esempio di codice di un modello di classe che ho scarabocchiato perché non ho usato costruttori in cascata (sembravano inconsapevoli del supporto per l'inizializzazione della proprietà sulla dichiarazione, che era sufficiente alla necessità).

• Estrema attenzione ai dettagli di implementazione specifici in un microcosmo e / o impostazioni di configurazione, anche nel caso di tecnologie che si focalizzano sull'essere agnostico di piattaforma o protocollo (cioè ... l'intero punto NON deve essere fissato su un'implementazione specifica o un uso particolare ma piuttosto su riutilizzo / riutilizzo / estensibilità / integrazione necessaria).

• Disponibilità a specificare / supervisionare / riesaminare il codice / e in alternativa spoolare il lavoro da e verso una squadra offshore, e abilità non codificanti legate a farlo.

• Utilizzo di versioni specifiche di prodotti / piattaforme / moduli / ecc. In misura talvolta assurda; "Quindi ... hai usato le versioni 1, 2 e 4? Ma non 3, eh? Hmmm ... {annota il tuo curriculum con" no v3 !!!} ". Il grado di utilizzo non sembra importare; solo che hai o non hai usato qualcosa a tutti , e la cosa specifica che essi chiedono anche ... senza sostituzioni sembravano contare, anche di un prodotto concorrente più ampiamente utilizzato e completamente descritto.

• Una maggiore attenzione a "quanto bene ti adatterai al nostro team" rispetto a "sei effettivamente un bravo sviluppatore di software" o "hai le capacità e l'esperienza per aggiungere valore all'azienda e aiutarci a fornire una qualità prodotto "o addirittura" sei un pericoloso idiota che entrerà e distruggerà il negozio ". In alcuni casi, il mio curriculum è stato preso come un dato di fatto, e persino il cosiddetto "schermo tecnico" o intervista tecnica è stata una valutazione della personalità molto più di una valutazione delle competenze. Anche per posizioni contrattuali relativamente a breve termine in cui saresti lì e ci tornerai prima che due stagioni siano cambiate.

• Le aziende questa volta sembravano concentrarsi molto meno sulla risoluzione di specifici problemi tecnici, l'avvio di nuovi progetti di sviluppo green-field o big 2.0, o l'immissione sul mercato di un prodotto specifico per capitalizzare su una tendenza o opportunità emergente o sui soliti grandi kickoff . Un tema ricorrente che ho notato in almeno 15 dei luoghi era che un piccolo gruppo di 3-5 sviluppatori, per lo più sopravvissuti al crollo del mercato dell'08, erano in grado di macinare un prodotto nel corso degli ultimi 3 anni circa e hanno riscontrato un certo successo o la loro società nel suo insieme è in forte espansione e stanno assumendo nuove persone per stare al passo con le crescenti richieste di funzionalità o per affrontare / superare i difetti di progettazione che hanno incorporato in questi sistemi o per liberare le piattaforme di cui sopra per liberare il core team che lo ha creato per fare "altri progetti".

Ma ... se c'è una cosa che so di questo business è che è ciclica. La prossima volta che cerco un nuovo concerto, non sarò sorpreso se il gioco è cambiato di nuovo. Devi solo rimanere mentalmente flessibile, fare un po 'di ascolto attivo, evitare di fare affermazioni assolute se non sono necessarie ma non essere neanche una donnola, e non venire come unidimensionale (vieni come un idiota o uno zelota, né desiderabile) o troppo buono (può essere minaccioso e costare un concerto).

Regola semplicemente il tuo approccio e prova a dare una risposta più misurata la prossima volta ... menziona alcuni modi in cui potresti affrontare un problema ... ma anche se si tratta di una conoscenza vera per te, agisci come se stessi davvero pensando a questo e ragionando sul posto. Sembra più umile e meno intimidatorio o scoraggiante in quel modo.

Naturalmente, la Legge di Murphy è quella che è, la prossima intervista dopo che smetti di essere "appassionato del mio attuale ragazzo della tecnologia preferita" e adotti una posizione più equilibrata / accarezzata dalla barba è il concerto che avresti ottenuto se fossi stato impazzito ragazzo zelante. ;)

Penso che tu stia tracciando una falsa conclusione, perché il tuo set di campioni è troppo limitato. Sebbene abbia visto una buona parte dei negozi IT con forte avversione per qualsiasi cosa "non inventata lì" ¹ , nessuno di loro squalificherebbe i candidati in base alle loro preferenze nello stack tecnologico: erano giustamente convinti di poter insegnare al candidato giusto da usare le loro biblioteche coltivate in casa.

Dubito seriamente che la società abbia messo al bando l'uso di LINQ. Più probabilmente, volevano che mostrassi loro le tue abilità a un livello più profondo.

Ad esempio, un modo per capire se conosci le tue tabelle hash è chiederti di implementarne una primitiva su una lavagna. Questo semplice esercizio rivela al revisore una quantità sorprendente di dati sulle tue conoscenze: apprende immediatamente se conosci il codice hash / uguali e cosa sai delle collisioni hash. Allo stesso tempo, è difficile immaginare qualcuno nella loro mente giusta reimplementare una tabella hash, perché Microsoft ha fatto un ottimo lavoro. Lo stesso vale per molti algoritmi, come l'ordinamento e la ricerca: gli intervistatori spesso vorrebbero sapere se il tuo background è sufficiente per comprendere le interazioni di basso livello, piuttosto che verificare di avere una conoscenza pratica delle librerie .NET.

È quasi certo che insisterebbero sul fatto che tu utilizzassi le implementazioni delle biblioteche piuttosto che le tue una volta che sei stato assunto per lavorare per la loro compagnia. Ma durante l'intervista ti spingerebbero verso il codice di basso livello per comprendere meglio le tue vere abilità.

Penso che tu stia facendo delle pazze generalizzazioni lì del tipo "Ho visto una mucca nera in Scozia, quindi tutte le mucche scozzesi sono nere".

Se ti intervistassi, sarei deluso se non potessi rispondere alle mie domande su Linq.

Anche se Linq è complicato, molte persone lo vedono come un voodoo che è ingiusto in quanto è in realtà molto semplice e tanto più intelligente per questo.

Per interpretare l'avvocato del diavolo, la ragione è che molti sviluppatori non si preoccupano delle cose nuove e pensano che tutto debba essere risolto con strumenti fatti in casa (di solito inferiori). Non c'è niente di sbagliato nell'usare le astrazioni. Inferno, di solito non c'è una buona ragione per non usare quelle astrazioni.

Sembra che tu abbia appena intervistato un povero sviluppatore che non si tiene aggiornato con le cose e adotta l'approccio a martello e chiodo a tutto. Questi sono i tipi di sviluppatori che non sanno nulla di utili strumenti open source come NUnit, NHibernate o i vari contenitori IoC; quelli che cercano di risolvere ogni problema con un enorme proc memorizzato nel database; quelli che non sanno assolutamente nulla di MVC nonostante sia uscito da diversi anni ormai.