Gracias por la A2A.
Hay dos preguntas tres preguntas aquí:
- ¿Puede una persona que no es “rápida” ser un desarrollador de software competente?
- ¿Puede esa persona tener éxito en los trabajos de desarrollo de software “donde la administración quiere el máximo rendimiento”?
- ¿Qué más podría hacer esa persona?
Primero, permítame aclarar algo: no hay absolutamente ninguna forma científicamente verificada de medir la productividad de los programadores individuales . Y la gente lo ha intentado: durante muchos años, hubo una medida estándar basada en KLOC (miles de líneas de código), pero fue una idiotez, ya que más líneas de código no significa más funcionalidad y puede significar un código más lento. Uno de los mejores argumentos para la programación de pares es que no afecta la productividad del equipo (que es más medible que la productividad individual), pero produce menos líneas de código, lo que se traduce en un menor costo de mantenimiento.
La única forma confiable de medir el alcance de un proyecto (y eso es solo relativo a proyectos similares) es con una técnica llamada puntos de función. Se necesita un montón de entrenamiento y aún es en gran parte impulsado por heurísticas; su ventaja sobre cualquier otra cosa es la confiabilidad entre codificadores (dos personas que usan puntos de función por separado, pero en el mismo proyecto producirán desgloses y estimaciones muy similares). Aun así, los puntos de función enfatizan los requisitos funcionales, pero los requisitos no funcionales pueden afectar en gran medida la productividad; Es mucho más difícil escribir software para aviones a reacción y centrales nucleares que escribir una aplicación iOS.
Una cosa que la mayoría de los buenos gerentes en el mundo de los desarrolladores saben es que sus mejores programadores no siempre están tocando sus teclados. La razón por la que podría, por ejemplo, tener máquinas de tenis de mesa y de pinball es que los programadores pasan mucho tiempo dejando que sus subconscientes resuelvan problemas. Es fácil golpear una pared y simplemente no poder avanzar. Sin embargo, hay cosas útiles que se pueden hacer en el tiempo de inactividad, como la documentación, la escritura de pruebas unitarias y el código de perfil. Hay mucho por ser un desarrollador de software que no está programando, y ese trabajo es a menudo la sentencia de muerte de las carreras de desarrollo para programadores muy talentosos.
Por lo tanto, es prácticamente imposible cuantificar un programador lento y rápido, aunque siempre habrá superprogramadores: la gente maravillosa, que es simplemente varias veces más productiva que sus compañeros. No soy uno, nunca podría serlo, y no te preocupes por ellos: son unicornios, extremadamente raros y apenas un estándar útil.
Como resultado, la mayoría de las compañías y los gerentes no pasan mucho tiempo preocupándose por la productividad del programador. Si una persona está contribuyendo, están bien. Alguien a quien se percibe que contribuye más rápidamente podría ganar más dinero, pero todos se dan cuenta de que esto es, en el mejor de los casos, heurístico y, en el peor de los casos, impulsado por algunos sesgos terribles.
¿Hay empresas “donde la administración quiere la máxima producción”? Sí. Mi consejo es evitar a esas compañías, independientemente de lo bueno que sea un programador. Si se percibe a sí mismo como lento, entonces evítelos doblemente, ya que (y he visto esto) la administración se aferrará a sus dudas y las utilizará para juzgarlo. Para ser justos, administrar proyectos de desarrollo es una tarea miserable la mayor parte del tiempo; la gestión de los desarrolladores se ha comparado con “pastorear gatos”, pero recientemente escuché una nueva: “empujar cuerdas”. Muchos gerentes de proyectos están mal capacitados (si es que lo hacen), y la mayoría de los desarrolladores no quieren nada más que nunca ser gerentes de proyectos. Aun así, evita a estas personas.
Sin embargo, digamos que, hipotéticamente, usted era tan demostrablemente lento que se le juzgó incapaz de una tarea de desarrollo de línea principal. Bueno, en la web dev esto te va a hacer daño; hay una gran necesidad de más páginas con más funcionalidad, por lo que la velocidad es más importante que la calidad, y gran parte del trabajo pesado se realiza mediante marcos. Por lo tanto, no apuntaría a esa área (y francamente no he hecho mucho desarrollo web desde 2000).
Sin embargo, hay trabajos de programación para aquellos que son metódicos y excelentes solucionadores de problemas. Cuando era desarrollador, a menudo trabajaba en el rendimiento. Hay algunas personas arrogantes que hablan de esto como si fuera un trabajo mágico, pero no lo es. No escribí “algos”, ya que la cantidad total de nuevos e importantes algoritmos escritos en todo el mundo cada año probablemente se puede contar en dos manos. Lo que hice fue replantear problemas y mapearlos a algoritmos y estructuras de datos existentes. Sigue siendo un trabajo desafiante e interesante. Requiere una cierta cantidad de paciencia porque tiene que crear un perfil de código, crear pruebas, modelar el uso para poder simular condiciones reales, muchas cosas que implican una programación real muy pequeña y mucho análisis de pacientes a través de registros y códigos (y simplemente sentarse y pensando). Si bien es importante tener cierto interés natural y capacidad en el pensamiento algorítmico, esta no es una teoría de la computación. Aprendí mucho más sobre el rendimiento de Kent Beck y Martin Fowler que de Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein: 9780262033848: Amazon.com: Libros (uno de los algoritmos estándar y textos de estructuras de datos) . Permítanme ser claro: necesita ambos, pero habiendo capacitado a personas en desempeño en la industria y el mundo académico, puedo decirles que los estudiantes que amaron la teoría de la computación no fueron los mejores analistas de desempeño; Dios sabe que no estoy en el lado matemático de la informática.
Otra cosa a considerar es simplemente no ser un desarrollador de software, o al menos no ser un desarrollador de software profesional. Hay muchos trabajos de TI, y la mayoría no involucra programación. Dicho esto, una gran cantidad de trabajo de TI fuera de dev & test requiere mucho más extinción de incendios y una respuesta rápida que la que requiere dev & test.
Sin embargo, si te encanta la programación, el desarrollo de software es el camino a seguir. Si mi productividad o calidad de programación significara que estaba “relegado” a algo más que a los empleadores de primer nivel (que representan tal vez, quizás el 3% de los desarrolladores profesionales a tiempo completo), todavía haría ese trabajo sobre cualquier otro trabajo en el Mundo excepto lo que hago ahora.
La única forma de averiguar si puedes actuar como un desarrollador profesional es intentarlo. Hay personas que intentan conseguir trabajo y no lo hacen, pero recuerde que esta es una industria que necesita tanto talento que contratará a idiotas con una licenciatura en inglés (ese soy yo para los trabajos de desarrollo. Si no los encuentra un trabajo después de una búsqueda realmente difícil, o si consigue un trabajo y no tiene éxito, intente nuevamente, obtenga otro trabajo y no tenga éxito, y finalmente decida que no es algo que pueda hacer bien, entonces Intenté y no perdí nada en el esfuerzo, excepto quizás un poco de orgullo. Si tiene problemas con la confianza en sí mismo y la duda en sí mismo (y sospecho que podría, con base en la formulación de la pregunta), hable con la gente sobre esto, porque confíe en mí. cuando digo que estos problemas son comunes y de ninguna manera deterministas sobre su futuro.
¡Buena suerte!