Por que o uso de abstrações (como LINQ) é tão tabu? [fechadas]

Sou um contratado independente e, como tal, entrevisto 3-4 vezes por ano para novos shows. Estou no meio desse ciclo agora e fui recusado por uma oportunidade, apesar de sentir que a entrevista foi bem. O mesmo aconteceu comigo algumas vezes este ano.

Agora, não sou um cara perfeito e não espero ser uma boa opção para todas as organizações. Dito isto, minha média de rebatidas é menor que o normal, então eu pedi educadamente ao meu último entrevistador algum feedback construtivo, e ele entregou!

O principal, de acordo com o entrevistador, era que eu parecia me inclinar muito mais para o uso de abstrações (como o LINQ), em vez de para algoritmos de baixo nível, cultivados organicamente.

Aparentemente, isso faz sentido - na verdade, também fez outras rejeições porque eu também falei sobre o LINQ nessas entrevistas e não parecia que os entrevistadores sabiam muito sobre o LINQ (mesmo sendo .NET. rapazes).

Portanto, agora fico com esta pergunta: se devemos estar "de pé sobre os ombros dos gigantes" e usar abstrações que estão disponíveis para nós (como o LINQ), por que algumas pessoas consideram isso um tabu? Não faz sentido retirar o código "da prateleira" se ele atingir os mesmos objetivos sem custo adicional?

Parece-me que o LINQ, mesmo que seja uma abstração, é simplesmente uma abstração de todos os mesmos algoritmos que alguém escreveria para realizar exatamente o mesmo fim. Somente um teste de desempenho poderia dizer se sua abordagem personalizada era melhor, mas se algo como o LINQ atendia aos requisitos, por que se preocupar em escrever suas próprias classes em primeiro lugar?

Não pretendo me concentrar no LINQ aqui. Tenho certeza de que o mundo JAVA tem algo comparável. Gostaria apenas de saber por que algumas pessoas ficam tão desconfortáveis ​​com a ideia de usar uma abstração que elas mesmas não escreveram.

ATUALIZAR

Como eufórico apontou, não há nada comparável ao LINQ no mundo Java. Então, se você está desenvolvendo na pilha do .NET, por que nem sempre tentar usá-lo? É possível que as pessoas simplesmente não entendam completamente o que isso faz?

Eu não acho que é o uso de abstrações per se que seja censurável. Existem duas outras explicações possíveis. Uma é que todas as abstrações estão vazando uma vez ou outra. Se você der a impressão, correta ou não, de que não entende os fundamentos subjacentes, isso pode refletir mal em uma entrevista.

A outra explicação possível é o efeito fanboy. Se você fala com entusiasmo sobre o LINQ e o apresenta repetidamente em uma entrevista com uma empresa que não o usa e não possui planos atuais, isso dá a impressão de que você ficaria insatisfeito ou até mesmo descontente ao trabalhar com tecnologias mais antigas. Também pode dar a impressão de que seu entusiasmo por um produto o cegou para alternativas.

Se você realmente acha que ficaria feliz em uma loja não-LINQ, tente perguntar sobre o que eles não usar e adaptar as suas respostas em conformidade. Mostre a eles que, embora prefira o LINQ, você é competente usando as ferramentas disponíveis.

Alguns programadores .NET, particularmente aqueles provenientes de um background clássico de VB / ASP ou C ++, não gostam de coisas novas como LINQ, MVC e Entity Framework.

Com base no que observei, é provável que os ex-VB'ers deste grupo ainda estejam usando camadas de acesso a dados e outro código originalmente escrito há mais de 10 anos. Eles também usam chavões antigos, como "n-tier" e similares, e realmente não entendem nada além de .NET Framework 2.0, nem desejam aprender nada sobre isso.

Os C ++ tendem a ser programadores academicamente orientados que adoram codificar algoritmos legais, mesmo que isso signifique reinventar a roda. Eles odeiam, dependendo de qualquer coisa que não tenham entregue o código. Algumas dessas pessoas também gostam de fazer com que os entrevistados se sintam inferiores, especialmente aqueles com um histórico menos tradicional.

É provável que você encontre organizações como essa ao entrevistar. Mas você também encontrará alguns que estão usando métodos mais novos. Não deixe que algumas entrevistas ruins o joguem fora.

A Microsoft tem uma longa história de lançar novas tecnologias quentes e depois esquecê-las 5, 10 ou 20 anos depois. O LINQ pode parecer outro para algumas pessoas. Eles observam que a Microsoft não pode descontinuar o SQL, mas o LINQ pode estar seguindo o Silverlight . Assim, você pode ver a paranóia resultante de uma experiência difícil ou apenas pessoas que foram deixadas para trás pela tecnologia moderna e que se ressentem.

Não faz sentido retirar o código "da prateleira" se ele atingir os mesmos objetivos sem custo adicional?

Sempre há um custo extra.

A curva de aprendizado para coisas prontas está sempre lá. A dor de obter atualizações (e dependências) está sempre lá. A incapacidade de mexer nas entranhas está sempre presente.

Para o LINQ, o primeiro realmente se aplica. Muitas pessoas consideram o código com aparência "estranha" difícil de ler e de depurar. A sintaxe do tipo sql é praticamente persona-non-grata em todos os shows profissionais que trabalhei desde que foram lançados. O LINQ to SQL (e outras fontes de dados) tem várias dicas e opções limitadas de otimização.

Esses são os argumentos gerais contra as ferramentas de terceiros e o LINQ especificamente. Tudo isso dito, o LINQ é uma ferramenta útil e deve ser preferida na maioria das situações. O choro não inventado aqui, e as abstrações não devem ser favorecidas cheira fortemente à dissonância cognitiva .

Eles não sabem / não podem aprender o LINQ, mas são "obviamente" bons desenvolvedores, portanto o LINQ não deve valer a pena. É uma armadilha comum.

Outra coisa que você deve considerar é que seu entusiasmo por uma nova tecnologia legal pode simplesmente fazer as pessoas se sentirem desconfortáveis ​​e não quererem você por perto. Você não está "capacitando" eles, porque é você quem conhece essa tecnologia, não eles. Mesmo que eles próprios não percebam isso, eles podem estar procurando candidatos que reforcem o que já investiram tanto tempo.

Você deseja apresentar uma atitude que diz: "O que você estiver fazendo, eu quero ajudá-lo a alcançá-la", em vez de fornecer um subtexto que diz: "Você pode estar fazendo as coisas de um jeito ruim, e ter-me por perto provará isto."

Minha opinião sobre isso (e TBH, eu acho, porque nenhum de nós pode dizer o que esses entrevistadores estavam pensando) é que frequentemente você vai a uma entrevista para explicar por que eles deveriam contratá-lo para se encaixar na equipe deles, na maneira de trabalhar deles .

Você pode ser o desenvolvedor perfeito, um deus do código inicial, mas isso não significa absolutamente nada se o que você quer fazer (enfatizado por você falar excessivamente e com muito entusiasmo sobre alguns gubbins legais de tecnologia) simplesmente lhes diz sobre você e que você não faria isso se encaixam com o que eles querem. Se eles têm um sistema de acesso a dados de estilo antigo, que não pode ser atualizado por qualquer motivo, não precisam de alguém que se esqueceu de como mantê-lo. Se eles estão desenvolvendo coisas novas e você realmente deseja colocar essa nova tecnologia legal em todos os lugares, é óbvio que eles terão um grande problema com a manutenção futura do código e / ou o treinamento da equipe.

Como freelancer, isso é muito mais problemático do que se eles estivessem contratando uma permissão. Com uma permissão, o treinamento e o desenvolvimento de novas formas de trabalhar não são coisas ruins, dentro do escopo do código e das práticas existentes - você estará lá por um longo tempo para melhorar as coisas. Com um freelancer, eles realmente não dão a mínima para o que você quer, você está lá apenas para fazer o trabalho da maneira que eles querem, e não é seu trabalho fazer qualquer outra coisa. (discordo - torne-se um funcionário permanente)

Provavelmente não tem nada a ver com o LINQ, rejeitei um candidato que apareceu e expliquei o quanto tudo seria melhor escrito em Haskell. Nós não fazemos Haskell. O mesmo se aplica a qualquer tecnologia que não seja usada pela empresa, geralmente não é um problema se você mencionar como algo bom. O problema surge quando você está entusiasmado e interessado demais.

Há uma preocupação válida que ouvi daqueles que não usam o Linq, e é uma que eu tenho em mente: "Só porque você não pode ver a implementação não significa que não é caro".

Pegue o seguinte trecho:

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

Os iniciados por LINQ aqui estão se encolhendo. Por quê? Porque apenas porque esse código parece bonito e elegante, não significa que não seja terrivelmente ineficiente. Count (), com um predicado, avalia todos os elementos de seu pai enumerável e resume as vezes que o predicado retornou verdadeiro. Portanto, não é apenas este N ^ 2 (quando inputList e otherInputList são aproximadamente iguais à cardinalidade N), é o pior caso absoluto N ^ 2; TODOS os elementos de otherInputList são percorridos para TODOS os elementos de entrada. Em vez disso, o primeiro passo é usar Any () em vez de Count, porque é isso que você realmente quer saber, e ele será encerrado assim que a resposta for "sim". A configuração de um HashSet que armazena valores distintos também otherInputListObject.OtherPropertypode ajudá-lo; o acesso se torna O (1) em vez de O (N),complexidade de pior caso em vez de complexidade quadrática de melhor caso .

Portanto, vemos que esses métodos elegantes e agradáveis ​​têm sérios custos por trás deles, e se você não sabe quais são esses custos, pode codificar com facilidade um algoritmo de complexidade O (meu GD) no servidor de arquivos central de alto desempenho de seu empregador em potencial ou na página principal do portal de destino na próxima vez em que precisar de um ajuste. Demitir você depois de fazer isso não desfaz o que você fez, mas não contratá-lo se eles acharem que você faria isso impediria. Portanto, para evitar isso, você deve provar que estão errados; discuta o que esses métodos fazem (o que significa que você precisa conhecer a si mesmo) e sua complexidade, e como chegar à resposta em um tempo eficiente (NlogN ou melhor).

Outra preocupação é o bom e velho argumento "Quando sua única ferramenta é um martelo". Coloque-se no lugar do entrevistador entrevistando esse fanboy do Linq. O candidato gosta do Linq, quer usá-lo, acha que é a melhor coisa do mundo. Pode até parecer que o candidato não poderia codificar sem ele, pois todos os problemas de programação fornecidos foram resolvidos com o Linq. Bem, o que acontece quando não pode ser usado? Muitos códigos do .NET 2.0 ainda estão por aí, que, se fossem atualizados, exigiriam atualizações dolorosas para servidores, estações de trabalho de usuários, etc etc, tudo para que você possa usar seus métodos de extensão sofisticados. Como entrevistador, eu tentaria mostrar que você poderia codificar uma classificação eficiente ou usar os métodos de classificação 2.0, se necessário, não importa o quanto eu concorde com você que as bibliotecas Linq e os métodos de extensão semelhantes são bastante doce. Um entrevistador que não entende o ponto pode nem se importar em tentar fazer com que você mostre aptidão para qualquer outra coisa; eles assumem que você não o tem e seguem em frente.

Este ficou um pouco longo, mas pode ser útil para alguém, então eu deixarei.

Na verdade, encontrei algo semelhante, passando por pouco mais de 20 entrevistas no mês passado (uma mistura de telefone e face a face). Definitivamente, havia algo inesperado acontecendo que eu não conseguia entender.

Uma das coisas que notei, porém, foi que as coisas que geralmente têm sido o ponto central dos ciclos de entrevistas dos últimos cinco ou seis anos não foram decididamente discutidas ou pouco estudadas. Coisas como os fundamentos da análise / design de OOP, padrões (ambos de design e arquitetura), alguns dos recursos .net mais avançados / voltados para abstração (incluindo lambdas ou LINQ especificamente, genéricos, serialização / ligação de dados e similares) e até o tópico geralmente quente da metodologia preferida (ninguém parecia se importar muito com ágil versus cascata ou que sabor é ágil) e ferramentas ou escolha de ORM ou meios preferidos de colaboração ou gerenciamento de controle de origem. Em alguns casos não mencionados, em quase todos os casos aparentemente não preocupam.

O que recebeu o foco, em várias entrevistas e várias empresas não relacionadas em setores não relacionados, foi o seguinte:

• Uma fixação estranha em convenções desatualizadas / fora de moda e limitações "de volta à idade da pedra". Como desenvolver um aplicativo Web primitivo no VS2003 com uma lista de restrições absurdas, proibindo ainda mais o uso de recursos explícitos naquela era do .net ... como se esse fosse um medidor real da capacidade de desenvolvedores modernos ... a capacidade de lembrar o paradigma e as limitações de 9 anos atrás, ainda mais prejudicados por restrições irrealistas / arbitrárias. Outro lugar era muito obstinado em matéria de coleções personalizadas, por volta de coleções pré-genéricas. Outro local exibiu uma amostra de código de um modelo de classe que eu rabisquei porque não usei construtores em cascata (eles pareciam desconhecer o suporte à inicialização da propriedade na declaração, o que era suficiente para a necessidade).

• Foco extremo em detalhes específicos da implementação em um microcosmo e / ou definições de configuração, mesmo no caso de tecnologias focadas em agnóstico de plataforma ou protocolo (ou seja, o ponto principal é NÃO se fixar em uma implementação específica ou uso específico, mas sim reutilização / reutilização / extensibilidade / conforme a integração necessária).

• Disposição de especificar / supervisionar / revisar o código / e de outro modo afastar o trabalho de e para uma equipe offshore, além de habilidades de não codificação relacionadas a isso.

• Uso de versões específicas de produtos / plataformas / módulos / etc. Até um grau às vezes absurdo; "Então ... você usou as versões 1, 2 e 4? Mas não 3, hein? Hmmm ... {faz anotações no seu currículo com" no v3 !!!} ". O grau de uso não parecia importar; só que você tem ou não ter usado algo em tudo , ea coisa específica que eles estão pedindo também ... não substituições pareciam contar, até mesmo de um produto concorrente mais amplamente utilizado e com todos os recursos.

• Uma quantidade muito maior de foco em "quão bem você vai se encaixar na nossa equipe" sobre "você é realmente bom como desenvolvedor de software" ou "você tem as habilidades e a experiência necessárias para agregar valor à empresa e nos ajudar a oferecer uma qualidade?" produto "ou até" você é um idiota perigoso que entra e destrói a loja ". Em alguns casos, meu currículo era apenas um dado adquirido, e até a chamada "tela técnica" ou entrevista técnica era uma avaliação da personalidade muito mais do que uma avaliação de habilidades. Mesmo para posições de contrato relativamente de curto prazo, onde você estaria lá e voltaria antes que duas temporadas mudassem.

• Desta vez, as empresas pareciam ter muito menos foco na solução de problemas técnicos específicos, iniciando novos projetos de desenvolvimento green-field ou grandes 2.0, ou lançando um produto específico no mercado para capitalizar uma tendência ou oportunidade emergente ou os grandes arranques habituais . Um tema repetido que notei em pelo menos 15 dos locais foi que um pequeno grupo de 3 a 5 desenvolvedores, a maioria sobreviventes da queda do mercado em 08, conseguiu moer um produto ao longo dos últimos três anos. e encontraram algum sucesso ou a empresa como um todo está crescendo e eles estão contratando novos funcionários para acompanhar as crescentes demandas de recursos ou para resolver / superar as falhas de design que incorporaram a esses sistemas ou para assumir as plataformas mencionadas para liberar criar a equipe principal que a criou para realizar "outros projetos".

Mas ... se há uma coisa que eu sei sobre esse negócio é que é cíclico. Na próxima vez que eu estiver procurando por um novo show, não ficarei surpreso se o jogo mudar novamente. Você só precisa permanecer mentalmente flexível, ouvir ativamente, evitar fazer declarações absolutas se elas forem desnecessárias, mas também não são uma doninha e não são unidimensionais (você é um idiota ou um fanático, nem desejável) ou como sendo muito bom (pode ser ameaçador e custar um show).

Apenas ajuste sua abordagem e tente dar uma resposta mais ponderada na próxima vez ... mencione algumas maneiras diferentes de abordar um problema ... mas mesmo que seja um conhecimento rotineiro, você age como se estivesse realmente pensando nisso e raciocinar no local. Parece mais humilde e menos intimidador ou ofensivo dessa maneira.

É claro que a Lei de Murphy é o que é, a próxima entrevista depois que você deixa de ser "apaixonado pelo meu atual cara favorito da tecnologia" e adota uma postura mais equilibrada / com barba é o show que você teria se tivesse ficado louca cara fanático. ;)

Acho que você está tirando uma conclusão falsa, porque seu conjunto de amostras é muito limitado. Embora eu tenha visto uma parcela justa de lojas de TI com forte aversão a qualquer coisa "não inventada lá" ¹ , nenhuma delas desqualificaria os candidatos com base em suas preferências na pilha de tecnologias: eles estavam legitimamente convencidos de que poderiam ensinar o candidato certo a usar suas bibliotecas caseiras.

Eu duvido seriamente que a empresa tenha banido o uso do LINQ completamente. Provavelmente, eles queriam que você lhes mostrasse suas habilidades em um nível mais profundo.

Por exemplo, uma maneira de descobrir se você conhece suas tabelas de hash é pedir para implementar uma primitiva em um quadro branco. Este exercício simples revela uma quantidade surpreendente de dados sobre seu conhecimento para o revisor: ele aprende instantaneamente se você sabe sobre código de hash / iguais e o que você sabe sobre colisões de hash. Ao mesmo tempo, é difícil imaginar alguém em sã consciência reimplementando uma tabela de hash, porque a Microsoft fez um bom trabalho nela. O mesmo vale para muitos algoritmos, como classificação e pesquisa: os entrevistadores geralmente desejam saber se sua experiência é suficiente para entender interações de baixo nível, em vez de verificar se você possui um conhecimento prático das bibliotecas .NET.

É quase certo que eles insistiriam em que você usasse implementações de bibliotecas, e não as suas, quando for contratado para trabalhar na empresa deles. Mas, durante a entrevista, eles o empurrariam para o código de baixo nível, a fim de obter uma melhor compreensão de suas verdadeiras habilidades.

Acho que você está fazendo algumas generalizações loucas do tipo "eu vi uma vaca preta na Escócia, então todas as vacas escocesas são negras".

Se eu o entrevistei, ficaria desapontado se você não pudesse responder minhas perguntas do linq.

No entanto, o Linq é complicado, muitas pessoas o veem como vodu, o que é injusto, pois na verdade é muito simples e ainda mais inteligente.

Para bancar o advogado do diabo, a razão é que muitos desenvolvedores simplesmente não se importam com coisas novas e pensam que tudo precisa ser resolvido com ferramentas domésticas (geralmente inferiores). Não há nada de errado em usar abstrações. Inferno, geralmente não há boas razões para não usar essas abstrações.

Parece que você acabou de entrevistar um desenvolvedor ruim que não se mantém atualizado com as coisas e adota a abordagem de martelo e prego em tudo. Esses são os tipos de desenvolvedores que não sabem nada sobre ferramentas úteis de código aberto, como NUnit, NHibernate ou vários contêineres IoC; aqueles que tentam resolver todos os problemas com um processo armazenado em massa no banco de dados; aqueles que não sabem absolutamente nada sobre o MVC, apesar de já estar fora há vários anos.