¿Cuáles son las características de un buen desarrollador / ingeniero de software?

Otra adición a otros comentarios de ppls: encontrar la solución más simple para el problema real

Me gustaría desarrollar y expandir una parte de la respuesta de Dave Aronson, es decir, centrarme en hacer el trabajo correcto en lugar de hacerlo bien. Creo que es revelador que ninguna otra respuesta se haya centrado en esto a pesar de que muchas investigaciones demuestran que este es el factor más importante para el éxito del proyecto de desarrollo de software. Personalmente, creo que vale la pena leer detenidamente The Game Outcomes Project, Part 1: The Best and the Rest.

Digamos una historia que he leído en algún lugar de Internet (¿Noticias de Hacker?). Imaginemos un mundo con tres líneas de tiempo paralelas. Todos comienzan igual: big corp X inc. están cada vez más frustrados con su gran y complejo sistema CMS desarrollado en los años 90 escrito en el lenguaje de programación X de la vieja escuela. Sienten la necesidad de hacer una actualización y modernización bastante significativa de la funcionalidad para agregar características “modernas” como un editor WYSIWYG para poder mejorar, y de una manera más eficiente, manejar todos los sitios web públicos Big Corp X inc. tener. Por supuesto, Mathias, el gerente de big corp X inc. tienen la tarea de supervisar este proyecto y quieren saber cuánto tiempo el desarrollador encargado del proyecto cree que tomará completarlo.

En la línea de tiempo 1, Aaron el desarrollador tiene la tarea asignada. Aaron tiene una educación adecuada de nivel universitario de CS y trabajó unos años dentro del desarrollo web completo. Por supuesto, Aaron no tiene experiencia con el lenguaje de programación X y todo el furor hoy en día está haciendo cosas en Node / MongoDB, por lo que Aaron lanza para reescribir el sistema CMS por completo en un año (es un sistema grande, por lo que es necesario mucho hecho para portarlo primero y luego desarrollar la nueva funcionalidad). Naturalmente, Aaron es demasiado optimista sobre el marco temporal de la reescritura debido a que no comprende y subestima la complejidad del sistema antiguo y todas sus peculiaridades y parches en casos especiales. Sin embargo, en 12 meses casi había terminado con el puerto, pero desafortunadamente no se habían completado nuevas funciones.

En la línea de tiempo 2, Bertha, el desarrollador principal, tiene la tarea asignada. Bertha también tiene una educación adecuada en CS, pero también casi 10 años de experiencia en varios proyectos de desarrollo, incluidos muchos proyectos web completos de varios tamaños. Bertha sabe que una gran reescritura no vale la pena, tomará demasiado tiempo. Dado que Bertha es una gran programadora, no tiene problemas para aprender el lenguaje de programación X, a pesar de ser un poco peculiar, y cree que es bastante fácil ya que la mayoría de los lenguajes de programación son bastante similares después de todo, se trata principalmente de sintaxis, que es bastante fácil de usar. recoger. Las nuevas características tardan un poco más en completarse debido al lenguaje de programación, pero no por un factor enorme. Dado que Bertha no tiene que hacer la reescritura completa, sabe que puede completar las nuevas funciones en menos de 6 meses, ¡y en realidad lo logra en 5! La experiencia y el profundo conocimiento de los patrones, muchos lenguajes de programación y demás claramente vale la pena …

En la línea de tiempo 3, Clark tiene la tarea asignada. Mucha gente pensó originalmente que era bastante extraño que Clark obtuviera la asignación, ni siquiera trabaja en el departamento de desarrollo de Big Corp X Inc., pero pensó que sería divertido pasar a TI ya que le encanta jugar. con varios “proyectos” de TI en casa, como configurar su servidor Linux como servidor de archivos para sus películas y asegurarse de que toda su familia tenga dispositivos conectados. Además, realizó un curso rápido y gratuito en línea para desarrollo web durante su viaje de vacaciones de verano a las Bahamas. Entonces, ¿cómo fue para Clark? Bueno, terminó su trabajo en 1 mes. ¡¿Qué?! ¡¿1 mes?! ¡¿¡¿¡¿Cómo es esto posible?!?!?! Y no solo entregó un sistema CMS que tenía todas las nuevas características que la administración había solicitado, sino que también logró mover completamente toda la información del sistema anterior al nuevo. Resulta que Clark compró un buen tema de WordPress que modificó un poco para que coincida con el estilo de la empresa y configuró algunas instalaciones en un Linux-VM alquilado a Amazon. Lo hizo las primeras dos semanas, un tiempo bastante largo para una tarea tan fácil, pero Clark no tenía tanta experiencia, por lo que tuvo que investigar algunas cosas que para los desarrolladores experimentados habrían sido triviales. De todos modos, a Clark le quedaban dos semanas y, por supuesto, comenzó el trabajo para migrar la información …

A estas alturas, ya debería haber entendido el punto. Todas las otras características son agradables para el desarrollador, pero si no puede encontrar soluciones simples para las necesidades del negocio / cliente, no es improbable que siga siendo bastante ineficiente. Lo mismo ocurre con la gran diferencia en el resultado entre Aaron y Bertha: Bertha sabía que una reescritura era una solución complicada y costosa para un problema bastante simple de agregar algunas características. Y, por supuesto, esto se puede ejemplificar aún más en escenarios más pequeños donde dos desarrolladores que trabajan en un sistema personalizado intentan desarrollar una nueva característica, pero no entienden la verdadera necesidad y el problema del cliente, sino que simplemente construyen la solución que el cliente solicita. . Como siempre, comprender el problema correctamente es más de la mitad del camino hacia una solución.

• curiosidad insaciable: ven algo que les interesa y no se contentan con saber cómo funciona. necesitan desarmarlo, resolverlo y tal vez incluso volver a armarlo.
• autodisciplinados: priorizan bien su tiempo y esfuerzos. cuando trabajan para empresas, tienen plazos de vencimiento porque saben que siempre puede haber sorpresas por delante. cuando trabajan para sí mismos, permanecen motivados, calculadores y decididos con cada minuto del día.
• tenaz como el infierno – Einstein dijo que logró lo que hizo porque se quedó con el problema más tiempo que nadie. si quieres ser bueno en algo, hazlo. No hay rasgo más importante que esto.
• apasionados, si no compulsivos, de su campo: estudian mientras otros duermen y leen mientras el mundo mira televisión. asisten a conferencias, escriben trabajos, realizan prototipos y presentan su trabajo a sus colegas para su revisión. enseñan y aprenden y lo hacen de alguna forma, todos los días.
• se enorgullecen de su trabajo: están felices de apoyar su trabajo y quieren que otros lo vean y lo critiquen.
• jugador de equipo: líder / compañero de equipo, adoptan plenamente su papel y ponen mucho pensamiento y esfuerzo en hacer mejor esta parte del trabajo, ya que no se trata solo de código. Mejorar el flujo de trabajo, hacer un esfuerzo adicional con la documentación, hacer tiempo para ayudar a los demás y defender lo que es justo frente a la oposición son rasgos de desarrolladores e ingenieros fuertes. También defienden a sus compañeros de equipo y celebran los éxitos de los demás, y son muy confiables.
• son dueños de sus errores y nunca pasan la pelota: se arrodillan, arreglan sus errores y pasan al siguiente desafío. parte de escribir código es cometer errores y algunos de ellos son MUY difíciles de encontrar y costosos para la compañía. Las personas que mienten acerca de estos errores y tratan de culpar a otros se cavan una tumba. el astuto asumirá la responsabilidad y utilizará estas situaciones como una oportunidad para construir una reputación como alguien con quien se pueda contar en todo momento, incluso si esto lleva a la terminación. Estamos en el negocio de ser correctos, perfectos, eficientes y confiables. si no es quien eres, no estará en el trabajo que haces.
• devuelven, aprenden a enseñar y enseñan a aprender

No hace falta decir que deberían saber todo sobre programación. La programación es una colección de herramientas para resolver problemas. Deben tener una caja de herramientas lo suficientemente grande como para poder elegir la mejor herramienta para el trabajo.

Implacable: si alguien tiene un problema difícil, siempre hay una solución. Un buen ingeniero de sistemas encontrará esa solución.

Empatía de dominio: un buen ingeniero de sistemas podrá ver un problema desde el punto de vista de los interesados, en lugar de un simple punto de vista técnico.

Recopilación de requisitos: un ingeniero de sistemas podrá entrevistar a las partes interesadas para obtener los requisitos y abstenerse de desarrollar la solución I hasta que los requisitos hayan sido analizados.

Planificación: un sistema debe diseñarse y planificarse antes de desarrollarse.

Documentación: ¡documente todo! Si te atropella un autobús, ¿qué tan difícil será para la próxima persona tomar el control? Tenga en cuenta que probablemente será la próxima persona en una aplicación mal documentada, al menos una en su carrera … es horrible.

Conozca sus mejores prácticas de seguridad: diseñe teniendo en cuenta la seguridad, no lo agregue al final.

Nunca serás perfecto. Pero no dejes de esforzarte por ser.

Durante mis 26 años en el campo, he manejado bastantes programadores y la calidad # 1 que me gusta ver es la tenacidad. La capacidad de asignar a un ingeniero un problema difícil y de que lo trabajen incansablemente hasta que lo resuelvan. A veces van por callejones sin salida, pero los buenos ingenieros no se rinden, siguen trabajando en el problema hasta que lo superan. ¡Los mejores deseos!

Solo lo remitiré a la respuesta de Dave Aronson a ¿Cuáles son las características de un desarrollador de software con un 1% superior?