Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
No significa que es que las personas que tienen más tiempo en tecnología, entonces que son más viejos...
conocen más fundamentos, más la capa de abajo, entonces ellos son los mejores profesionales que los profesionales que tienen solo tres, cinco años, no son tan buenos porque hoy es más fácil, no, que ver, nada que ver, no hay tal cosa como un mal profesional o no hay tal cosa como que los que comienzan hoy en día no pueden llegar a ser buenos profesionales en nada, no es así para nada, ¿verdad?
Sin embargo, pues siempre en el momento del aprendizaje nos vemos con esa parte de qué tan profundo debo llegar. Entonces queremos hacer esa aclaración. Saber o no saber, bastantes capas de abajo no nos hace como tal necesariamente mejor.
Douglas (00:53)
Hola a todos y bienvenidos a un episodio más de Dev & Ops, este es su espacio favorito de desarrollo, tecnología, DevOps y su cultura en general. en este nuevo episodio, por supuesto, le doy la bienvenida a mi amigo y co-host, Juan Ramos. ¿Qué tal estás Juan? Bienvenido.
Juan (01:13)
Hola Douglas encuentro muy bien hoy el día de hoy. es un día tranquilito, ya vamos a grabar el episodio, lo cual me gusta mucho. También estuve viendo algunos vídeos sobre la serie que estoy viendo, Floribus, muy buena, la recomiendo. Así que venimos con toda la actitud para tener la plática del día de hoy.
Douglas (01:34)
mira que interesante, esa es la segunda persona que me recomienda esa serie, mi hermana también me hizo la recomendación y pues yo creo que la voy a tener que agregar a mi lista, a mi EQ.
Juan (01:47)
que por cierto,
se me ocurre que tal vez en algún episodio más adelante y bueno, las personas nos pueden dejar en los comentarios si les gustaría algo así podríamos revisar las tecnologías que se ven en algunas series porque mientras miraba estas series no paraba de saltarme preguntas de bueno, cómo hacen esto, cómo debe estar funcionando X-Technología y no sé, es interesante ver películas y series bajo esa lupa un poquito más crítica que no tiene que
realista la ficción obviamente, pero siempre es divertido.
Douglas (02:22)
Sí, muy interesante, yo creo que es buena idea, a ver si le llama la atención a nuestra audiencia que nos lo hagan saber. También podemos reaccionar a películas que simulan el mundo real, pero cuando está el hacker ahí, no deja de teclear, ataca, ataca, ataca, ataca, hacerle sub y ataca, ataca, ataca, empiezan a teclear.
Juan (02:36)
Si, si,
De hecho vi una que están dos personas en el mismo teclado en el mismo teclado hackeando algo no sé algo super raro son bien chistosos
Douglas (02:52)
si, y también yo vi una serie, la serie de flash, mire a flash haciendo, buscando algo más rápido a una velocidad que yo creo que cualquier gamer quiere ese teclado y esa conexión, bandwidth, reacciona a velocidad luz prácticamente más la fuerza que tiene ese teclado, no? si, ajá, por eso te digo, ese es el setup que quiere todo gamer, no? instantáneo
Juan (03:13)
y la pantalla, que refresh rate debería tener también.
Sí, es cierto.
Douglas (03:21)
Pero bien, me resulta interesante. Pero si te parece Juan, entremos al tema de hoy que también es interesante, o eso creo yo, que el tema de hoy va a ser bastante bueno y esperando como siempre generarle valor a las personas que nos ven y nos escuchan. Y hoy queremos hablar, queremos tener una conversación basado en estas dos preguntas que voy a hacer ahorita.
que son, hasta dónde necesitamos entender las capas de abajo o, que es una pregunta, la misma pregunta solo que con lo opuesto, qué tanto nivel de abstracción es suficiente y para darme a entender Juan, cuando decimos las capas de abajo es, cuando se trabaja en tecnología, las capas de abajo o abstracción son las cosas que pasan por debajo
al momento de hacer algo, pero yo arriba solo necesito ejecutar un comando, solo necesito llamar a una función, solo necesito arrastrar un elemento, porque a veces es gráfico, solo necesito arrastrar un elemento y para mí ya funciona, pero cuando en Windows yo le doy clic al botón de inicio y lo de clic que abre una aplicación,
En realidad, las capas de abajo lo que está ocurriendo es un comando que se ejecuta que llama a la aplicación y si te vas más abajo de ese comando hay diferentes instrucciones que están diciendo en esta parte de la memoria vas a ejecutar el programa y en esta parte del disco vas a leer y si te vas más abajo hay más niveles de abracción o hay más capas abajo hasta que llegamos a ensamblador y a la máquina hasta que llegamos a puras señales eléctricas interactuando directamente con el hardware
Juan (05:08)
Sí.
Douglas (05:13)
Entonces, la pregunta es qué crea.
Juan (05:15)
Es como en las películas
de Antman, donde se van al mundo... No recuerdo cómo se llama, microscópico, acuántico. Gracias.
Douglas (05:20)
cuántico cuántico cuántico se al mundo cuántico exacto
si seguimos con niveles de tracción llegamos al mundo cuántico correcto ahí vamos a ver nos vamos a topar con con an man y ese universo cuántico y pero queremos llevar esa conversación porque es muy interesante para la que tanto enfoque debemos ponerle a esa tracción a esos fondos fundamentos cuando estamos aprendiendo algo
Ya sea una tecnología nueva porque estamos estudiando, estamos aprendiendo, ya sea una investigación que estamos haciendo para implementar algo en el trabajo, ¿qué tanto debemos prestarle atención a las capas de abajo, a esas capas que están abstraídas por las tecnologías hoy en día, que siempre ha sido así, ya lo vamos a ir discutiendo a medida avanzamos, recordando que lo nuevo es en realidad lo que nos vuelve competitivos, porque yo puedo saber la capa de abajo.
muy bien, con varias capas hacia abajo, entenderla muy bien, pero nadie me va pagar para hacerlo de esa manera.
quieren que lo haga de la forma más rápida y más eficiente por eso tengo que aprovechar las nuevas interfaces que existen, nuevos comandos que existen, los nuevos frameworks, las nuevas herramientas, nuevos lenguajes incluso porque por eso hay lenguajes de alto nivel y de bajo nivel los lenguajes de alto nivel con una función nos hacen, nos pueden ahorrar no sé, 30, 50, 80 líneas de código si no es que más y no es una exageración, no es una exageración probablemente mucho más he visto el código fuente de ciertos
mandos en bash, el código fuente en C y es una cantidad de código absurda, absurda, o sea, yo solo tengo que ejecutar un comando en mi terminal, entonces sí, exacto, entonces qué tanto, qué tanto hay que bajar, para vos Juan, qué tanto te identificas con el tema, esto te da igual, te ha dado igual, le has puesto mente, yo obviamente te conozco un poco y tengo una idea de tu pensamiento alrededor de esto,
Juan (07:02)
Un LS.
Douglas (07:23)
pero quisiera que te expresara y nos lo dijeras, tal vez, un poco más claro.
Juan (07:27)
que tanto me interesa el tema, me interesa muchísimo. La verdad es que sí soy una persona que busca entender un poco cómo funcionan las cosas por dentro. Bueno, yo era el típico niño que me regalaban un carrito de control remoto y para mí era más divertido desarmarlo y ver qué tenía dentro que realmente jugar con él.
Entonces este tipo de temas la verdad es que siempre me han gustado pero también debo admitir Douglas que no me considero alguien que se obsesiona tanto con saber todos los pequeños detalles de cómo funciona cada una de las cosas que estoy utilizando.
pero pero de nuevo es como de hecho creo que por ahí vamos a ir hablando y desarrollando el tema es de tener un equilibrio y es de tener un cierto balance de hasta dónde llegar o hasta dónde es suficiente en lo personal tengo ciertas opiniones sobre cada una de estas cosas tengo una opinión de cuando es suficiente para mí y cuando deberíamos profundizar en diferentes temas pero tal vez sea por la forma en
como yo he ido aprendiendo o he ido iniciando en el mundo de tecnología también es desde mi perspectiva como programador donde algunas cosas me interesan genuinamente pero otras no tanto por ejemplo bueno toda la parte de qué se yo cómo funciona un cable porque están enrollados los cables y todo esto todas esas cosas que con el tiempo alguien me lo ha dicho alguien me lo ha comentado y
y es entretenido saberlo pero realmente no tengo un interés tan grande como si lo tengo con otras áreas. De nuevo es parte de la el lente con el que yo veo las cosas como programador pero bueno en resumidas cuentas me gusta mucho e incentivo siempre a todo el mundo a entender un poco pero también creo que hasta la fecha he sabido poner un stop hasta donde profundizar.
Douglas (09:36)
No está bien, me gusta, me gusta y me identifico con vos bastante Juan y bueno realmente me identifico desde lo primero que dijiste de que vos sos, vos eras ese niño que desarmaba los juguetes para ver cómo funcionan y yo también era así, lo recuerdo muy bien de hecho por ahí tengo probablemente algunas cuantas marcas de guerra en mi espalda porque a veces me iba más allá de los juguetes y desarmaba lo que no debía ¿no? Pero sí, también he tenido esa curiosidad de entender cómo funciona
Juan (10:02)
Sí.
Douglas (10:06)
entiendo tu punto de que no todo te genera la misma curiosidad y justo por eso hoy queremos enfocarnos realmente en platicar alrededor de qué tanta producción es bueno o qué tanto debo prestar la atención a las capas de abajo en lo que hago en mi rol, verdad, ya sea alguien como programador, alguien como administrador de base de datos, alguien como network admin, como sysadmin, etcétera.
Juan (10:25)
Claro.
Douglas (10:33)
Y como siempre Juan, queremos hacer las aclaratorias del caso cuando es necesario hacerlas. Y en este caso yo considero que es necesario. es que primero me gustaría aclarar a las personas que nos ven y nos escuchan que nada de esto es pensando como en hate, en tirar hate a la gente como se dice hoy en día. No significa que es que las personas que tienen más tiempo en tecnología, entonces que son más viejos...
conocen más fundamentos, más la capa de abajo, entonces ellos son los mejores profesionales que los profesionales que tienen solo tres, cinco años, no son tan buenos porque hoy es más fácil, no, que ver, nada que ver, no hay tal cosa como un mal profesional o no hay tal cosa como que los que comienzan hoy en día no pueden llegar a ser buenos profesionales en nada, no es así para nada, ¿verdad?
Sin embargo, pues siempre en el momento del aprendizaje nos vemos con esa parte de qué tan profundo debo llegar. Entonces queremos hacer esa aclaración. Saber o no saber, bastantes capas de abajo no nos hace como tal necesariamente mejor.
Hoy en día la tecnología ha avanzado y busca que hagamos las cosas mucho más rápido y los profesionales buenos son los que aprovechan esas cosas nuevas para ser más rápido siendo igual de efectivos o posiblemente mejor. Entonces solo queremos aclarar eso, ¿verdad? Pero la plática es interesante tenerla y yo creo que va a generar valor y por eso estamos decidiendo discutir ese tema. Y entonces, habiendo hecho las aclaraciones y entrando en tema,
Fíjate que yo estaba meditando que este tipo de interrogantes realmente siempre ha existido. cree que hoy en día, como tenemos acceso a información, creemos que el Internet ha avanzado un montón y sobre todo hoy en día con la inteligencia artificial, creemos que es una plática o un interrogante de estos tiempos. ¿Qué tanta atracción tener? Porque hoy todo es tan rápido, porque hoy le puedo pedir a la IA un script, una aplicación entera incluso.
que que un script una aplicación entera le puedo pedir y ella lo va a hacer entonces pero no la verdad que no fíjate que yo recuerdo cuando comencé con linux en el año 2000 exactamente si no me equivoco justo en el mero año 2000 que comencé con linux
Juan (12:41)
Sí.
El Y2K.
Douglas (12:58)
Sí, fue el 2001, por tarde fue el 2001, creo que fue el 2000, cuando yo empecé ya comenzaban a salir y a tener auge los package manager para instalar paquetes en Linux, package manager como JUM.
o como el APT GET, que hoy en día son las APT por cierto, en aquel tiempo era APT GET, APT-GET, todavía lo puedes usar como APT-GET, de hecho creo que APT, no sé si le cambiaron el nombre al binario o solo es un alias, trabajo más con distribuciones de Red Hat, por eso es que no lo sé específicamente, pero fíjate que ya estaban, ya estaban estos package managers y tenían cada vez más auge.
Juan (13:21)
No,
Douglas (13:39)
Sin embargo, te instalaban como los paquetes más comunes del sistema operativo que el kernel y paquetes que vienen más por defecto. Pero ya casi que cualquier aplicación que vos necesitabas todavía había que hacer builds manuales.
Para que no sepan Build Manuales era bajar el código fuente, digamos en GeneX, no estaba en GeneX en ese tiempo por cierto, pero voy a usar GeneX como ejemplo, digamos en GeneX, era bajar el código fuente del paquete y correr un comando monstruoso, va donde hacíamos un make build y entonces él empezaba a ver ahí y corría un montón de cosas y se topaba con que había una dependencia que no estaba, faltaba una dependencia Open SSL.
para poder instalar, para poder tener abrir el puerto 443 la dependencia de OpenSSL entonces había que ir de manera manual y a veces primero hacer el build de OpenSSL manual y me funcionaba entonces ahora actualizar mi build de NGINX apuntando a ese OpenSSL y quería volver a hacer el build y ahora había otra dependencia que me fallaba y tenía que por tal vez esa dependencia así la podía instalar con apt-get y así iba hasta que lograba hacer el build
Juan (14:53)
Sí.
Douglas (14:55)
de la aplicación y luego instalarla. Eso creó en mí Juan, pues un muy buen conocimiento de todo lo que tiene que ver con las dependencias de un paquete a nivel de sistema operativo y cómo realmente funciona. Sí, sí, De hecho, y qué bueno que existía ya Make, porque entonces si en lugar de Make Build hubiese sido a saber qué gran comando.
Juan (15:09)
¿Ya existía el Meika en ese entonces? Ok. Sí.
Sí.
Douglas (15:21)
que a veces, más que a veces con make, pasarle un montón de flak para apuntar a 5 o 6 dependencias se volvía un gran comando, sin make, hubiese sido todavía más complejo.
Juan (15:31)
Sí.
Douglas (15:33)
Pero eso
creo en mí, fíjate, ese entendimiento. Hoy en día, yo no sé cuántos años tengo de donde hacer build de un paquete. Ya no recuerdo. Incluso eso me llevó a luego yo hacer mis propios RPMs, mis propios paquetes, a construirlos yo mismo de tal vez aplicaciones internas o de otros servicios o mi propia, mi propia, nuestra propia, perdón, estándar de NGINX. Ya era un paquete interno que de manera interna lo distribuíamos y así lo instalábamos, verdad. Qué tiempo es eso.
Juan (15:47)
Ok
Douglas (16:03)
Hoy en día Juan todo tiene un repositorio y jump install, install, esa la hora.
Juan (16:04)
Sí, sí, sí.
de hecho
cuando me topo con que se yo alguna utilería algún software que quiero instalar y me dirigen a hacer un build manual ya de inmediatamente lo descarto no porque no quiera hacerlo sino porque me da la me da a entender que todavía no está listo que todavía está en una etapa muy temprana entonces creo que bueno ya te da una
una pauta de cómo ha cambiado la industria.
Douglas (16:45)
Sí, sí, sí. Y sí, te da esa perspectiva, Y antes esa era la norma, tenías que bajar el código fuente y que un proyecto estuviese bien documentado, que comandos correr para hacer el build y luego una instalación, ese era un proyecto sólido.
Juan (16:50)
y antes sí.
Douglas (17:01)
Sin embargo Juan, yo tengo todo este entendimiento, este conocimiento, toda esa experiencia y tengo muchísimos años pero muchísimo, probablemente más de una década, donde no hago el build de un paquete. Entonces, ¿qué tanto me destaca eso sobre otros profesionales hoy en día que jamás han tenido que hacer un build?
Probablemente un poquito, probablemente mucho, probablemente a veces y es aquí donde estamos teniendo la conversación, verdad, y quiero avanzar en la conversación, ¿por qué entender las capas de bajo nivel? ¿por qué es importante, Juan? Porque es importante aunque es aburrido, o sea muchas veces aunque sea temas que disfruto.
cuando ya me voy muy abajo y si me querés explicar ensamblador me voy a aburrir o me vaya mala atención al principio pero ya luego de un tiempo pues no, no, quiero, dame un pipeline y lo voy a hacer más rápido ¿no? pero porque es importante entonces las tecnologías, las herramientas han ido evolucionando y que tan importante es, y aquí quiero contar una anécdota, una anécdota
Juan (17:45)
jajaja
Douglas (18:09)
En este trabajo en el que vos y yo nos conocimos, siempre hago referencia a él, así digo, que el que vos y yo nos conocimos. Sí, sí, sí, Buenos tiempos. Pero recuerdo en este lugar, cuando ya estaba, esto fue muchos años después de que yo inicié, cuando ya estaba en un departamento de APM que monitoreaba las aplicaciones, recuerdo que ellos usaban Splunk para centralizar los locks.
Juan (18:14)
Sí, me gusta esa forma de referirnos.
Douglas (18:36)
los diferentes servidores hacían forward de sus logs a Splunk y desde Splunk tenían un montón de analíticas para revisar los logs y con eso generaban dashboards, KPIs, todo lo que te puedes imaginar.
Juan (18:43)
Sí.
Douglas (18:49)
Algo soñado al principio que yo trabajaba y me tocaba hacer esas cosas junto con otras mil cosas, no estaba yo en ese departamento. Surgió la necesidad, y no recuerdo los detalles a cabalidad, pero surgió la necesidad de hacer un análisis de un servidor como Legacy o Standalone que tuvieron un problema, no sé si es que tuvieron un problema, o ocupaban sacar métricas de utilización. El asunto es que ese servidor...
no tenían como instalarle el forwarder de Splunk y mandar esos logs. Entonces los analistas estaban viendo de manera manual, intentando sacarle información, pero lo que tenían eran puros log files, ¿no? Como se le dice raw log files.
Juan (19:35)
Sin filtros, sin categorías, ni nada.
Douglas (19:38)
los archivos de log en el sistema operativo y
algunos están rotados y cuando están rotados para quienes no sepan rotarlo es un servicio interno de Linux que comprime la parte de los logs y mantiene ciertas copias y eso es para que un log file no vaya a llenar el disco duro. Entonces ya no recuerdo si es que yo ofrecí ayuda o si es que ellos se acercaron a pedirme ayuda. Ya no recuerdo de quién fue la iniciativa. El asunto es de que
Juan (19:45)
Ajá.
Douglas (20:07)
Cuando yo entré al servidor, en cuestión de minutos,
Ya había logrado hacer el parcial de manera manual los logs con comando, con puro comando de bash, con grep, con AWK y con diferentes métricas y validaciones. Si un status code es diferente a 200, imprimime esa línea y que si no me imprimas toda la línea, solo imprimime el pad y imprimime el error, lo que querrás.
Juan (20:32)
no, no, no,
Douglas (20:42)
porque antes de que existiera ese departamento, yo era, no era yo solo. Marvin, un compañero y gran amigo con el que trabajaba él y yo, nos tocaba hacer ese análisis de manera manual. Ese era parte de nuestro día a día, años anteriores. Entonces para nosotros fue...
Juan (21:01)
Ustedes eran el Splunk
de la empresa.
Douglas (21:03)
Nosotros éramos el Splunk, era el Parsons, nosotros éramos el Forwarder, nosotros éramos los Dashboards, junto con los que montábamos servidores y formatíamos, instalábamos Hypervisor, nosotros éramos todo en ese momento. Pero la empresa creció, ¿no? La empresa creció.
El punto es que yo pude hacer eso rápido, les expliqué cómo lo hice y por sí les presentaba en el futuro, verdad. Esta semana recién pasada, aquí en Fuel tuve de una casualidad enorme la necesidad de hacer lo mismo para dos clientes diferentes que tenían servidores legacy.
no tenían nada, no tenían nada, ningún lugar central de logs, verdad? y uno de ellos necesitaba hacer troubleshooting de un problema que tuvieron en su web server y yo pude identificarlo de manera relativamente rápida y para otro de ellos se sacaban, se necesitaban sacar métricas de bandwidth, de ancho de banda que ellos consumen y yo pude hacerlo de manera manual y eso me llevó a meditar y decir hey
aquí esto se volvió útil ¿Cuántas tareas he tenido desde la última vez que hice eso? probablemente miles ya no recuerdo y me hizo pensar ¿vale la pena haber sabido esto? ¿qué tanto me destaca esta una tarea? una de 300 tareas que tanto me hace destacar no lo sé, no lo sé pero cuando es necesario podés hacerlo
Juan (22:33)
Sí.
Douglas (22:33)
pueden
resolver y fíjate que tengo para concluir con anécdotas pero ya sin ponerle nombres ni situaciones específicas. ha pasado muchas veces con cloud engineers, con system engineers que no tienen un trasfondo, tal vez vienen de trasfondo de programadores.
o no han tenido mucha experiencia porque comenzaron directamente en la nube cuando tienen situaciones relacionadas a lo que es el networking en la nube, verdad, como ellos ahí lo prendieron en la nube y ahí lo hacen, cuando tienen situaciones, toca arquitectar algo más complejo o toca hacer troubleshooting de algo más complicado, normalmente ahí tienen ciertos problemas o ciertas limitantes, limitantes que por gracias a Dios yo no tengo porque como acabamos de discutir, a mí me tocaba
Juan (23:09)
Ok.
Douglas (23:22)
conectar esos servidores, conectarles el cable de red, punchar el pass panel, pedir los puertos, pedir las pilas, pedir el routing, configurar el routing dentro del servidor, o sea, a mí me tocó hacer eso, entonces cuando yo voy a la nube y tengo que trabajar con networking con todo lo que tiene que ver, VPC, subnet, subnet privadas, subnet públicas, internet gateway, routing interno, que VPC peering y todas esas cosas, pues yo no tengo problema entendiendolo porque yo lo trabajé de manera directa.
Y no es que un cloud engineer que comience hoy no puede alcanzar ese nivel solo porque ya no tiene la oportunidad de trabajar en un data center. Por supuesto que lo puede alcanzar y por eso la incógnita, ¿Qué tanto tiempo le es bueno a un cloud engineer que viene comenzando ponerse aprender de conceptos más bajos, de más de bajo nivel de networking?
más allá de lo que le ofrece el dashboard de AWS o de Azure o de cualquier plataforma en la que está trabajando, ¿no? ¿Qué tanto le conviene ponerse a buscar entender esos conceptos, ver cómo funciona, tratar de entenderlos, bajarse un emulador de un router Cisco o Juniper y hacer pruebas, instalar en Linux, Quagga Routing o instalar servicios de routing y hacer pruebas. ¿Qué tanto le conviene eso?
para entenderlo mejor y luego arquitectar sus soluciones. Y es aquí donde te paso la guitarra porque ya me eché yo como tres canciones. No sé qué ejemplos similares nos podés dar vos de la parte de programación porque yo, por supuesto, por mi experiencia, me enfocado más en lo que tiene que ver con el área de sysadmin.
Juan (24:59)
Bueno, de darte algunos ejemplos que estaba recordando mientras hablabas, solo me gustaría mencionar que cuando hiciste la pregunta de si eso te daba cierta ventaja o si eso te hacía destacar de alguna manera, yo diría que sí. Yo diría que si bien no vamos a utilizar esos conocimientos el 100 % de las veces, hay un 1 % donde si lo vamos a necesitar.
y si lo tenemos que bueno que bueno que lo vamos a poder tener a la mano y poder resolver rápido así como dijiste en cuestión de minutos ya le habías conseguido los logs ya habías hecho búsquedas filtros y todo todo la cosa que de otra manera hubiese sido más difícil pero pero bueno tal vez ya podemos ir
Douglas (25:45)
Juan,
disculpa, antes de que entre a tu pregunta y ya que tocaste esta parte en la que vos pensas que si me hace destacar o si haría destacar un profesional estas cosas tal vez incluí en tu respuesta que tanto luego se vuelve abstracto para nosotros mismos
Llega un punto en que nosotros mismos, nuestra propia mente, tanto lo que he aprendido o las experiencias que he tenido, nos hace tener ese conocimiento que se vuelve abstracto incluso para nosotros. Y ya actúo de manera automática, pero eso me lo ha generado el hecho de que he aprendido esos conceptos de más bajo nivel. Yo recuerdo en episodios anteriores que vos a veces afrontás cosas.
Juan (26:07)
mmm
Douglas (26:34)
con mucho conocimiento abstracto donde decís, no, pero yo siento que esto que hice es fácil y yo lo estoy viendo desde afuera y digo, no, no fue fácil. sea, Juan ha pasado por un montón de cosas, ahora él le parece fácil. Realmente no lo es, ahorita que tocas ese punto, entonces me haces meditar en ello y te regreso para que lo incluyas en tus ejemplos de programación. ¿Vos qué pensás que tanto luego llega a volverse abstracto el conocimiento para nosotros mismos?
Juan (27:03)
Si, después se vuelve... es que claramente llega un punto donde se vuelve casi memoria muscular para nosotros, cosas que hacemos día con día. bueno, tal más adelante podemos ir dando como ya puntos más fuertes de cómo y por qué pensamos estas cosas,
porque si bien es cierto, estoy diciendo en este momento que si te da un valor no digo una ventaja significativa, una ventaja abismal pero si otorga un valor único a los profesionales que entienden cosas un poquito más profundas entienden los conceptos, los fundamentos pero es cierto que tampoco es el gran diferenciador que sea, bueno, que sea la clave ¿no? o tal vez sí
No lo sé, depende de caso a caso. La verdad es que en lo personal Douglas, yo soy de las personas que siempre intento ir utilizando lo más nuevo. Yo siempre estoy tratando de buscar lo más nuevo que esté hoy en día y te puedo dar varios ejemplos. Uno, fuera del ámbito profesional, en lo que es mi computadora personal,
hubo un momento donde yo todo lo instalaba por línea de comandos porque bueno yo utilizo Linux entonces todo lo instalaba con la terminal hoy en día ya no lo hago ya mi preferencia va orientada hacia los flatbacks y solo como contexto rápido flatbacks es como una
relativamente nuevo paquete para aplicaciones de Linux donde no importa si estás en Ubuntu, Red Hat o Arch el Flatpak va a correr. Hoy en día utilizo más eso y ya no me importa tanto buscar cómo agregar los repositorios, cómo agregar esto y lo otro.
Y de hecho antes de eso, agregar un repositorio para luego descargar el paquete, pues no lo hacía manualmente. Lo hacía utilizando la misma línea de comando que ya te lo hacen automáticamente y así ¿no? Creo que depende mucho de la época y el momento de cada quien Douglas donde cuando yo inicié en el mundo de tecnología había un contexto histórico que es diferente al que está en este momento para una persona que iniciando.
De hecho te comento que cuando yo estaba iniciando y aprendía... Estaba aprendiendo todos los conceptos sobre HTML, CSS Lo nuevo de ese momento era el llamado HTML5 y CSS3 Eso era lo que sonaba en los foros o al menos eso lo que yo miraba
y bueno, hablaban sobre las nuevas etiquetas, nuevas propiedades de CCS que hoy en día realmente ya ni siquiera se utiliza ese marketing eso fue puro marketing para las nuevas etiquetas hoy en día no, hoy en día se hace una nueva, se lanzan etiquetas nuevas para HTML o propiedades nuevas de CCS pero en ese entonces eso era lo nuevo
Y recuerdo Douglas que en ese momento yo... eso era lo que buscaba, buscaba específicamente tutoriales que hablaran sobre HTML5 y CSS3 y cualquiera que hablara sobre versiones anteriores, que de nuevo seguían funcionando las versiones anteriores, pero cuando encontraba tutoriales que no hablaran sobre lo nuevo, no los miraba. No me interesaba aprender lo viejo, decía yo. Realmente...
Fue algo que me dio una gran ventaja, no tanto, realmente solo es que aprendía las etiquetas que estaban nuevas en ese entonces, pero con el tiempo eso dejó de ser relevante. De hecho, algo que yo he notado es que muchos desarrolladores o muchos tutoriales que hay en línea hoy en día, en cuanto a HTML, todo lo van enmaquetando utilizando etiquetas div y listo.
Ahora, ¿eso es bueno o eso es malo? Depende de cada caso, porque como sabemos en HTML hay etiquetas que el section etiqueta aside etiqueta bueno, muchas etiquetas ¿no? Y estas tienen un por qué en el navegador Así que también conocerlo las otras te da te otorga un valor al momento de crear un producto que esté un poquito más pulido ¿no? Y yo creo que ese es el
la ventaja que tenemos cuando conocemos algún concepto más profundo cuando conocemos ciertos procesos que están pasando por detrás eso no lo que nos da es la ventaja para luego crear productos o soluciones que pueden estar preparados para mayores cambios también recuerdo por ejemplo en programación
Por ejemplo en Go, recuerdo que algo que siempre sucedía con Go y esto era más que todo un glitch, un bug Cuando haces un ciclo en Go y asignabas una variable, típico for each, eso te da una variable Vamos a decir que estás recorriendo, voy a dar una clasesita rápida de Go Tendrás una colección o un arreglo de ciudades, cities
y luego asignamos una variable, la variable city entonces por cada iteración, city tiene el nuevo valor de la siguiente ciudad bien, en Go sucedió un bug donde dependiendo de cómo estaba ejecutándose esa variable no se actualizaba correctamente y esto a veces podría ser un problema en unit tests o en ciertos procesos que tenían que ser muy muy precisos
Bien, hay un hack para eso. En cada uno de los ciclos asignabas la variable igual a la misma variable. Entonces tenía city igual a city. Y con eso se solucionaba. Eso ha el hack durante toda la vida de Go, pero hace poco, hace relativamente poco, no sé si una o dos actualizaciones atrás, eso ya no es necesario.
Entonces aquí viene la pregunta, ⁓ que nos obliga a reflexionar sobre este tipo de situaciones. ¿Saber cómo se hacía antes y saber ese tipo de conceptos me da una ventaja hoy en día? Pues ya no. Realmente ⁓ ya no importa. Y así yo considero Douglas que hay muchas cosas que si bien en su momento fueron muy útiles, por cómo funciona la industria ya no son un diferenciador. Ojo, saber
pues tampoco es malo tampoco tampoco te quita y está muy bien
pero realmente por como esta la industria hoy en dia ya no se vuelve un diferenciador y por eso menciono que depende mucho de la situacion de cada quien porque no es lo mismo alguien que esta buscando trabajo y tiene que enfocarse en lo que esta actualmente en ese momento pues yo diria que los fundamentos mas low level podriamos pausarlos por un momento y enfocarnos en lo que se hace hoy en dia pero bueno realmente con ese tipo
de casos donde antes se hacía de una forma, ahora se hace de otra, pues no lo sé, no hay un diferenciador y rapidito te doy otro ejemplo, en su momento yo recuerdo hacer ciertas aplicaciones en javascript donde yo creaba manualmente de forma dinámica los elementos del navegador
con los elementos me refiero a un botón, un drop down y todas estas cosas. Hoy en día...
no se hace así, hoy en día lo vamos a hacer a través de un framework react, angular, view y ya no tenemos que hacer estos llamados de manera, vamos a llamarlo nativa en javascript, sino que nos apoyamos en los frameworks para crear o quitar de manera dinámica incluso el simple hecho de asignar ids dentro del navegador
pues ya el mismo framework se encarga de eso de nuevo saber hacerlo de la manera pues más de bajo nivel vamos a decirlo no te quita nada de hecho es bueno pero al momento de una contratación o al momento de hacer tu trabajo del día a realmente considero que no representa una diferenciación tan grande pero ojo siempre considero que saberlo
va a tener su recompensa en cierto momento. Vale la pena. Tal vez ya no por la acción en sí, sino por otras cosas. Y de nuevo, tal vez vamos a ir desarrollándola más adelante. Pero sí, de hecho, eso lo que yo pienso, Douglas, por eso siempre trato de no aferrarme tanto a es que yo así lo hacía y así lo he hecho siempre, no necesito de...
Creo que es mejor siempre ir actualizándonos, es lo más sano, creo yo.
Douglas (36:42)
Sí, muy de acuerdo con eso que decís, que lo mejor es irnos actualizando. Me gusta en general el tema justo porque no hay una respuesta necesariamente tan fácil y hay bastantes depende en él. Por supuesto, la perspectiva que vos traes y me gusta algo que dijiste.
que consideras que no es que necesariamente me va a ser mejor que otras profesionales y me va a ser ganar un trabajo antes que ellos porque probablemente la conversación ni siquiera salga al momento de la entrevista, no. Si te ocupan para que hagas Next.js no te van a preguntar si usaste jQuery, ejemplo, no. O sea, es para Next.js y necesitan que sepas Next.js. ¿Verdad? Pero me gustó que dijiste.
Juan (37:21)
Ja ja ja
Sí.
Douglas (37:30)
pero te aporta valor a vos como profesional, sea, te agrega algo de valor. ¿En qué momento ese valor se necesita para el puesto de trabajo? Pues van a haber poquitas opciones o poquitas situaciones en las que vas a necesitar ese valor y ahí vas a destacar. Puede que sea una situación, en la que no va a ser suficiente para que te contraten por sobre alguien.
pero puede que sea una situación en la que si se necesitan hacer despidos en la empresa en la que estás digan, fíjate que juan no porque él lo hacía antes jQuery y él entiende bien cómo funciona llamar a hacer llamados a la base de datos desde front end y te acordas aquel cliente que una vez tuvo un problema juan lo resolvió entonces puede que puede que ya estando en la empresa esas cositas si agreguen ese valor que te permitan destacar va a ser grave
Juan (38:11)
Sí.
de hecho,
Douglas (38:25)
algo.
Juan (38:27)
perdón que te interrumpa Douglas pero tenés razón puede que en algunos casos funcione y lo sé de primera mano porque de hecho en
cuando en una entrevista de trabajo me hicieron una pregunta algo así y la pregunta era muy simple pero estoy seguro que para muchas personas y más cuando vienen empezando es un tema que no se manejan tan intuitivamente y la pregunta era cómo harías un ciclo cómo recorrerías unos datos sin utilizar las palabras reservadas de for, forage o while y bueno ahí la respuesta era
haciendo un programa recurrente utilizando recursividad entonces saber sobre esos temas que de nuevo no los utilizadas en tu día a día como programador yo no conozco alguien que en su día a día necesite utilizar recursividad es muy raro pero conocerlos es bueno y por eso tengo de primera mano me ha pasado donde me han hecho esa eso fue una pregunta crucial para la contratación
Douglas (39:35)
Sí, fíjate que, bueno, a mí no para la contratación, pero todos esos ejemplos que te puedo dar rapidito ya estando en el lugar, en esta empresa donde vos y yo nos conocimos, había un sistema una vez que...
Crachaba, fallaba y nadie sabía por qué, los logs no mostraban nada, nadie miraba nada, nadie entendía nada, crachaba. Entonces ya estaban decepcionados, los ejecutivos estaban decepcionados por completo. Entonces pues les dije yo, déjenme analizarlo. Y yo lo que hice fue generar un core dump del sistema operativo como era el kernel, genera un dump.
Juan (40:11)
Ok
Douglas (40:13)
todo el output que está haciendo el kernel de manera interna al momento que se genera un error entonces generé el core dump, lo agarré él en ese core dump y ahí identifique dónde está el problema a estas alturas no recuerdo cuál era el problema exactamente pero eso no se lo guiaba en ningún lado, ni en web server, ni en server, ni en el edge, en ningún lado y ahí pude identificar lo que era y se corrigió el problema no había nada más en la empresa que lo supiera hacer solo yo
Juan (40:14)
Sí.
Ok
Douglas (40:42)
entonces ahí hay un valor diferente. Ahorita en la empresa en la que estoy en Fueled, antes TENUP, un cliente que tiene su proveedor de nube un poco más pequeño, quería un cliente de los grandes que estaban en ese proveedor un poco más pequeño antes, necesitaban agregar nuevos discos y entonces vino el proveedor y dijo mire necesitamos vamos a agregar este tipo de tarjetas de fibras a los servidores
Juan (40:45)
Sí.
Douglas (41:09)
necesito que nos den su aprobación porque esto les va subir el billing x porcentaje. Entonces como yo trabajé en data centers, estoy en una empresa que es full nube Juan, full nube, pero como yo trabajé data centers yo entendí perfectamente que lo que ellos iban a hacer y les dije, hey, pero eso no nos va a dar la mejor alta disponibilidad, necesito que pongan un switch de fibra, esto es para conectar discos duros que se conectan por fibra y son los switches normales de fibra que usas en networking, se usan para eso también. Entonces les dije necesito que me pongan un switch de fibra,
Juan (41:18)
Ok
Ok
Douglas (41:39)
para que tengan redundancia entre el control del arreglo de discos y los servidores. ⁓ pero esto le va a costar un poquito más. No, pero estoy seguro que el cliente lo va a preferir así por su redundancia, por su alta disponibilidad. Y resultó ser así. Y nadie más en la empresa tenía esa experiencia que tengo en ese sentido. por eso la conversación es tan interesante, cada cuanto pasa, ¿por esto me van a contratar? No, es más.
Juan (41:59)
Sí, sí, sí.
Douglas (42:08)
Yo creo que resultó irrelevante, probablemente mi experiencia en data centers al momento en me contrataron acá porque todo es cloud, ¿no? Pero han estado estas ocasiones donde uno destaca. Y la conversación es muy interesante. Si querés avancemos, me parece muy entretenido. Y hay algo que, un fenómeno que me gustaría que miremos, no un fenómeno, algo interesante que perdemos de vista en realidad. Y es que como hoy en día tenemos a la inteligencia artificial,
Juan (42:35)
Ok.
Douglas (42:38)
eso es lo actual, lo de momento y debemos usarla. sea, profesional que no esté usando la inteligencia artificial está mal invirtiendo tiempo. Hay que usarla de manera responsable, de manera profesional, pero hay que usarla. Pero creemos...
Que la inteligencia artificial es la que crea ese gap, esa falta, ese brinco, entre que no hay necesidad de verlo del nivel bajo porque la inteligencia artificial lo hace. Pero en realidad ese concepto, esa situación de no querer ver la capa de abajo...
siempre ha estado porque antes del inteligencia artificial teníamos Google, las búsquedas en Google teníamos Stack Overflow, yo sé que aquí todos los que están viendo y escuchando nos conocen de Stack Overflow y cuánto de los que nos ven y nos escuchan solo copiaron y pegaron una configuración de Nginx, una función de JavaScript en sus scripts, sus aplicaciones, sus configuraciones, solo la copiaron y pegaron y más
abajo había como una página y media donde el que dio la respuesta explicaba por qué funciona pero no lo leímos solamente agarraban el código y lo ponían yo recuerdo en algún momento ver a alguien ahí en Stack Overflow que puso la búsqueda y vio el código y dijo esto se parece a lo que necesito y lo copió y lo pegó
Yo, pero ¿por qué decís que es que necesitás? ¿por qué te parece? Sos un, como le dije yo, sos un interpreter. O sea, interpreta código tu cerebro, ¿no? Porque yo, cuando miro algo que digo, parece que esto me sirve, leía por qué lo, por qué es que lo, por qué la persona lo está recomendando y cuando no lo decían ellos, entonces me iba a documentaciones a verificarlo.
Juan (44:27)
No,
Douglas (44:40)
Pero lo que quiero resaltar aquí es que eso de no verlo por la necesidad de la inteligencia artificial conceptualmente siempre ha existido. Antes de eso también tenías los how-tos, son estas guías que te encontrabas en internet con cómo instalar WordPress con NGINX, cómo instalar tal herramienta, cómo instalar tal aplicación, cómo crear un to-do y entonces eran how-tos.
Juan (45:04)
Mm-hmm.
Douglas (45:10)
diseñados para que entendas cómo funcionan para crear ambientes de prueba pero no faltaba que agarraba eso y quería poner eso en producción sin alta disponibilidad, sin chequeo de seguridad, sin nada listo para producción pero como ese le funcionó así lo agarraba y así lo ponía
por no tomarse el tiempo de entender el bajo nivel, de venir y decir, estoy poniendo algo que tiene single point of failure, estoy poniendo algo que no tiene seguridad, que no tiene verificación extra, etcétera. Y antes de mi tiempo, pues no sé qué existía, probablemente los libros.
Digo, yo creo que sí. De hecho, yo alcancé a tener que ver libros para estudiar cosas y recuerdo ver gente. Yo no estuve en la universidad. Las personas que nos siguen desde ese tiempo saben. Pero alcancé a ver gente con unas biblias así de libros de C++, con un montón de rutinas que las estaban transcribiendo de libro al código para probarlas. Pero mi punto con esto, Juan, que hoy creemos que es la inteligencia artificial que ha avanzado tan rápido que nos ha quitado esa necesidad de entender lo que
Juan (46:03)
Sí.
Sí.
Douglas (46:19)
debajo porque nos genera todo, pero en realidad conceptualmente siempre ha existido. ¿Por qué traigo esto a la conversación Juan? Porque entonces me hace pensar que es más una actitud humana, una actitud nuestra, una actitud profesional, de que buscamos abstraer eso y a veces nos queremos ir por lo fácil.
y solo hacerlo trabajar. De nuevo, estamos valorando que es más importante enfocarnos en lo nuevo. Vos lo dijiste, yo le hago eco. Es más importante enfocarnos en lo nuevo. No nos podemos quedar con que antes se hacía así. Pero hay un motivo. Los retos de ayer son los que han creado la tecnología que tenemos hoy.
Los retos del pasado son los que han creado la tecnología que tenemos hoy y los retos que hoy estamos enfrentando y queremos superar son los que están desde ya formando la tecnología que vamos a tener mañana. Soné bien profundo con esto Juan.
Pero es una realidad, así ha sido siempre. Eso ha pasado aún entre nosotros, ¿no? Las soluciones que hoy tienes en tu trabajo son motivo de problemas que tenían antes y que buscaron solventarlos y ahora los hacen de la mejor manera. Y ya tienen problemas identificados que los están trabajando, que en el futuro cercano, o futuro mediano, van a tener cosas más interesantes que lo van resolviendo, ¿no? Pero existe esa necesidad humana donde solo queremos hacerlo y continuar, siempre ha existido y hoy queremos culpar a la inteligencia artificial.
Juan (47:20)
Sí, sí.
Mm-hmm.
Douglas (47:48)
Entonces, no sé Juan, en tu proceso de aprendizaje vos o en el trabajo, si has notado esto que yo estoy mencionando, que siempre ha existido esa parte humana de en realidad hacerlo de hoy y avanzar sin querer profundizar más.
Juan (48:04)
Sí, claro, totalmente, de hecho...
en mi trabajo, así como lo mencionas, tenemos soluciones que las hacemos de cierta manera hoy en día y tienen un porqué y tienen un motivo que en el pasado nos dieron error o con el tiempo subieron los requerimientos y ahora necesitábamos darle soporte a otras cosas y fue expandiéndose entonces si alguien, por ejemplo, cuando yo inicié en la empresa empecé a ver cómo hacían todo al inicio no entendía y muchas cosas yo decía
pero por qué lo hacen así, Es la mentalidad de todo programador, dicen esto no sirve, hay que volverlo a hay que refacturizar todo. Pero cuando empezás a TDDNs y empezás a ver cómo funciona, entendés el por qué. Y...
Y aquí es donde viene el balance que creo yo que hay que tener porque si bien entender el por qué hicieron algunas cosas, por qué utilizan tal solución puede ser interesante. Pues eso no quita el punto de que para realizar mi trabajo tengo que hacerlo como está, independientemente si conozca el trasfondo o no. Entonces yo la manera en que lo he hecho Douglas es que
Me enfoco mucho en aprender cómo funciona y cómo utilizar la herramienta, la solución o cualquier cosa de tal manera que me funcione.
mi disculpa, tuve un problemita técnico te mencionaba Douglas que considero que siempre es bueno aprender lo nuevo
y aprender lo viejo o los conceptos más profundos en la manera que sea necesario o que sea posible. Yo insito a todo el mundo a que profundice en todo lo que pueda y que sea relevante para ellos. Como mencionaba, para mí es muy importante entender o saber un poco de cómo funcionan algunas cosas, ya sea en programación en general o del lenguaje que estoy utilizando en ese momento.
tal vez no tanto de como alguna solución para hacer el deployment, para hacer el CICD que de todas maneras es beneficioso entenderlo y saberlo lo básico pero tal vez no las cosas más profundas que son la responsabilidad de otro departamento así que desde mi punto de vista yo así lo veo Douglas y de hecho cuando mencionabas Stack Overflow yo también aplicaba lo mismo yo hacía la misma estrategia donde buscaba la solución en Stack Overflow
lo traía mi código y seguía adelante y no fue hasta que el jefe que yo tenía antes en la empresa en la que trabajábamos me dijo lo siguiente, dijo deje de leer esta cover flow y vaya a la documentación
Y realmente esa mentalidad me cambió mucho la forma en cómo yo afronto los problemas porque es muy fácil irnos a Stack Overflow, irnos a ChatGPT y preguntarle cómo hago tal función o hacerme una aplicación. Pero qué pasa cuando no funciona? Qué pasa cuando hay un error? No vamos a saber qué es lo que está fallando. No vamos a saber incluso si aunque funciona, es la mejor forma de que funcione. Es la manera mejor.
la manera más segura, no lo sabemos. Es sólo hasta que entendemos los fundamentos de la documentación, del lenguaje, la solución que estamos entendiendo que realmente vamos a poder utilizar estas herramientas, estas soluciones de la mejor manera. Y siempre de nuevo, yo creo que aprender cualquier cosa no es una pérdida de tiempo, no es un problema, pero sí entender que algunas...
dependiendo de la situación no van a ser tan relevantes y te doy un ejemplo muy muy muy simple en la programación es muy importante dependiendo de lo que estemos haciendo la el alineamiento creo que sería la palabra de la memoria y esto se reduce a si yo estoy creando un objeto vamos a decir al objeto Douglas que tiene edad este color de piel altura todo
vamos a agrupar esos valores de tal manera que la memoria me refiero a la memoria física o la memoria virtual creo que sería este en orden esto para que sea más óptimo
eso al final del día puede que estemos optimizando el programa y la aplicación que estemos realizando pero realmente va a ser un cambio o va significar algo en el uso real de nuestra aplicación se va a traducir eso a menores costos en nuestros servidores la gran mayoría de las veces es que no entonces no vale la pena yo aunque conozco estos conceptos me es más importante que el código sea más legible que realmente esté más optimizado para este tipo de casos
de nuevo va de casos a casos porque como decíamos al inicio tal vez si nos vamos mucho más low level, low level podríamos empezar a programar en ensamblador y para el 99 % de la industria de programación eso no es necesario pero si hay un porcentaje de la industria donde requerís hacer código de ensamblador
y realmente vale la pena para ese tipo de situaciones yo creo que el equilibrio ahí estaría Douglas en ir utilizando lo que nos funciona y siempre que se pueda ir indagando un poco aprender una cosita revisar otro otro cosa de por qué está así cómo lo hacían si estoy utilizando una función que ya tiene todo abstraído pues revisar qué es lo que hace por dentro no pierdo nada
Al menos esa ha sido mi forma de afrontar todo esto Douglas, es poquito a poco ir aprendiendo cómo funcionan ciertas cosas.
Douglas (54:12)
Sí, fíjate que me gusta eso que está diciendo del equilibrio o el balance y voy a agarrar esa parte para continuar la conversación y tal vez tratar de comenzar a descender para que busquemos aterrizar la conversación, ¿verdad? Y eso del equilibrio me parece tan importante que lo estás mencionando.
Y aquí hay varios dependes según el escenario y ya dijimos de que no es que saber lo de bajo nivel, saber esos fundamentos o esa historia necesariamente nos va a hacer mejor en el puesto en el hecho de que vamos a ganarle el puesto sobre alguien si estamos en entrevista o porque estamos ahí y son
cuatro programadores y el que tiene más conocimiento es el que más hace. Ya sabemos que en la práctica no necesariamente sí. Sin embargo, estamos como discutiendo, creyendo y medio concluyendo de que a nivel personal sí me vuelve mejor. A nivel personal. Vos dijiste todo conocimiento es bueno, por supuesto que todo conocimiento es bueno. También a nivel personal yo voy conociendo de dónde se origina.
Y también depende de cómo lo utilicemos. He estado en diferentes escenarios donde hay personas que dicen, oíme, yo creo que hay que usar GitFlow. Y te salen, GitFlow fue inventado hace tanto tiempo por la empresa tal y ellos dijeron que no y que sí. Y quedas viendo vos y, OK, este que me contó el origen de GitFlow y quién lo inventó, en qué año, qué estaba comiendo cuando lo inventó, la vez pasada no podía hacer un pipeline.
pues que bueno, tiene todo ese conocimiento pero no lo puede poner en práctica. También por otro lado, personas de las que sigo yo en tecnología que son de mucha influencia, trabajan desde hace muchos años en tecnología y tienen el mayor conocimiento de capas bajas que yo puedo ver, sin embargo, trabajan en lo nuevo.
trabajan en cosas nuevas, pero a ellos desde como hablan hay una diferencia en ellos y aunque alguien que no ha tenido la experiencia de ellos pudiera tener un trabajo similar a ellos sí lo vuelve mejor vos puedes ver a un Linux Torbo el creador de Git y el creador de Linux, ¿no? trabaja desde los ochentas en tecnología
O al principio de los 90 creo, o en los 90 creo Linux, pero trabaja, cuatro décadas o más de estar trabajando en tecnología, él trabaja de manera moderna, él trabaja con lo nuevo, pero en él cuando habla vos ves una diferencia.
Ocupo saber todo lo que él hace para yo trabajar como Sysadmin en Linux o para alguien trabajar desarrollando en el kernel de Linux. No, pero vos ves en él la diferencia. Hay otras personas que yo sigo, uno se llama Daring Pub y el otro Victor Farsi. Tienen un podcast de DevOps también que se llama DevOps Paradox. Para quienes hablen inglés, muy recomendado.
Uno de ellos trabaja desde los ochentas en tecnología, otro desde los noventas. Son de las personas con prácticas más modernas que conozco. Ya son unos señores, porque si yo estoy en cuatro décadas, nací en los ochentas, y ellos ya trabajaban para esa época, no están pocos mayores que yo todavía. Y son de los que manejan cosas las más modernas que visto. Pero ellos cuando hablan, esa experiencia que han tenido...
vos lo puedes ver puesto en práctica como realmente a ellos sí lo vuelven mejores. Y a un caso más reciente, si te fijas, voy trayendo casos desde el sol a la luna y voy bajando cada vez más a la tierra, a gente más cerca de uno. En un caso hace como ocho meses, un sitio de WordPress tenía unos problemas de performance.
Juan (57:56)
jajaja
Douglas (58:09)
Y entonces el developer que estaba asignado no lo encontraba. ¿Cuál era el problema? Entonces cuando lo escalan al jefe de él, era el como el staff engineer, él dice, ah ustedes están usando el plugin tal para para Object Cache. Ah, es que ese plugin lo que hace es que agarra los elementos y los divide entre tantas partes y los pone en memoria. Cuando vos tenés bastante eso hace que tarde más ir a buscar a Cache y empezó a explicar cómo funciona el plugin.
Él no creó el plugin, él no contribuía al plugin, pero fue alguien que se tomó el tiempo de ver el código fuente a saber cuándo, ¿no? A saber cuándo, para ver cómo funciona y entenderlo para él, ¿no?
Normalmente la mayoría de personas que hacen WordPress, este plugin es para caché, lo agarro, lo instalo y nos vamos, ¿no? Y listo, ya me está funcionando. Inmediatamente a él ahí lo volvió una mejor persona, un mejor profesional, pudo ser de ayuda. ¿Cada cuánto se necesita que se escale hasta el algo? No, no muy seguido. Pero sí podemos ver que a nosotros como profesionales, Juan.
Juan (59:02)
Y listo.
Douglas (59:18)
si no vuelve mejor internamente, aunque en la práctica en el puesto no me va a ser necesariamente ganarle a alguien el trabajo o no me va a ser necesariamente ponerlo en práctica todos los días, pero esa una ocasión cada tres años te va a permitir destacar o cada vez que estás arquitectando o diseñando algo lo vas a hacer un poquito más afinado que los demás porque conoces ese trasfondo. Ahora...
con lo que vos dijiste de balance, de equilibrio, que tanto conocimiento de bajo nivel necesito, que tanto tengo que prestarle atención, vengo comenzando en algo ahorita, que tanto tengo que prestarle atención, ya dijimos, no vamos a ir hasta abajo, hasta abajo, hasta abajo y terminar en ensamblador, entonces estábamos todos buscando aprender ensamblador, pero que tanto vengo comenzando en algo y voy a tratar de dedicarle el tiempo a ir a bajo nivel.
Es encontrar ese balance, no hay una respuesta directa. No hay una fórmula que diga esto es y ya está listo. Pero yo puedo sugerir algo aquí, Juan. Una de las cosas sería buscar leer la documentación de la tecnología que vas a aplicar. Léela toda porque normalmente ellos te explican los conceptos detrás de las diferentes decisiones e implementaciones.
Y esos conceptos normalmente son el bajo nivel suficiente para yo ser lo más efectivo posible. Así como el ejemplo de este ingeniero que te puse, que se tomó el tiempo de entender el código fuente del plugin.
Ese, él no se fue, todo esto está hecho en PHP, ¿no? Él no dijo, si esto se ve que es en C++ o el apuntador de memoria de este, no. Este cuando guarda en RAM, el apuntador que usa tal, no, él no hizo eso. El bajo nivel para él fue ir a leer el código y entender el código de cómo el plugin realmente funciona de manera interna. el consejo que puedo dar yo es, leamos la documentación.
Juan (1:01:15)
Mm-hmm.
Douglas (1:01:29)
porque normalmente, ya sea una tecnología, un lenguaje, un framework, una aplicación, un servicio que hay que configurar, normalmente esa documentación nos va a dar el trasfondo suficiente, los conceptos suficientes para aprender lo...
necesarios de bajo nivel para implementarlo y si hay una tecnología que la documentación sea pobre porque me he topado con servicios que son muy utilizados y vos te bajas la documentación y solo dice quick start y te da tres comandos para instalarlo el framework el plugin lo que sea y ya estuvo pero entonces tratemos de los conceptos conceptualmente que hace eso si no lo sabía irlo a buscar si es un plugin para o si es una aplicación para object cache por ejemplo object cache
leer un poquito que es AbjectCash o vas a implementar no sé, RabbitMQ para algo ya estás bien avanzado pero no has trabajado, lee que es RabbitMQ, qué hace y buscá entenderlo, ese es como el consejo que puedo dar de nuevo no hay una fórmula específica, de nuevo no vale la pena irse tan profundo pero sí vale la pena dedicarle un poquito y al final siempre el mayor tiempo dediqué
a lo nuevo, a mantenernos actualizados. No sé si en esto Juan qué piensas vos, si se te ocurre algo más que se puede hacer para intentar buscar lo de bajo nivel pero lo necesario, sin ir muy profundo porque no lo vamos a hacer todos los días, pero sin descuidarlo para llegar a ser mejores profesionales.
Juan (1:03:07)
sí, bueno, depende de... yo creo que depende de el tiempo con el que tengamos a nuestra disposición te doy un ejemplo muy muy rápido hace relativamente poco tuve que implementar en nuestro sistema pagos utilizando Stripe Stripe tiene una documentación muy muy grande muy grande
Me detuve a leer cada una de las cosas y cómo funciona y por qué está haciendo así, la verdad es que no. Me enfoque en que funcionara. Leí lo más que pude para tratar de aplicar las mejores prácticas, pero realmente no profundice tanto. ¿Por qué? Porque a veces en el trabajo tenemos el tiempo en nuestra contra. Esa es la verdad. También en mi vida personal,
por diferentes motivos en mi vida personal tengo menos tiempo libre así que tampoco puedo gozar del tiempo para también aprenderlo así que yo creo Douglas que aquí estas son las tácticas que yo he utilizado a través del tiempo para tratar de entender un poco más cada una de las soluciones y herramientas que yo utilizo que de nuevo nuevamente me gustaría como recalcar lo que hemos dicho
no es necesario, por ejemplo como lo que dije con Stripe yo no necesite entender todos los pequeños detalles que lleva enramados entre sí para poder utilizarlo pero si podemos profundizar es bueno entonces yo lo que he hecho es dependiendo de la cantidad de tiempo que tengo disponible Douglas si tengo mucho tiempo disponible yo intento implementar la solución que quiero utilizar por mi propia
cuenta. Por ejemplo, hay una librería muy buena que me encanta en Go para conectarme a Kafka, a RavidMQ y diferentes tipos de canales así que se llama Watermill. Bueno.
Esta es una abstracción muy alta de cómo utilizar estos servicios, pero yo también he intentado implementarlo por mi propia cuenta, utilizando las librerías más de bajo nivel que me da el lenguaje. También he intentado implementar servidores HTTP utilizando solo la librería estándar. Eso te da un entendimiento de por qué funcionan algunas cosas, por qué le pasamos algunos parámetros que a veces pues solo sabemos que se le pasa y ya.
Entonces eso es una muy buena práctica pero requiere que tengas tiempo disponible. Si tenés menos tiempo disponible, yo creo que vale la pena leer un poco de la documentación, bueno no solo la documentación sino la... código, la implementación de cómo está esto. Y aquí es donde a mí me encanta por eso el lenguaje Go. Porque en Go es muy fácil seguir el trazo de lo que estamos importando e ir a la...
a la implementación original y me permite a mi leer el código de cómo están haciendo algunas cosas, cómo implementan sus unit tests. Eso, como estás dentro del mismo ambiente de trabajo, te quita menos tiempo y puedes revisarlo rápidamente. Y bueno, ya si tenés muy poco tiempo libre, pues no está de más ver videos en internet, ver videos en YouTube sobre lo que estamos utilizando y estoy seguro que van a encontrar muchos videos que hablan sobre esto de manera simplificada.
o más resumida y nos pueden ayudar a entender algunas cositas que tal vez con la documentación pura no nos quedaba tan claro. Entonces yo creo que todo depende de cómo estamos en cierto momento en nuestra vida pero hay opciones para profundizar un poquito más y poder aportarle ese valor extra a nuestra carrera profesional.
Douglas (1:07:08)
Sí, me gusta, lo comparto muy de acuerdo, dependemos ya en la práctica real, dependemos del tiempo, yo creo que, y esto es un agregado mío, sé que así lo estás diciendo, así lo pensando, solo es un agregado mío, por más restricciones de tiempo que tengamos,
que es lo mínimo que yo voy a ver de la documentación de una tecnología que voy a implementar lo mínimo es que yo pueda entender el 100 % de lo que estoy entregando jamás vamos a presentar algo que no entendemos solo porque no hay tiempo entonces solo si para si alguien quiere como métricas a lo que acaba de decirnos Juan esa es su métrica que tampoco puedo ir que entendas el 100 % de lo que estás entregando si no es entendido el 100 %
Entonces pedí más tiempo, pedí ayuda, pero no entregues algo que no entendas el 100%. Y como un tip extra, porque estoy muy de acuerdo, si el tiempo no te deja profundizar, la siguiente vez que te asignen una tarea de lo mismo para que le agregas un nuevo feature o lo que sea, trataré cuando lo estimes, a regarle tiempito para dedicarle otra media hora, una hora a la documentación y aprovecharlo de esa manera.
Pero en fin, yo creo Juan que esta plática tiene bastante tela que cortar. Sin embargo, siento que hemos llegado a un buen punto de nuevo. Aquí no es una plática interesante porque no es como querer llegar a una conclusión absoluta. Sin embargo, es tocar el tema, es sacar la conversación para que podamos darle valor a los fundamentos, a la capa de bajo nivel, a la historia de las tecnologías que estamos usando.
con la intención de que nos vuelvan mejores, con la intención de que nos vuelvan mejores, ¿verdad? La intención es que esta plática que hemos tenido despierte en cada uno de ustedes que nos ven y nos escuchan la curiosidad que consideren, hey, ¿realmente estoy entendiendo cómo funciona esta tecnología? ¿Realmente estoy entendiendo qué es lo que hace Trash Bambalinas, Next.js, React, el framework que estoy utilizando, la tecnología que estoy utilizando, ¿realmente estoy entendiendo eso?
A pesar de que no lo he entendido al todo, que tanto me ha impedido hacer mi trabajo, que lo analicen, y puede que la respuesta sea, no me han pedido nada, pero que tanto me aportaría dedicarle un tiempito a entenderlo más. Lo que queremos con esto es que despierten ustedes la curiosidad, esperamos que haya sido el valor que le hayamos aportado con esta conversación tan tan interesante. Juan, no sé con qué te gustaría despedirte.
Juan (1:09:50)
Me gustaría simplemente cerrar con algo que es una opinión muy personal. Si bien es cierto, hoy en día podemos encontrar trabajo con los conocimientos más abstractos y lo más entre comillas fácil. Yo creo que llega un punto donde vamos a necesitar destacarnos. A medida necesitemos crecer como profesionales o optar por empleos mejores. Vamos a decirlo así.
hay muchas otras personas que van a estar compitiendo igual que con nosotros y si vos no le das la importancia para entender cosas que son más profundas van a ver otros que sí lo van a hacer y que no sea eso el motivo por el que perdemos una oportunidad así que de nuevo en lo que estamos enfocándonos en nuestra área denle una leída aprendan fundamentos más
más bajos para poder optar a diferentes oportunidades. No tienen que aprender cómo funciona a nivel binario y a nivel físico, ¿no? Pero lo suficiente como para tener un diferenciador como profesionales.
Douglas (1:11:11)
gusta, me gusta muchísimo y yo creo que pues este es un buen momento para que podamos concluir la conversación. Te agradezco primero a vos Juan por haber tomado el tiempo y tenido esta conversación conmigo. He aprendido mucho tu perspectiva. Agradecerle a las personas que nos ven y nos escuchan por haber llegado hasta esta parte. Nuestro deseo siempre es proveerles valor. Nos despedimos y nos vemos en el próximo episodio.
Juan (1:11:36)
Hasta la próxima.