¿Deberían las compañías de software evitar a los programadores perfeccionistas?

De acuerdo con wikipedia:

El perfeccionismo, en psicología, es una creencia de que la perfección puede y debe alcanzarse. En su forma patológica, el perfeccionismo es una creencia de que el trabajo o la producción que es menos que perfecto es inaceptable. A tales niveles, esto se considera una creencia poco saludable, y los psicólogos generalmente se refieren a tales individuos como perfeccionistas desadaptativos.

Para resumir, ser perfeccionista no es necesariamente algo malo. Sí, pueden perder algunos plazos, pero probablemente harán un mejor trabajo general. Quiero decir, ¿sus clientes realmente le están pagando para completar la función A antes de la fecha B o le están pagando para que haga un producto de calidad? Veo un montón de compañías de software que podrían usar más perfeccionismo.

Sin embargo, un perfeccionista desadaptativo es malo. No aceptarán nada menos que perfecto. En resumen, nunca cumplirán porque su objetivo es simplemente inalcanzable.

Nota: si bien estoy de acuerdo con el sentimiento de Debasish. Trataré de responder la pregunta de los participantes con mis antecedentes (startups).

En mi experiencia, un perfeccionista no puede alcanzar plenamente su potencial en una empresa emergente o de ritmo acelerado.

La mayoría de las empresas de ritmo rápido alteran continuamente los objetivos y especificaciones del producto. Esto hace que muchos proyectos cambien a menudo durante el ciclo de construcción, y si ese proyecto no da el impulso deseado del producto, se descarta. Tener un ingeniero que pueda adoptar y reutilizar fácilmente la mayor cantidad de código actual posible es una gran ventaja al tratar de minimizar el tiempo perdido. Un perfeccionista podría ir tan lejos como desechar una buena cantidad de código en la premisa de que no es exactamente lo que necesita. Además, pueden necesitar pasar una cantidad considerable de tiempo repensar las cosas después de un cambio. Esto podría ser un gran problema cuando existe una probabilidad razonable de que el código sea desechado por razones de producto de todos modos.

En el pasado, he tratado de evitar aquellos que pueden tener tendencias perfeccionistas:
– Comprobar si pueden dar soluciones rápidas a algunos problemas simples pero “urgentes”.
– Formular preguntas de la entrevista sobre el comportamiento que ha visto en su empresa y que está tratando de evitar.
– Verificando sus referencias de cómo trabajaron con otros en código compartido.

Una pregunta de ejemplo que he usado fue para dar un problema difícil de CSS donde la única solución conocida son las tablas (Muchos puristas pasarán horas tratando de solucionar el problema con divs en lugar de la corrección de la tabla de 30 segundos). Después del ejercicio, si tuviera sentido, señalaría que el proyecto con ese código en particular fue rechazado por razones de producto.