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.
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?
