Uno de los pioneros de la inteligencia artificial deja Google y advierte del peligro de la tecnología

 https://www.nytimes.com/es/2023/05/03/espanol/ia-peligro-google.html?smid=nytcore-ios-share&referringSource=articleShare

Geoffrey Hinton deja Google para poder compartir con libertad su preocupación de que la inteligencia artificial podría causar daños graves al mundo.Credit...Chloe Ellingson para The New York Times

Por Cade Metz, Toronto. 3 de mayo de 2023

Geoffrey Hinton fue uno de los pioneros de la inteligencia artificial. En 2012, Hinton y dos de sus estudiantes de posgrado de la Universidad de Toronto crearon una tecnologíaque se convirtió en la base intelectual de los sistemas de IA que las empresas más grandes del sector tecnológico consideran clave para su futuro.Sin embargo, el lunes se unió de manera oficial a un creciente coro de críticos que afirman que esas empresas están corriendo hacia el peligro con su agresiva campaña para crear productos basados en la IA generativa, la tecnología que impulsa chatbots populares como ChatGPT.Hinton contó que había renunciado a su puesto en Google, donde trabajó durante más de una década y se convirtió en una de las voces más respetadas en este campo, a fin de poder hablar libremente sobre los riesgos de la IA. Una parte de él, afirmó, lamenta ahora el trabajo de su vida.
“Me consuelo con la excusa habitual: si yo no lo hubiera hecho, habría sido alguien más”, dijo Hinton durante una larga entrevista la semana pasada en el comedor de su casa de Toronto, a poca distancia del lugar donde él y sus estudiantes hicieron su gran avance.
El paso de Hinton de pionero de la IA a profeta pesimista marca un momento extraordinario para la industria tecnológica, quizá en su punto de inflexión más importante en décadas. Los líderes del sector creen que los sistemas nuevos de IA podrían ser tan importantes como el lanzamiento del navegador web a principios de la década de 1990 y podrían implicar avances en ámbitos que van desde la investigación de fármacos hasta la educación.
Sin embargo, muchas personas del sector temen que estén liberando algo peligroso. La IA generativa ya puede ser una herramienta para la desinformación. Pronto, podría ser un riesgo para el empleo. En algún momento, dicen los más preocupados por la tecnología, podría ser un riesgo para la humanidad.
“Es difícil evitar que los malos la utilicen para cosas malas”, expresó Hinton.
Después de que la empresa emergente OpenAI de San Francisco lanzó una nueva versión de ChatGPT en marzo, más de mil líderes tecnológicos e investigadores firmaron una carta abierta en la que pedían una moratoria de seis meses en el desarrollo de nuevos sistemas porque las tecnologías de IA plantean “profundos riesgos para la sociedad y la humanidad”.
Varios días después, 19 líderes actuales y antiguos de la Asociación para el Avance de la Inteligencia Artificial, una sociedad académica con 40 años de antigüedad, publicaron su propia carta con el fin de advertir sobre los riesgos de la IA. En ese grupo figuraba Eric Horvitz, director científico de Microsoft, la empresa que ha desplegado la tecnología de OpenAI en una amplia gama de productos, incluyendo su motor de búsqueda Bing. 
Hinton, a menudo llamado “el padrino de la IA”, no firmó ninguna de esas cartas y dijo que no quería criticar de manera pública a Google o a otras empresas hasta que hubiera dejado su trabajo. El mes pasado notificó a la empresa que dimitía y el jueves habló por teléfono con Sundar Pichai, director ejecutivo de la empresa matriz de Google, Alphabet. Se negó a comentar públicamente los detalles de su conversación con Pichai.
El científico jefe de Google, Jeff Dean, afirmó mediante un comunicado: “Seguimos comprometidos con un enfoque responsable de la IA. Aprendemos continuamente para comprender los riesgos emergentes al tiempo que innovamos con audacia”.
Hinton, británico expatriado de 75 años, es un académico de toda la vida cuya carrera se vio impulsada por convicciones personales sobre el desarrollo y el uso de la IA. En 1972, como estudiante de posgrado en la Universidad de Edimburgo, Hinton adoptó una idea llamada red neuronal. Una red neuronal es un sistema matemático que aprende habilidades analizando datos. En aquella época, pocos investigadores creían en la idea. Pero se convirtió en el trabajo de su vida.
En la década de 1980, Hinton era profesor de informática en la Universidad Carnegie Mellon, pero abandonó esa institución para irse a Canadá porque dijo que era reacio a aceptar financiamiento del Pentágono. En esa época, la mayor parte de la investigación sobre IA en Estados Unidos estaba financiada por el Departamento de Defensa. Hinton se opone de manera profunda al uso de la IA en el campo de batalla, lo que él califica como “soldados robot”
En 2012, Hinton y dos de sus estudiantes en Toronto, Ilya Sutskever y Alex Krishevsky, construyeron una red neuronal que podía analizar miles de fotografías y enseñarse a identificar objetos comunes, como flores, perros y autos.
Google invirtió 44 millones de dólares para adquirir la empresa creada por Hinton y sus dos estudiantes. Además, su sistema condujo a la creación de tecnologías cada vez más potentes, incluyendo nuevos chatbots como ChatGPT y Google Bard. Sutskever pasó a ser científico jefe de OpenAI. En 2018, Hinton y otros dos antiguos colaboradores recibieron el Premio Turing, a menudo llamado “el Premio Nobel de la informática”, por su trabajo en redes neuronales.
Más o menos al mismo tiempo, Google, OpenAI y otras empresas comenzaron a construir redes neuronales que aprendían de enormes cantidades de texto digital. Hinton pensaba que era una forma muy potente de que las máquinas entendieran y generaran lenguaje, pero inferior a la forma en que lo hacían los humanos.
El año pasado, cuando Google y OpenAI crearon sistemas que utilizaban cantidades mucho más grandes de datos, su perspectiva cambió. Seguía creyendo que los sistemas eran inferiores al cerebro humano en algunos aspectos, pero pensaba que estaban eclipsando la inteligencia humana en otros. “Quizá lo que ocurre en estos sistemas es en realidad mucho mejor que lo que ocurre en el cerebro”, supuso.
A medida que las empresas mejoran sus sistemas de IA, él cree que se vuelven cada vez más peligrosos. “Recordemos cómo era hace cinco años y veamos cómo es ahora”, dijo sobre la tecnología de IA. “Tomemos esa diferencia y pensemos en lo que podría pasar más adelante. Eso da miedo”.
Hasta el año pasado, aseguró, Google actuó como un “supervisor apropiado” de la tecnología, al tener cuidado de no lanzar algo que pudiera generar daños. Pero ahora que Microsoft impulsó su motor de búsqueda Bing con un chatbot —lo que desafía el negocio principal de Google—, Google está compitiendo para implementar el mismo tipo de tecnología. Los gigantes tecnológicos están atrapados en una competencia que podría ser imposible de detener, dijo Hinton.
Su preocupación inmediata es que internet se llenará de fotos, videosy textos falsos, y una persona promedio “ya no podrá saber qué es verdad”.
También le preocupa que, con el tiempo, las tecnologías de la IA revolucionarán el mercado laboral. Hoy en día, los chatbots como ChatGPT tienden a complementar a los trabajadores humanos, pero podrían remplazar a los asistentes legales, asistentes personales, traductores y otras ocupaciones que manejan tareas más cotidianas. “Elimina el trabajo pesado”, dijo. “Pero es posible que nos quite más que eso”.
En los próximos años, le preocupa que las versiones futuras de la tecnología sean una amenaza para la humanidad porque a menudo aprenden un comportamiento inesperado de la gran cantidad de datos que analizan. Esto puede convertirse en un problema, aseguró, si las personas y las empresas permiten que los sistemas de IA no solo generen su propio código de computadora, sino que también lo ejecuten por su cuenta. Y teme el día en que las armas en verdad autónomas —esos robots asesinos— se hagan realidad.
“Algunas personas creían en la idea de que estas cosas realmente podrían volverse más inteligentes que los humanos”, dijo. “Pero la mayoría de la gente pensaba que eso estaba muy lejos de pasar. Y yo pensé que estaba muy lejos. Pensé que faltaban entre 30 y 50 años o incluso más. Obviamente, ya no pienso así”.
Muchos otros expertos, incluidos muchos de sus estudiantes y colegas, dicen que esta amenaza es hipotética. Pero Hinton cree que la competencia entre Google y Microsoft y otras empresas se convertirá en una carrera global que no se detendrá sin algún tipo de regulación a nivel mundial.
Pero eso puede ser imposible, dijo. A diferencia de las armas nucleares, aseguró, no hay forma de saber si las empresas o los países están trabajando en la tecnología en secreto. La mejor esperanza es que los principales científicos del mundo colaboren en formas de controlar la tecnología. “Creo que hasta que hayan entendido si pueden controlarlo, no deben desarrollar más esto”, dijo.
Hinton dijo que, cuando la gente solía preguntarle cómo podía trabajar en una tecnología que posiblemente era peligrosa, parafraseaba a Robert Oppenheimer, que dirigió las iniciativas de Estados Unidos para construir la bomba atómica: “Cuando ves algo que es técnicamente grandioso, sigues adelante y lo llevas a cabo”.
Ya no dice lo mismo.

Desarrolladores Boomer: 10 lecciones que aprendí de ellos, Jan Kammerath 23 de abril, MEDIUM

Esta historia de Jan la siento como mia, ahora tengo más de 50 años y soy Generación X; con todo lo que dice me siento identificado, y he estado en este mismo desarrollo y más en Ecuador...........

Los boomers construyen la tecnología que todos amamos hoy

Ahora tengo casi 30 años y comencé a aprender a codificar alrededor de los 12 años, en 1996. Mi carrera profesional como ingeniero de software despegó a principios de la década de 2000 cuando comencé a trabajar para una empresa de software local. Solo tenía 17 años cuando comencé a programar profesionalmente y en un entorno comercial, era el más joven de todos. Fui un niño. Un niño con una gran pasión por las computadoras, las redes y la programación.

Mis colegas boomers me enseñaron habilidades duras y blandas esenciales en aquellos tiempos. Los considero mis mentores hasta la fecha. Con muchos de ellos soy buenos amigos además de la diferencia de edad. Con algunos de ellos he perdido el contacto desde hace años. Todos ellos me han enseñado valiosas lecciones que quiero compartir con ustedes. Especialmente con aquellos de vosotros que no habéis tenido la oportunidad de trabajar con ellos. Cuando yo tenía 17 años, ellos tenían entre 30 y 40 años. Más o menos la edad que tengo ahora. Muchos de los desarrolladores boomer ya se han jubilado o están en la fase de jubilarse ahora y temo un poco que parte de su legado se pierda en el tiempo.

La gente cambia, los problemas permanecen. — Colega anónimo

#1 Todo se ha hecho antes

Los nuevos inventos, el nuevo software, el nuevo hardware o los nuevos lenguajes de programación no son tan nuevos como parecen o a menudo afirman ser. Muchos paradigmas, enfoques o soluciones se han intentado antes. Muchas de esas soluciones siguen reapareciendo. ¿Por qué? Porque cuando fueron probados y probados anteriormente en la historia, fallaron, porque estaban adelantados a su tiempo o eran demasiado inmaduros. Fíjate en el reconocimiento de voz: IBM lo lanzó en los años 80 . Era inmaduro, requería muchísimos recursos y era increíblemente caro. Cuando se lanzaron Siri de Apple y el asistente de Google, ambos fueron otro intento de una interfaz de usuario basada en el habla. Y lo consiguieron. Simplemente porque su tiempo había llegado.

FrontPage de Vermeer (adquirida por Microsoft): uno de los primeros creadores de sitios web en 1995

Casi todos los tipos de software que podría estar escribiendo hoy probablemente se escribieron antes. Para Unix, para DOS, para CP/M, para Windows 95, para Macintosh o para lo que sea. Los ejemplos son casi infinitos y muchos productos de software populares de hoy en día tienen antepasados.

·         FrontPage es uno de los antepasados ​​de Wix y Squarespace

·         Second Life es un antepasado de Metaverse y Roblox

·         Visual Basic (1.0 para DOS) es un antepasado de Visual Studio Code

·         CVS, SourceSafe y Subversion son ancestros de Git

·         Microsoft NetMeeting es el abuelo de Microsoft Teams

·         Oracle (lanzado en 1979) es el abuelo de todas las bases de datos relacionales

La lista podría continuar para siempre. Mire todas las aplicaciones en la pantalla de inicio de su teléfono. Todos ellos tienen antepasados ​​que van desde productos físicos hasta aplicaciones modernas. Mire Maps: primero tuvimos mapas impresos plegables físicos, luego tuvimos software de escritorio como Microsoft AutoRoute y finalmente aterrizamos en Google Maps y Apple Maps que todos usamos hoy.

Microsoft Access (1992): uno de los primeros creadores de aplicaciones "sin código"

Cuando cree nuevas aplicaciones, observe lo que se hizo antes. Evalúe la mejora en la tecnología y aprenda de lo que se hizo antes y cómo las capacidades técnicas de hoy pueden mejorarlo.

#2 Sigue la ciencia

¿Estás creando un " MVP " o un " producto mínimo viable " para probar tu idea de software? Lo que estás haciendo en realidad es escribir un prototipo. La informática tiene una investigación bastante buena sobre la creación de prototipos de software . Puede encontrar que muchas de las preguntas que tiene al intentar construir un " MVP " se resuelven de manera precisa con el conocimiento científico sobre la creación de prototipos.

Inventaron Unix y C: Ken Thompson y Dennis Ritchie

Con la creciente popularidad de la ingeniería de software y las nuevas empresas que buscan proporcionar herramientas o consultoría para ingenieros de software, habrá un número cada vez mayor de personas que intentarán venderle "ideas" vinculadas a sus productos o servicios. Los boomers me enseñaron a apegarme a la ciencia y hacer una evaluación científica de si un producto, servicio o enfoque es razonable o si alguien simplemente está tratando de venderme aceite de serpiente.

Cuando alguien, una persona o una empresa me vende una “idea” o un “enfoque diferente”, analizo los siguientes puntos que aprendí de los boomers.

·         ¿Existe evidencia científica que respalde las afirmaciones realizadas?

·         ¿Qué dicen los últimos trabajos de investigación académica sobre el tema?

·         ¿Los argumentos resisten el escrutinio científico?

Ya sea Scrum, Agile, No Code, Low Code, OOP, NoSQL, Blockchain, Metaverse o cualquier otra tendencia que esté a la vuelta de la esquina. Revalidarla con métodos científicos. De esta manera, puede diferenciar el aceite de serpiente de las innovaciones y avances tecnológicos reales.

#3 Termina de una vez

¿Haces TDD, BDD, pruebas unitarias, diseño basado en dominios, desarrollo basado en datos, programación en pares y sigues la filosofía SOLID, SSOT, GRASP o Unix? Bien por ti y si no, no te preocupes. No existe una sola forma correcta de hacer las cosas, sino múltiples enfoques para una solución. Sin embargo, debe evitar cometer errores que otros cometieron antes que usted.

El método de gestión de proyectos Waterfall, el lenguaje de modelado unificado (UML) para el software de modelado o el proceso unificado son un enfoque tan válido como las metodologías ágiles como Scrum o SAFe, que utilizan historias de usuarios para definir requisitos o dividen su trabajo de desarrollo en sprints. Puede debatir el enfoque de la programación y la ingeniería de software para siempre, especialmente a nivel filosófico.

Redacción de diagramas de flujo y diagramas UML con Microsoft Visio

Siempre es muy fácil para los programadores entrar en debates sobre cómo organizar, qué control de versiones usar, cómo diseñar, redactar y construir software. Todos tienen un enfoque diferente, preferencias diferentes y una visión diferente de las cosas. Sin embargo, hay un punto en el que debe poder pasar del debate a hacer realmente el trabajo necesario. Debe definir el enfoque y lo más probable es que sea un compromiso. Sea como sea y te guste o no. Trágalo y termínalo de una vez.

Encuentre un compromiso de trabajo para usted y sus compañeros programadores. Acepte el proceso, comience y haga el trabajo. Todavía puede ajustar más adelante cuando identifique espacio para mejorar. La planificación es importante, pero no se exceda. Encuentre un equilibrio saludable entre la planificación, el diseño, el dibujo y la construcción.

#4 Identificar la necesidad

¿Cuál es el propósito del software que está creando y por qué lo crea para quién? ¿Qué quiere lograr esa persona, tu usuario, con tu software? ¿Qué es realmente capaz de hacer su usuario y en qué entorno? — Esas son las preguntas, los boomers me enseñaron a hacerme antes de construir cualquier cosa.

Una vez respondidas estas preguntas, procederé a escribir el software más básico y simple para resolver ese problema específico y presentárselo al usuario. Posteriormente, el usuario me bombardeará con solicitudes de funciones. Predominantemente con respecto a la interfaz de usuario, porque eso es lo que el usuario percibe que es todo el software. No implementaré ninguna de estas características solicitadas, pero identificaré la necesidad real del usuario y encontraré una manera simple, fácil y conveniente de satisfacer esa necesidad.

Muy popular y elogiado por su simplicidad: WS_FTP95

“La gente no sabe lo que quiere hasta que se lo muestras. Es por eso que nunca confío en la investigación de mercado. Nuestra tarea es leer cosas que aún no están en la página”.—Steve Jobs

La persona promedio no tiene idea de qué es una computadora, cómo funciona, cómo se escribe el software o qué es una red informática. No puede esperar que sepan nada sobre el software y, por lo tanto, no puede esperar que puedan articular los requisitos de una manera tan significativa de la que podría derivar su software.

Identificar la necesidad real del usuario: ¿cómo quiere hacer el usuario qué y por qué razón? Implemente la forma más fácil y conveniente de hacerlo y presente esa solución en forma de prototipo. Luego iterar desde ese prototipo en adelante. Nunca confíe en que el usuario pueda articular sus requisitos.

#5 Obtenga las herramientas adecuadas para el trabajo

Los boomers me enseñaron a escuchar al usuario e identificar su necesidad. A partir de esa necesidad, redactaré una solución simple, confiable y conveniente. Esa solución no implica ningún lenguaje de programación, componente, software, sistema o plataforma. Es una descripción genérica de la solución, una definición de cómo me gustaría lograr qué. Una vez que haya redactado esa solución, seguiré los siguientes pasos para identificar qué herramientas, cadena de herramientas, lenguaje de programación y sistema operativo usaré.

·         ¿Qué plataformas de destino necesitará mi solución? Escritorio, web, móvil, integrado, mainframe, Unix, Windows, Linux, Solaris, Macintosh, DOS?

·         ¿Qué lenguajes de programación puedo usar para compilar para esa plataforma?

·         ¿Qué componentes necesito para construir la solución en esa plataforma?

·         ¿Qué habilidades necesito aprender para construir esa solución con esas herramientas?

·         ¿Qué obsolescencia tienen estas herramientas, de ahí mi solución? ¿Mi solución podrá sobrevivir los próximos 5 años sin reescribirla por completo?

·         ¿Cuánto me cuestan estas herramientas a mí y a mis usuarios? ¿Pueden mis usuarios pagar la solución o necesito reducirla para que se ajuste a su presupuesto?

Borland C++ 5.02: Una relación de amor y odio con muchos desarrolladores boomers

Encontrar las herramientas adecuadas nunca es fácil y, a menudo, está extremadamente sesgado. Tiene idiomas preferidos, herramientas y plataformas con las que se siente más cómodo. También tienes herramientas, lenguajes y plataformas que simplemente disfrutas mucho. Sin embargo, es posible que estas no sean las herramientas, los lenguajes y las plataformas adecuados para la solución que su usuario necesita.

Se honesto contigo mismo:

·         ¿Elegiste la cadena de herramientas, el lenguaje y la plataforma porque te gusta?

·         ¿O los elegiste porque solo quieres probarlos?

·         ¿O los eligió porque son el enfoque más económico?

No existe una solución universal para ningún problema. Identificar las herramientas que conducen a la solución más económica. Serán un compromiso. Aprenda a dominar estas herramientas e implemente la solución que sea mejor para el usuario, no la solución y no las herramientas con las que se sienta más cómodo o que sean la última tendencia.

#6 Haz los esquemas

Me encanta programar y me encanta saltar directamente a ella. Los Boomers me enseñaron a nunca hacer eso. Me enseñaron a tomar una taza de café y una hoja de papel en su lugar. Me enseñaron a redactar la solución con los componentes y la plataforma seleccionados. Querían que hiciera un plano, los esquemas, incluso antes de escribir la primera línea de código. Incluso una vez que tuve el plano frente a mí, definiré las partes técnicamente más complicadas y críticas.

Las partes más críticas las implementaré de forma aislada de antemano. De esta manera pude averiguar si realmente sería capaz de implementar estas partes críticas y complicadas. Apple proporcionó el siguiente ejemplo en su revista de desarrollo de la primavera de 1991. Muestra la complejidad de una búsqueda de DNS con MacTCP en Macintosh System 7 y posteriores.

/* Código de muestra MacTCP de Apple Develop (primavera de 1991, página 55) */
# include  <Types.h>
 # include  <MacTCPCommonTypes.h>
 # include  <AddressXLation.h>
 # include  "CvtAddr.h"

 pascal void  DNRResultProc ( struct hostInfo *hInfoPtr, char *userDataPtr) ;

/* ConvertStringToAddr es una simple llamada para obtener el número de IP de un host,
    dado el nombre del host. */
OSErr ConvertStringToAddr ( char *nombre, largo sin firmar  *netNum)
 {
  struct  hostInfohInfo;
  resultado OSErr;
  char terminado = 0x00 ;

  if ((resultado = OpenResolver (nil)) == noErr) {
    resultado = StrToAddr (nombre,&hInfo,DNRResultProc,&done);
    if (resultado == cacheFault)
      while (!hecho)
        ; /* esperar a que la interrupción llame a la resolución de fallas de caché */
    CloseResolver ();
    if ((hInfo.rtnCode == noErr) || (hInfo.rtnCode == cacheFault)) {
      *netNum = hInfo.addr[ 0 ];
      strcpy (nombre, hInfo.cname);
      nombre[ strlen (nombre) -1 ] = '\0';
      devuelve ningún error;
    }
  }
  *númneto = 0 ; resultado
  devuelto ;
}

/* Esta es la rutina de finalización utilizada para las llamadas de resolución de nombres.
Establece el indicador userDataPtr para indicar que la llamada se ha completado. */
pascal void  DNRResultProc ( struct hostInfo *hInfoPtr, char *userDataPtr)
 {
  # pragma unused (hInfoPtr)
   *userDataPtr = 0xff ; /* Establecer los datos del usuario en distintos de cero significa que hemos terminado. */
 }

Solo después de que se demuestre a sí mismo que es capaz de implementar las partes complejas (como el ejemplo anterior) , puede estar seguro de que puede implementar la solución por completo. Se asegurará de haber identificado cualquier obstáculo antes y también será consciente de las limitaciones a las que se enfrentará. Especialmente aquellos que no conocía cuando redactó su solución. Es muy importante evaluar su solución antes de comenzar a implementarla.

No salte al código. Redactar una solución técnica en papel. Pruebe las partes más críticas y complicadas. Asegúrese de que la solución sea técnicamente posible y que sea técnicamente capaz de implementarla. Busque soluciones alternativas si su evaluación falla.

#7 La codificación es un oficio

Escribir software puede ser un arte y puede ser muy expresivo. La gente puede escribir código extremadamente elegante con funciones de lenguaje sofisticadas. El código se puede escribir de manera que sea complicado, estúpido, simple, hermoso o absolutamente aterrador. Si bien eso puede ser emocionante como una obra de arte, el código puede serlo, es absolutamente inútil como un producto elaborado.

Lo que debe tener en cuenta : crea un producto para que lo usen sus usuarios. En un sentido muy básico, es como una forma moderna de pala, tractor o ducha: un producto técnico para que lo usen otras personas.

Puede que no seas el mejor programando, porque nadie lo es. La codificación en sí misma no es una competencia. Sí, su producto va a competir, si es un producto de software comercial. Pero tú y tu código no están compitiendo con alguien. Estás escribiendo el código para crear la solución a un problema. Trate de hacer su mejor trabajo, pero no exagere. No intentes convertirlo en una obra de arte. Concéntrese en la solución y no tenga demasiado miedo de su propio trabajo.

No hay necesidad de avergonzarse de su código VB6 del '98.

Cuando alguien más mire su código más adelante, encontrará formas de optimizarlo. Encontrarán formas de hacerlo más limpio, más bonito, más rápido, más ligero, más delgado y más elegante. Esa es la naturaleza de cada oficio. Siempre hay formas de mejorarlo. No deberías avergonzarte de lo que construiste si te apegas a las mejores prácticas y a los cimientos del oficio.

La codificación no es magia y no es ciencia espacial. Es un oficio y necesitas dominar ese oficio. Nunca serás perfecto en ese oficio, pero debes continuar mejorando tus habilidades todos los días entrenando, aprendiendo y aplicando. No te avergüences de ti mismo ni del código que has escrito en el pasado.

#8 No necesitas eso

Escribir software de computadora en los años 90 era un ejercicio costoso. La computadora decente en 1995 tenía un precio de $ 2,500- $ 3,000 en dinero de hoy. Incluía algo así como un 486 de 100 Mhz, 8 MB de RAM y una unidad de disco de 540 MB, Windows 3.11 y posterior Windows 95. Fácilmente capaz de ejecutar un IDE como Borland C++ 4.02. Para Borland C++ 5.02 necesitaría actualizar la memoria RAM a 16 MB o más, ya que 16 MB era el requisito mínimo para Borland C++ 5.02. El precio de venta al público de Borland C++ 4 era de 499 dólares en aquellos días, lo que equivale a 988 dólares en la actualidad. Eso es la friolera de mil dólares además de esa máquina que ya es cara. Si estaba programando para computadoras Macintosh, puede agregarle fácilmente un par de miles de dólares.

Los IDE eran caros: alrededor de $ 1,000. ¡Pero venían en una bonita caja con asa!

La programación en el pasado era divertida, pero costosa e incómoda. No era inusual bloquear toda la máquina y enviarla a reiniciar con su código. Cuando invierte tanto dinero en su equipo, piensa dos veces en qué invertirá. Piensa dos veces si realmente necesita esa biblioteca adicional por otros $200.

¿Hay una base de datos de archivos planos ligeramente mejor que la incluida en su entorno de desarrollo? Son otros $1,000. No necesitas eso.

Cuando los boomers escribieron software, tuvieron que lidiar con todo tipo de restricciones: efectivo, memoria, CPU, red, disco y básicamente todo lo demás. Prácticamente todo era limitado en comparación con hoy. Siempre pensarían dos veces si realmente necesitarían algo y cuál sería el impacto en su producto final. Los sistemas de sus usuarios objetivo eran aún más limitados que las computadoras en las que programaban.

¿Realmente necesitas todas esas cosas caras? Trate de hacerlo simple y en un presupuesto. No hay necesidad de una supercomputadora y el entorno de desarrollo más costoso. Utilice las herramientas que puede permitirse o que ya tiene. Elija sabiamente sus dependencias, ya que lo seguirán durante bastante tiempo.

#9 Libéralo cuando se pueda enviar

Hoy en día, el software de envío es fácil. Los productos SaaS se pueden enviar en un instante con entrega continua. El cliente puede actualizar constantemente las aplicaciones en sus dispositivos, ya que siempre están en línea. Los boomers en el pasado tenían que enviar software en disquetes o discos compactos. Tenían una sola oportunidad de enviar. Lo que sea que pusieran en ese disquete o disco tenía que funcionar cuando llegaba a las manos del usuario. Sin segunda oportunidad.

PC-MAN en una bonita caja por $34.95

Si el software del disquete o del disco tuviera problemas, los minoristas tendrían que darle al cliente un disquete adicional con un parche o reemplazar el inventario existente por completo. Había muy poco margen de error si quería un producto de software comercialmente exitoso en los estantes. Un producto tenía que ser " envíable ", lo que significa que se probó, probó y verificó para que funcionara en la mayor cantidad de máquinas posible.

También tenga en cuenta que las plataformas de destino eran un desastre. Tenía una variedad de opciones de gráficos diferentes para admitir si su software usaba más que una simple entrada de texto (las opciones populares eran Hercules, CGA, EGA, VGA para PC IBM y compatibles) . Tenía que probar eso antes de enviar su producto al usuario. Dado que no había virtualización, eso significaba que tenía que probarla en máquinas físicas o confiar en una biblioteca de terceros que se probó y probó. No me hagas empezar con el sonido o las opciones de red.

El software que se puede enviar, como me enseñaron los boomers, significa software que se ejecutará de forma inmediata en al menos el 90 % de las máquinas de destino previstas. Crear una nueva versión fue un proceso de pensamiento muy completo. No se podía simplemente lanzar, enviar y esperar lo mejor.

Defina lo que significa envío para usted. Asegúrese de que lo que envíe funcione para el 90 % de los usuarios desde el primer momento. No tome atajos en las pruebas de caja negra y caja blanca. El proceso de lanzamiento y envío técnico es parte de su proceso de desarrollo y, por lo tanto, parte de su software. No lo delegues a nadie más.

#10 Lee los libros

Stackoverflow se lanzó en septiembre de 2008, 10 años después del lanzamiento de Windows 98 y 6 años después de Windows XP. Sí, había recursos de programación en Internet antes del año 2000. MSDN, Microsoft Developer Network, es uno de ellos. Sin embargo, la gente rara vez los usaría dado lo lento y costoso que era Internet con su módem de 56k en comparación con el acceso a Internet siempre activo de hoy. Sí, había grupos de noticias donde podías publicar preguntas y esperar días para obtener una respuesta. En la mayoría de los casos, se le dijo que solo leyera la documentación. En lugar de Github y Stackoverflow, ambos fundados en 2008, los boomers tuvieron que confiar en los libros. Libros caros, pero de alta calidad.

Y libros que necesitaban mucho : un libro de introducción a su idioma, un manual de referencia para el idioma, un manual de referencia para el sistema operativo en ese idioma y cualquier libro específico de dominio (por ejemplo, redes) que necesitaran. Un solo libro a menudo no hacía el trabajo, los boomers necesitaban un estante de libros técnicos. El libro “ Principio de programación de Macintosh C ” en 1992, como ejemplo, costaba 26,95 dólares estadounidenses, lo que sería 57,98 dólares estadounidenses en la actualidad. Si miras los libros de programación de Macintosh de la época, fácilmente subirías a $ 500 en dinero de hoy solo por libros.

Afortunados los que tenían cerca una biblioteca universitaria bien equipada

Los libros más populares e importantes que todo desarrollador, no solo los boomers, tiene en su estantería son al menos, pero no se limitan a, los siguientes.

·         El lenguaje de programación C por Brian W. Kernighan

·         El lenguaje de programación C++ de Bjarne Stroustrup

·         El entorno de programación UNIX por Brian W. Kernighan

·         UNIX para programadores y usuarios por Graham Glass

Hay toneladas de otros libros de los años 70, 80 y 90 que te animo a leer. Encontrará que muchos de los libros de esa época son de mayor calidad que la mayoría de los libros que encontrará hoy.

·         Libros de programación en Internet Archive

·         Libros de programación de Macintosh en Vintage Apple

Los libros más importantes que me dijeron que leyera eran sobre el lenguaje de programación C, el sistema operativo UNIX, SQL con bases de datos relacionales y TCP/IP. Si bien hay libros electrónicos, lectores electrónicos y otras opciones de lectura de pantalla, me enseñaron a seguir con los libros impresos y debo admitir que personalmente prefiero los libros impresos desde entonces.

Lea los libros, comprenda los contenidos y aprenda. Aplicar los conocimientos aprendidos a través de la formación. No confíe únicamente en la capacitación institucional, necesita los libros y los necesitará por el resto de su vida. Nunca dejarás de aprender y los libros son la fuente de conocimiento más importante para aprender.

Lo que lograron los boomers

Como toda generación en la historia de la humanidad, existen conflictos generacionales. De hecho, hay tanta investigación académica sobre los conflictos generacionales que no hay motivo para que escriba nada más: La psicología detrás del conflicto generacional .

Jóvenes investigadores en el VEB Elektronik Gera (Alemania del Este, febrero de 1984)

Los desarrolladores boomer no lo tuvieron fácil: se los consideraba nerds, forasteros torpes con una extraña pasión por las computadoras sentados frente a la pantalla todo el día. Hoy en día, la ingeniería de software es una profesión muy respetada. Muchos jóvenes buscan trabajo en empresas de software. Además de los avances tecnológicos, este es probablemente el mayor logro que los desarrolladores boomers han logrado para todas las siguientes generaciones. Ellos, hombres y mujeres por igual, hicieron la transición de la programación incómoda y nerd a la muy respetada profesión de la ingeniería de software. Le debemos mucho a esa generación por sus logros.

Dado que los boomers a menudo se consideraban nerds y la mayoría de la sociedad no tenía ni idea de qué era una computadora o qué software hacía, la comunidad de programación era relativamente pequeña en comparación con la actualidad. Hoy, en 2023, tenemos aprox. 28 millones de desarrolladores en todo el mundo. Representan el 0,29% de la población mundial. Apenas hay estadísticas de cuántos programadores existían en los años 80 y 90, pero puede esperar que ese número sea extremadamente pequeño. Tenían que llevarse bien entre ellos si querían que la informática y la programación progresaran.

En mis primeros años, noté personalmente que los desarrolladores boomer siempre miraban los hechos y nunca a la persona. Cuando presentaba argumentos, los evaluaban y nunca los ignoraban solo porque era joven e inexperto. Para mí personalmente ese es uno de los grandes legados de los boomers que nosotros, como las generaciones más jóvenes, debemos preservar siempre. Concéntrese en los hechos, no en las personas.

En mis últimos 25 años de programación e ingeniería de software, leyendo docenas de libros de los últimos 60 años, también tengo constantemente la impresión de que un conocimiento muy importante se pierde en el tiempo. Siento que nuestro trabajo como generación más joven es preservar el conocimiento de las generaciones anteriores, especialmente en informática.

Gracias.

Espero haber podido preservar parte del conocimiento con este artículo o al menos hacerte pensar sobre la herencia de la informática y la programación. Honrar los logros de las generaciones que nos precedieron y tener en cuenta su experiencia para todo lo que hacemos hoy. ¿Tiene algo que agregar a mi experiencia o tiene experiencia trabajando con las generaciones anteriores usted mismo?