¿Ser un perfeccionista va en detrimento de la carrera de un ingeniero de software?

Respuesta corta: ¡SÍ!

Respuesta precisa: está COMPLICADO!

Algunos antecedentes:
Dado, los ingenieros de software escriben software que necesita ser vendido para ganar dinero que el ingeniero de software puede recibir su pago. El software se vende si ayuda a aliviar un dolor del cliente.

Dado, para tener un software listo al 90%, se necesita aproximadamente el 60% del esfuerzo. para tenerlo listo al 99%, se necesita otro 60% del esfuerzo. En resumen, la perfección del software es muy, muy difícil.

¿Por qué fue la respuesta corta: SÍ?
Si eres perfeccionista (supongo), te llevará mucho tiempo llegar al software perfecto. Mientras tanto, el cliente tiene un gran dolor (piense en la migraña) y quiere alivio AHORA. Cuando su software perfecto esté listo, su cliente estará muerto o habrá encontrado algo más (lo más probable).

¿Por qué es complicado?
No puede simplemente enviar software medio horneado al cliente, puede que no funcione. ¡Su cliente ya estaba irritable debido a su dolor que tenía ahora que está en una FALTA porque la solución no funcionó!
Además, usted no es el único en el mercado, si alguien puede enviar un software mejor en el mismo tiempo o menos, ha perdido al cliente nuevamente.

Entonces, la complicación es que necesita construir un software suficientemente bueno que haga feliz al cliente pero lo suficientemente rápido como para que aún tenga un cliente. Si el perfeccionista en ti es lo suficientemente rápido, entonces no es perjudicial. 🙂

Por lo tanto, si la perfección te frena, es perjudicial, ¡de lo contrario es tu mayor activo!

No necesariamente. Pueden ser un gran activo para un equipo. Un perfeccionista es un activo para emparejar la programación si se utiliza esa técnica. Un perfeccionista es el más adecuado para el control de calidad, pero puede programar bastante bien. Si un perfeccionista puede dejar que se acumule alguna deuda técnica para solucionar un problema que requiere atención inmediata, no hay problema; probablemente también intentarán pagar esa deuda en la primera oportunidad.

Hay (al menos) dos aspectos de calidad al desarrollar software.

El primero es la corrección.

¿El software no da resultados incorrectos? ¿El software da el resultado correcto en la mayoría de los casos y no da resultados (o error) cuando se encuentra con una situación en la que no daría el resultado correcto? ¿El software da resultados correctos en todos los casos?

Para la corrección y especialmente el desarrollo de pruebas, el perfeccionista generalmente brilla.

El segundo aspecto es la adherencia a las prácticas estándar. Aquí es donde las cosas se ponen un poco complicadas, ya que no todos estarán de acuerdo con todas estas prácticas. Por esta razón, dos perfeccionistas en un equipo pueden chocar, lo que lleva a algunos problemas serios. A veces se creará un código inferior (más lento / más intensivo en recursos) en nombre de adherirse a una metodología.

Tengo que concluir que los perfeccionistas suelen ser una ventaja para un equipo. También creo que necesitan un equipo para poder desarrollar software rápidamente.

Creo que la respuesta de Kenneth Cochran es correcta, pero terriblemente cínica. Desde mi punto de vista, es cierto que cierto tipo de perfeccionismo es perjudicial: el tipo que le impide enviar.

Si agrega nuevas funciones antes de que los usuarios hayan visto las funciones que ya tiene, es posible que sea demasiado perfeccionista. Entregar software a los usuarios es cómo descubrir qué características realmente importan y en las que vale la pena invertir tiempo y recursos.

Si necesita que su arquitectura sea perfecta, puede ser demasiado perfeccionista. Especialmente al escribir nuevo software o características, es vital mantener la arquitectura flexible. Piense en una espada de samurai o acero de Damasco: fuerte pero flexible. De lo contrario, puede estar endureciendo la arquitectura incorrecta, una que no admitirá las necesidades futuras de los usuarios.

Si su equipo lo ve como un cuello de botella, … Trabajar con un buen equipo aumentará naturalmente la perfección de su código. Siempre habrá margen de mejora.

Dicho de otra manera, la “perfección” debería estar optimizando una función diferente a la estética del código puro. Es posible que el software que nunca se usa no exista. A menos que comencemos algún tipo de museo de códigos donde los guiones antiguos se puedan ver por su belleza, de todos modos.

Si. Las empresas no quieren la perfección. Quieren “lo suficientemente bueno”. Al igual que un artista que crea una escultura o una pintura, tiene que dejar las herramientas y declararla “terminada” eventualmente.

A menos que esté involucrado en un proyecto que requiera una verificación formal para evitar errores catastróficos, su empleador solo quiere algo que funcione correctamente en la mayoría de los casos de uso. Los casos extremos que ocurren raramente pueden esperar hasta que un cliente los informe realmente.

Puede rechazar la idea de dejar un proyecto en un estado que viole sus sensibilidades estéticas, pero debe recordar que todo lo que un empleador quiere de un empleado es que agregue valor comercializable a un producto.

Por el contrario, es un atributo raro que diferencia a los programadores de élite de los plebeyos. Escribir un programa o un software, aunque es una tarea difícil en sí misma, se ha vuelto enormemente complejo en los últimos años, principalmente debido a la proliferación de Internet y la necesidad de proporcionar una gran cantidad de funciones y, al mismo tiempo, ser compatible con múltiples dispositivos y sistemas operativos.

En resumen, necesitamos más y más perfeccionistas en este campo.