¿Por qué el uso de abstracciones (como LINQ) es tan tabú? [cerrado]

Soy un contratista independiente y, como tal, entrevisto 3-4 veces al año para nuevos conciertos. Ahora estoy en medio de ese ciclo y me rechazaron por una oportunidad, aunque sentí que la entrevista salió bien. Lo mismo me ha pasado un par de veces este año.

Ahora, no soy un chico perfecto y no espero ser una buena opción para cada organización. Dicho esto, mi promedio de bateo es más bajo de lo habitual, por lo que cortésmente le pedí a mi último entrevistador algunos comentarios constructivos, ¡y él respondió!

Según el entrevistador, lo principal era que parecía inclinarme demasiado hacia el uso de abstracciones (como LINQ) en lugar de hacia algoritmos de menor nivel y de crecimiento orgánico.

En la superficie, esto tiene sentido; de hecho, también tiene sentido que los otros rechazos tengan sentido porque también parloteé sobre LINQ en esas entrevistas y no parecía que los entrevistadores supieran mucho sobre LINQ (a pesar de que eran .NET chicos)

Así que ahora me queda esta pregunta: si se supone que debemos estar "parados sobre los hombros de gigantes" y usar abstracciones disponibles para nosotros (como LINQ), ¿por qué algunas personas lo consideran tan tabú? ¿No tiene sentido sacar el código "de la plataforma" si logra los mismos objetivos sin costo adicional?

Me parece que LINQ, incluso si es una abstracción, es simplemente una abstracción de los mismos algoritmos que uno escribiría para lograr exactamente el mismo fin. Solo una prueba de rendimiento podría decirle si su enfoque personalizado fue mejor, pero si algo como LINQ cumplió con los requisitos, ¿por qué molestarse en escribir sus propias clases en primer lugar?

No quiero centrarme en LINQ aquí. Estoy seguro de que el mundo JAVA tiene algo comparable, solo me gustaría saber por qué algunas personas se sienten tan incómodas con la idea de utilizar una abstracción que ellos mismos no escribieron.

ACTUALIZAR

Como señaló Euphoric, no hay nada comparable a LINQ en el mundo Java. Entonces, si está desarrollando en la pila .NET, ¿por qué no siempre intenta usarla? ¿Es posible que las personas simplemente no entiendan completamente lo que hace?

No creo que sea objetable el uso de abstracciones per se. Hay otras dos posibles explicaciones. Una es que todas las abstracciones tienen fugas en un momento u otro. Si da la impresión, correcta o no, de que no comprende los fundamentos subyacentes, eso podría reflejarse mal en una entrevista.

La otra explicación posible es el efecto fanboy. Si habla con entusiasmo sobre LINQ y lo menciona repetidamente en una entrevista con una compañía que no lo usa y no tiene planes actuales para hacerlo, da la impresión de que no estaría satisfecho o incluso disgustado por trabajar con tecnologías más antiguas. También puede dar la impresión de que su entusiasmo por un producto lo ha cegado a las alternativas.

Si realmente cree que sería feliz en una tienda no LINQ, trata de preguntarle acerca de lo que no usan, y adaptar sus respuestas en consecuencia. Muéstreles que, si bien prefiere LINQ, es competente en el uso de las herramientas disponibles.

Algunos programadores .NET, particularmente aquellos que provienen de un fondo clásico de VB / ASP o C ++, no les gustan las cosas nuevas como LINQ, MVC y Entity Framework.

Según lo que he observado, es probable que los ex VB'ers de este grupo sigan utilizando capas de acceso a datos y otro código originalmente escrito hace más de 10 años. También usarán palabras de moda antiguas como "n-tier" y similares, y realmente no entenderán nada más allá de .NET Framework 2.0 ni quieren aprender nada al respecto.

Los C ++ tienden a ser programadores académicamente orientados que aman codificar algoritmos geniales, incluso si eso significa reinventar la rueda. Odian depender de cualquier cosa que no hayan entregado ellos mismos. Algunas de estas personas también se deleitan en hacer que los entrevistados se sientan inferiores, especialmente aquellos con antecedentes menos tradicionales.

Es probable que te encuentres con organizaciones como esta cuando estés entrevistando. Pero también se encontrará con algunos que están usando métodos más nuevos. No dejes que algunas malas entrevistas te desanimen.

Microsoft tiene una larga historia de presentar nuevas tecnologías y luego olvidarse de ellas 5, 10 o 20 años después. LINQ podría parecer otro para algunas personas. Notarán que Microsoft no puede desaprobar SQL, pero LINQ podría estar siguiendo a Silverlight . Por lo tanto, podría estar viendo paranoia como resultado de una experiencia dura, o simplemente personas que han sido dejadas atrás por la tecnología moderna y que se resienten de ella.

¿No tiene sentido sacar el código "de la plataforma" si logra los mismos objetivos sin costo adicional?

Siempre hay un costo extra.

La curva de aprendizaje para las cosas listas para usar siempre está ahí. El dolor de recibir actualizaciones (y dependencias) siempre está ahí. La incapacidad de atornillar las tripas siempre está ahí.

Para LINQ, el primero solo se aplica realmente. Muchas personas consideran que el código de aspecto 'extraño' es difícil de leer y más difícil de depurar. La sintaxis tipo sql es prácticamente una persona no grata en cada concierto profesional que he trabajado desde que salió. LINQ to SQL (y otras fuentes de datos) tienen varias trampas y opciones de optimización limitadas.

Estos son los argumentos generales contra herramientas de terceros y LINQ específicamente. Dicho todo esto, LINQ es una herramienta muy útil y debería preferirse en la mayoría de las situaciones. El llanto no inventado aquí, y las abstracciones no deben ser favorecidas, huele fuertemente a la disonancia cognitiva .

No saben / no pueden aprender LINQ, pero son "obviamente" buenos desarrolladores, por lo que LINQ no debe valer la pena. Es una trampa común.

Otra cosa que debes considerar es que tu entusiasmo por una nueva tecnología genial simplemente puede hacer que las personas se sientan incómodas y no te quieran. No los estás "empoderando", porque eres tú quien conoce esta tecnología, no ellos. Incluso si ellos mismos no se dan cuenta, pueden estar buscando candidatos que refuercen lo que ya han invertido tanto tiempo.

Desea presentar una actitud que diga: "Lo que sea que esté haciendo, quiero ayudarlo a lograrlo", en lugar de dar un subtexto que diga: "Puede que esté haciendo las cosas mal, y tenerme cerca demostrará eso."

Mi opinión sobre esto (y TBH, supongo porque ninguno de nosotros puede decir lo que pensaban esos entrevistadores) es que a menudo vas a una entrevista para explicar por qué deberían contratarte para encajar con su equipo, su forma de trabajar .

Puedes ser el desarrollador perfecto, un dios del código de inicio de rock, pero eso no significa absolutamente nada si lo que quieres hacer (enfatizado por hablar en exceso y con demasiado entusiasmo sobre algunos gubbins de tecnología genial) simplemente les dice acerca de ti, y que no lo harías encajan con lo que quieren. Si tienen un sistema de acceso a datos antiguo, que no puede actualizarse por cualquier razón, no necesitan a alguien que haya olvidado cómo mantenerlo. Si están desarrollando cosas nuevas y realmente quieres poner esa nueva tecnología genial en todas partes, entonces es obvio que tendrán un gran problema con el mantenimiento de código futuro y / o la capacitación del personal.

Como profesional independiente, este es un problema mucho mayor que si estuvieran contratando a un permie. Con un permiso permanente, la capacitación y el desarrollo de nuevas formas de trabajo no son malas, dentro del alcance del código y las prácticas existentes: estará allí durante mucho tiempo para mejorar las cosas. Con un profesional independiente, realmente no le importa lo que quieres, estás allí solo para hacer su trabajo de la manera en que quieren que se haga, y no es tu trabajo hacer otra cosa. (en desacuerdo - conviértase en un empleado permanente)

Probablemente no tenga nada que ver con LINQ en sí, rechacé a un candidato que apareció y le explicó cuánto mejor se escribiría todo en Haskell. Nosotros no hacemos Haskell. Lo mismo se aplica a cualquier tecnología que no sea utilizada por la compañía, generalmente no es un problema si la mencionas como algo bueno. El problema surge cuando eres demasiado entusiasta y entusiasta.

Hay una preocupación válida que he escuchado de aquellos que no usan Linq, y es una que tomo muy en serio: "El hecho de que no pueda ver la implementación no significa que no sea costosa".

Tome el siguiente fragmento:

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

Los iniciados por LINQ aquí son estremecedores. ¿Por qué? Porque el hecho de que este código se vea agradable y elegante no significa que no sea terriblemente ineficiente. Count (), con un predicado, evalúa cada elemento de su padre enumerable y resume las veces que el predicado devuelve verdadero. Entonces, esto no solo es N ^ 2 (cuando inputList y otherInputList tienen una cardinalidad N aproximadamente igual), es el peor caso absoluto N ^ 2; CADA elemento de otherInputList se recorre para CADA elemento de entrada. En cambio, el primer paso es usar Any () en lugar de Count, porque eso es realmente lo que quieres saber, y se cerrará tan pronto como se sepa que la respuesta es "sí". Configurar un HashSet que almacena valores distintos de otherInputListObject.OtherPropertypodría ayudarte también; el acceso se convierte en O (1) en lugar de O (N),complejidad del peor de los casos en lugar de la complejidad cuadrática del mejor de los casos .

Por lo tanto, vemos que estos métodos elegantes y agradables tienen costos importantes detrás de ellos, y si no sabe cuáles son esos costos, puede codificar fácilmente un algoritmo de complejidad O (mi GD) en el administrador de archivos central de alto rendimiento de su posible empleador o la página principal del portal de aterrizaje la próxima vez que necesiten un ajuste. Despidiéndote después de hacer eso no deshace lo que hiciste, pero no contratarte si piensan que lo harías lo evitaría. Entonces, para evitar esto, debes demostrar que están equivocados; discuta qué hacen esos métodos (lo que significa que debe conocerse a sí mismo) y su complejidad, y cómo llegar a la respuesta en un tiempo eficiente (NlogN o mejor).

Otra preocupación es el viejo argumento "Cuando tu única herramienta es un martillo". Ponte en el lugar del entrevistador que entrevista a este fanático de Linq. Al candidato le gusta Linq, quiere usarlo, piensa que es lo mejor. Incluso podría parecer que el candidato no podría codificar sin él, ya que todos los problemas de programación dados se resolvieron con Linq. Bueno, ¿qué pasa cuando no se puede usar? Todavía hay un montón de código .NET 2.0, que si se actualizara requeriría actualizaciones dolorosas para servidores, estaciones de trabajo de usuarios, etc., todo para que pueda usar sus sofisticados métodos de extensión. Como entrevistador, trataría de hacer que demuestre que puede codificar una clasificación eficiente o usar los métodos de clasificación 2.0 si fuera necesario, sin importar cuánto esté de acuerdo con usted en que las bibliotecas Linq y los métodos de extensión similares son bastante dulce. Es posible que un entrevistador que no ve el punto ni siquiera se moleste en intentar que muestre aptitud para cualquier otra cosa; Asumirán que no lo tienes y seguirán adelante.

Este se hizo un poco largo, pero podría ser útil para alguien, así que lo dejaré ser.

En realidad encontré algo similar, pasando por un poco más de 20 entrevistas el mes pasado (una combinación de teléfono y cara a cara). Definitivamente sucedió algo inesperado que no pude identificar.

Sin embargo, una de las cosas que noté fue que las cosas que generalmente han sido el punto central de los ciclos de entrevistas de los últimos cinco o seis años decididamente no se discutieron ni se les dio poca importancia. Cosas como los fundamentos del análisis / diseño de OOP, patrones (diseño y arquitectura, ambos), algunas de las características .net más avanzadas / orientadas a la abstracción (incluidas lambdas o LINQ específicamente, genéricos, serialización / enlace de datos y similares), e incluso el Por lo general, tema candente de la metodología preferida (a nadie parecía importarle mucho lo ágil frente a la cascada o qué sabor de ágil) y las herramientas o la elección de ORM o los medios preferidos de colaboración o gestión de control de fuente. En algunos casos no se menciona en absoluto, en casi todos los casos aparentemente no preocupan.

Lo que sí recibió atención, en múltiples entrevistas y en varias empresas no relacionadas en industrias no relacionadas, fue en este sentido:

• Una extraña fijación en convenciones anticuadas / anticuadas y limitaciones de "volver a la edad de piedra". Como desarrollar una aplicación web primitiva en VS2003 con una lista de restricciones absurdas que prohíben aún más el uso de características explícitas dentro de esa era de .net ... como si eso fuera un indicador real de la capacidad de un desarrollador moderno ... la capacidad de recordar El paradigma y las limitaciones de hace 9 años quedaron paralizados por limitaciones poco realistas / arbitrarias. Otro lugar fue muy obstinado sobre el tema de las colecciones personalizadas, alrededor de las colecciones pregenéricas. Otro lugar creó una muestra de código de un modelo de clase que garabateé porque no utilicé constructores en cascada (parecían ignorar el soporte para la inicialización de propiedades en la declaración, que era suficiente para la necesidad).

• Enfoque extremo en detalles de implementación específicos en un microcosmos y / o ajustes de configuración, incluso en el caso de tecnologías que se enfocan en ser independientes de la plataforma o el protocolo (es decir, el punto principal NO debe fijarse en una implementación específica o uso particular, sino más bien sobre reutilización / reutilización / extensibilidad / según la integración necesaria).

• Disponibilidad para especificar / supervisar / revisar el código / y, de lo contrario, desconectar el trabajo hacia y desde un equipo off-shore, y habilidades no relacionadas con la codificación relacionadas con hacerlo.

• Uso de versiones específicas de productos / plataformas / módulos / etc. Hasta un grado a veces absurdo; "Entonces ... ¿has usado las versiones 1, 2 y 4? Pero no 3, ¿eh? Hmmm ... {anota tu currículum con" no v3 !!!} ". El grado de uso no parecía importar; solo que ha usado o no ha usado algo en absoluto , y lo específico que están pidiendo también ... ninguna sustitución parecía contar, incluso de un producto de la competencia más ampliamente utilizado y con más funciones.

• Un enfoque mucho mayor en "qué tan bien encajará en nuestro equipo" sobre "si realmente es bueno como desarrollador de software" o "¿tiene las habilidades y la experiencia para agregar valor a la empresa y ayudarnos a ofrecer una calidad producto "o incluso" eres un idiota peligroso que entrará y destrozará la tienda ". En algunos casos, mi currículum simplemente se tomó como un hecho, e incluso la llamada "pantalla técnica" o entrevista técnica fue una evaluación de la personalidad mucho más que una evaluación de habilidades. Incluso para puestos de contrato a corto plazo en los que estaría allí y volvería antes de que hayan cambiado dos temporadas.

• Esta vez, las empresas parecían centrarse mucho menos en resolver problemas técnicos específicos, comenzar nuevos proyectos de desarrollo de campo verde o grandes 2.0, o llevar un producto específico al mercado para capitalizar una tendencia u oportunidad emergente, o las grandes patadas iniciales habituales . Un tema repetitivo que noté al menos en 15 de los lugares fue que un pequeño grupo de 3-5 desarrolladores, en su mayoría sobrevivientes del colapso del mercado en 08, pudieron elaborar un producto en el transcurso de los últimos 3 años más o menos. y encontraron cierto éxito o su empresa en su conjunto está en auge y están contratando a nuevas personas para mantenerse al día con las crecientes demandas de características o para abordar / superar los defectos de diseño que incorporaron en estos sistemas, o para hacerse cargo de las plataformas antes mencionadas para liberar hasta el equipo central que lo creó para hacer "otros proyectos".

Pero ... si hay algo que sé sobre este negocio es que es cíclico. La próxima vez que busque un nuevo concierto, no me sorprenderá si el juego ha cambiado una vez más. Solo tiene que permanecer mentalmente flexible, escuchar activamente, evitar hacer declaraciones absolutas si son innecesarias, pero tampoco ser una comadreja y no parecer unidimensional (usted viene como un idiota o un fanático, ni deseable) o como demasiado bueno (puede ser amenazante y costarle un concierto).

Simplemente ajuste su enfoque e intente dar una respuesta más mesurada la próxima vez ... mencione algunas formas diferentes en que podría abordar un problema ... pero incluso si se trata de un conocimiento memorístico, actúa como si realmente estuviera pensando en ello y razonándolo en el acto. Parece más humilde y menos intimidante o ofensivo de esa manera.

Por supuesto, la ley de Murphy siendo lo que es, la siguiente entrevista después de que deje de ser "un apasionado de mi actual tipo de tecnología favorita" y adoptar una postura más equilibrada / barba de acariciar es el concierto que le han metido te fuese el loco fanático ;)

Creo que está sacando una conclusión falsa, porque su conjunto de muestras es demasiado limitado. Aunque he visto una buena cantidad de tiendas de TI con fuerte aversión a cualquier cosa "no inventada allí" ¹ , ninguno de ellos descalificaría a los candidatos en función de sus preferencias en la pila de tecnología: estaban legítimamente convencidos de que podían enseñar al candidato correcto a usar sus bibliotecas locales.

Dudo seriamente que la compañía haya prohibido el uso de LINQ directamente. Lo más probable es que quisieran que les mostraras tus habilidades a un nivel más profundo.

Por ejemplo, una forma de averiguar si conoce sus tablas hash es pedirle que implemente una primitiva en una pizarra. Este simple ejercicio revela una sorprendente cantidad de datos sobre su conocimiento al revisor: él aprende instantáneamente si sabe acerca de los códigos / iguales de hash, y lo que sabe sobre las colisiones de hash. Al mismo tiempo, es difícil imaginar que alguien en su sano juicio vuelva a implementar una tabla hash, porque Microsoft hizo un buen trabajo en ello. Lo mismo ocurre con muchos algoritmos, como ordenar y buscar: a los entrevistadores a menudo les gustaría saber si su experiencia es suficiente para comprender las interacciones de bajo nivel, en lugar de verificar que tiene un conocimiento práctico de las bibliotecas .NET.

Es casi seguro que insistirán en que use implementaciones de biblioteca en lugar de la suya una vez que lo contraten para trabajar para su empresa. Pero durante la entrevista lo empujarían hacia el código de bajo nivel para obtener una mejor comprensión de sus verdaderas habilidades.

Creo que estás haciendo algunas generalizaciones locas del tipo "Vi una vaca negra en Escocia, así que todas las vacas escocesas son negras".

Si te entrevistara, me decepcionaría si no pudieras responder mis preguntas linq.

Sin embargo, Linq es complicado, mucha gente lo ve como vudú, lo cual es injusto, ya que en realidad es muy simple y aún más inteligente.

Para jugar al abogado del diablo, la razón es que muchos desarrolladores simplemente no se preocupan por las cosas nuevas y piensan que todo tiene que resolverse con herramientas propias (generalmente inferiores). No hay nada de malo en usar abstracciones. Demonios, generalmente no hay una buena razón para no usar esas abstracciones.

Parece que se entrevistó con un desarrollador pobre que no se mantiene al día con las cosas y adopta el enfoque de martillo y clavo para todo. Estos son los tipos de desarrolladores que no saben nada sobre herramientas útiles de código abierto como NUnit, o NHibernate, o los diversos contenedores de IoC; los que intentan resolver cada problema con un proceso masivo almacenado en la base de datos; los que no saben absolutamente nada sobre MVC a pesar de estar fuera desde hace varios años.