¿Qué piensan los desarrolladores de software de mediana edad si están trabajando en los mismos lenguajes de programación, marcos y pila de software que un nuevo graduado?

Depende de lo que consideres una edad media.

Tengo 31 años y he estado en la industria durante los últimos 12 años.

Pasó de ASP básico (no .Net pero ASP viejo y malo que se ejecutó en el servidor IIS) al Ruby on Rails, mientras adoptaba Webpack, Gulp, Angular y Vue.

Comenzó con el antiguo estándar C ++ 98. Ahora aprendiendo el estándar C ++ 17.

Trabajó con BASIC y VisualBasic 6. Ahora haciendo C # con WPF y Java con JavaFX.

Hace un año comencé con Go, que ahora es mi idioma principal para escribir microservicios concurrentes.

Pero lo más extraño es que el autor del compilador Go es Ken Thompson. El mismo tipo que trabajó en el sistema operativo UNIX, inventó el lenguaje B que condujo al desarrollo de C. Y tenía 64 años al momento de terminar el compilador Go.

Sí, incluso los perros viejos aprenden algunos trucos nuevos.

No estoy seguro de cómo piensan los programadores de mediana edad, pero puedo decirles cómo piensa un programador muy viejo (82 años). Creo que son términos de abstracciones.

Trabajé por primera vez en una computadora como estudiante hace sesenta y cinco años en el Radar Research Establishment, Great Malvern, Worcester, Reino Unido. Diseñamos flip-flops de válvula termoiónica (cada uno representando un dígito), osciloscopios de rayos catódicos, donde 50 por 50 arreglos de puntos en la pantalla proporcionaron 2.5 k de RAM y cada bit de datos almacenados requirió enhebrar un anillo de ferrita con un alambre de cobre.

El primer programa que escribí (en 1965) se introdujo en un marco principal usando tarjetas perforadas. He visto todo tipo de programación ir y venir. Pronto aprendí que los lenguajes de computadora son como los idiomas hablados: puede aprender la sintaxis relativa rápidamente, lo suficiente como para tener una conversación, pero puede tomar un par de años poder pensar en un idioma en particular.

Al avanzar de un idioma a otro, deja de pensar en términos de sintaxis y expresiones. Empiezas a pensar en términos de objetos que tienen recuerdos y pueden comunicarse entre sí, realizar funciones y realizar tareas. Objetos que pueden cooperar y combinarse para ayudarse mutuamente a alcanzar metas y objetivos.

Ya no creo que se trate de términos de soluciones algorítmicas, donde los programas se limitan a las bases de datos. Soy consciente de un vasto paisaje de memoria utilizable, la nube, que consta de una cantidad incalculable de servidores, que pueden contener mis objetos y enviarlos a computadoras de escritorio, computadoras portátiles, tabletas y teléfonos móviles, etc., donde pueden combinarse y hacer su trabajo. cosas en los entornos complejos de los navegadores.

No veo personas visitando mi sitio web en la nube. Veo que mis objetos bajan de la nube para crear un sitio web en el dispositivo del cliente. Mis objetos no están confinados a un solo servidor o incluso a un solo nombre de dominio. Pueden residir en cualquier parte del entorno abstracto que conocemos como la nube.

Mis programas no son vastas, creaciones complejas, miles de líneas de tamaño. Siempre consisten en unidades simples y pequeñas que interactúan, donde la complejidad proviene de las interacciones.

Mi mentor es la Madre Naturaleza, donde la programación que tiene lugar en las células biológicas supera con creces cualquier cosa creada por programadores humanos. Un libro sobre biología celular ayudará a un programador en el complejo mundo de las computadoras de hoy en día mucho más que cualquier libro sobre sintaxis de programación de computadoras.

No muchos programadores jóvenes piensan de esta manera, pero me ha llevado más de sesenta años llegar a esta forma de pensar. Mucho de lo que he escrito en mi sitio web en http://www.stigmergicsystems.com

Personalmente, creo que los lenguajes de programación, el marco y las pilas de software son relativamente poco importantes; Puedo escoger y elegir. Los patrones de diseño, el modelado de datos, las estrategias de prueba, los cuellos de botella y los puntos débiles son muy similares en una amplia gama de tecnologías y aplicaciones. Saber lo que hay que hacer es más importante que haber memorizado exactamente cómo se hace en cualquier contexto que esté usando hoy.

Aprendemos por nuestros errores, y hemos tenido tiempo de cometerlos. Del mismo modo, los nuevos graduados podrían comprender las características de un nuevo marco, pero solo la experiencia le enseñará por qué tiene esas características, qué problemas específicos resuelven. Cuando comparo el código escrito por nuestros desarrolladores senior con el escrito por los graduados, tiendo a encontrar que el código de posgrado es más “optimista”; Se hace más hincapié en hacer que el código funcione cuando se usa correctamente que en asegurarse de que funciona correctamente cuando las cosas salen mal. De hecho, puedo decir lo mismo sobre el código que escribí hace 15 años sobre el que escribo hoy.

No niego que los nuevos graduados más familiarizados con algún marco específico puedan tener cosas que enseñarme; El desarrollo de software es una carrera en la que estás aprendiendo todos los días. Simplemente no piense que el conocimiento de un sistema en particular supera los años de experiencia en otros.