¿Por qué la mayoría de las compañías de software no tienen ingenieros híbridos que realizan trabajos de desarrollo y control de calidad? Cazar Trabajos es un oficio

Hago una combinación de trabajo de desarrollo y control de calidad en Palantir Technologies. No es una pregunta simple de responder, pero aquí hay algunos pensamientos:

Razones prácticas

Es casi imposible el código de control de calidad que está cerca , ya sea que lo haya escrito o no. Naturalmente, crea un modelo de cómo debería funcionar el código, y es muy, muy difícil evitar sesgos que introducen. Básicamente, si conoce y confía en el código, solo verificará para asegurarse de que el código se comporta como cree que debería (que, por cierto, ya debería estar cubierto por pruebas automáticas). Hará suposiciones sobre lo que debería funcionar, y no piensa en todas las formas en que no podría funcionar, porque si lo hiciera, lo habría escrito para abordar esas preocupaciones. Es muy difícil (diría que básicamente imposible) superar este sesgo.
Un problema similar aunque separado es que, si ha escrito el código o está cerca del código, probablemente no sea el público objetivo del código . Hay algunas excepciones a esto (escribir código para otros desarrolladores con sus antecedentes exactos es el sueño de todo desarrollador), pero en la gran mayoría de los casos esto es cierto, incluso si su audiencia es altamente técnica. Se acerca al código sabiendo todos los fundamentos que lo integran y puede explicar las deficiencias o fallas que tiene. Esto es diferente del primer punto en que, si bien el primer punto se refiere a su capacidad para encontrar errores , este problema se aplica incluso si el código no tiene errores técnicos (¡ja!).
Aquí hay una analogía: digamos que tiene un doctorado en matemáticas, y alguien le pide que revise un libro de texto de cálculo de la escuela secundaria en busca de errores. Puede evaluar si el libro de texto es correcto o no, pero, dado que conoce el tema con mayor profundidad de lo que está escrito el libro de texto, esencialmente está ignorando una gran variedad de posibles problemas de los que simplemente no es consciente. Cuando lees una oración del libro, incluso si te esfuerzas por ponerte en el lugar de alguien que no conoce el material, tendrá sentido para ti, porque tienes más en común con el persona que lo escribió que la persona que lo leerá. Para probar realmente algo adecuadamente, debe abordarlo exactamente como lo haría su público objetivo, y ese es muy raro el caso en el desarrollo de software.

Razones culturales / orgánicas

Aunque tanto el desarrollo como el control de calidad suelen formar parte de una organización de ingeniería más grande, generalmente están bastante separados en la práctica, es decir, hay un liderazgo separado para cada uno. Ésto es una cosa buena. Hay un empuje natural entre dev (que quiere enviar el código) y QA (que quiere que el código que se envía sea lo mejor posible). Necesita personas en el mismo nivel para abogar por cada posición (para decisiones de proceso, etc.). Si dev es mucho más fuerte, enviarás basura; Si el control de calidad es mucho más fuerte, nunca enviarás. Debido a esto, generalmente son jerarquías totalmente separadas, por lo que existe una resistencia natural a hacer ambas cosas.
Para ser efectivo, debe haber una relación antagónica (saludable) entre los dos grupos. El objetivo principal del control de calidad es romper el código de desarrollo, y los buenos ingenieros de control de calidad a menudo disfrutan mucho al extraer una función en pedazos (no es que esperes que el código sea malo, pero quieres ser más inteligente que el dev era, piense en casos que no abordaron, etc.).
Las tuberías de contratación son totalmente diferentes. El reclutamiento de desarrolladores se optimiza para ciertas cosas, el reclutamiento de control de calidad se optimiza para otros. No interesa a ninguno de los grupos buscar personas que puedan hacer ambas cosas.

Razones personales

A menudo hay una preferencia personal bastante fuerte hacia QA o dev. Mucha gente entra en la programación porque quiere que mucha gente vea y use algo que hicieron, y generalmente no estarán contentos de hacer un trabajo de control de calidad. Mucha gente no se siente atraída por eso; Prefieren tener una influencia más indirecta (que a menudo puede ser significativamente más amplia), y están felices de saber que han tenido un gran impacto en el producto y la empresa. Definitivamente hay excepciones, pero muchos desarrolladores no serían buenos evaluadores, y muchos ingenieros de control de calidad no serían buenos desarrolladores.
Entre los que serían buenos en ambos, el desarrollo es a menudo la posición más atractiva. Los desarrolladores suelen tener mucho más respeto que los ingenieros de control de calidad, tanto interna como externamente. Esto se refleja de muchas maneras: sus salarios suelen ser significativamente más altos, se reclutan de manera mucho más agresiva (existe una percepción de competencia entre las empresas por los mejores desarrolladores que realmente no existe de la misma manera para el control de calidad), ellos ‘ son percibidos como más inteligentes, son vistos como la fuerza creativa detrás de los productos, etc. Es muy difícil reclutar para el control de calidad a tiempo completo de los 10 mejores programas de CS, y el control de calidad a menudo se ve como un paso por debajo de un desarrollador o una posición tomas si aún no eres lo suficientemente bueno como para ser un desarrollador. El trabajo de desarrollo generalmente se ve como más gratificante intelectualmente y menos repetitivo. Las tuberías de reclutamiento a menudo son preferenciales para los puestos de desarrollo si un candidato está calificado para ambos, ya que el desarrollo se considera una posición más difícil (desea que las personas se acostumbren a su máximo potencial, ¿verdad?).
Estas actitudes realmente apestan, y en la mayoría de las principales compañías, las suposiciones son casi completamente inexactas, pero aún persisten (algunas partes, especialmente en torno a la compensación y el reclutamiento, todavía parecen ser ciertas, lo cual es muy desafortunado y con suerte comenzará a cambiar). En general, especialmente para los graduados universitarios recientes, la percepción es que si puedes ser un desarrollador, simplemente no hay razón por la que quieras considerar una posición híbrida. Las personas que comienzan en el control de calidad que realmente querían puestos de desarrollo sienten que están escapando y no les interesa quedarse; Las personas a las que les gusta el control de calidad no piden los puestos de desarrollo. El tipo medio de desaparece.

Entonces, dado todo eso, hay formas bastante limitadas de que el crossover pueda funcionar, y hay una pequeña posibilidad de que alguien quiera hacerlo. Palantir tiene una fuerte cultura de autogestión proactiva (debe saber lo que debe hacer, no hay nadie para decirle), y eso me da mucha flexibilidad para identificar las cosas que deben hacerse y hacerlas, ya sea técnicamente caen bajo QA o dev. En mi experiencia, funciona mejor cuando el trabajo de desarrollo es tangencial al producto central. Históricamente, pasé aproximadamente 1/3 de mi tiempo escribiendo código, que generalmente se clasifica en una de las siguientes categorías:

Código en soporte directo de pruebas. Esto incluye código escrito contra API internas y externas, generadores de conjuntos de datos, pruebas de estrés y varios proyectos de prueba únicos.
Proyectos de herramientas internas (que facilitan la vida de las personas dentro de la organización que no escriben código).
Código destinado a usuarios altamente técnicos. Gran parte del código que escribo está destinado a los ingenieros de implementación avanzada de Palantir, que implementan el software en los sitios de los clientes.
Código para llenar vacíos en el proyecto en el que estoy trabajando. Los desarrolladores tienen un tiempo limitado y se centran en la funcionalidad principal. Por lo general, hay mucho trabajo por hacer en apoyo de la función.
Loco. Yo mismo no soluciono muchos errores en el producto principal (generalmente tenemos el desarrollador que conoce el código que corrige mejor los errores para minimizar las posibilidades de introducir errores secundarios), pero se sabe que sucede. También ayudaré a hacer parches y otro código aleatorio para soluciones alternativas.

Una nota final: he dejado a propósito a las personas que escriben automatización (SET / SDET en la mayoría de las empresas), ya que generalmente parecen operar fuera de la dinámica de desarrollo / control de calidad, ya que no están directamente involucrados con la configuración del producto en sí, sino más bien apoya (y en este punto son muy necesarios para) la capacidad a largo plazo de la empresa para producir código de calidad.

ingeniería de software