Archivo de la etiqueta: github

¿Cómo le hacen los que no pueden usar Git en su trabajo?

Un usuario de Reddit escribe:

Esta mañana, gasté 3 horas reescribiendo lo que hice ayer, porque mi compañero lo eliminó accidentalmente en la carpeta de Windows Server que usamos para desarrollar. No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git. ¿Alguno de ustedes ha trabajado en algún lugar así y encontrado una manera de sobrellevarlo?

Obviamente, las respuestas recomendándole que huyera de ahí lo más rápido posible no se hicieron esperar.

Hace casi 22 años, Joel Spolsky publicó en su blog su popular checklist para determinar si un equipo de desarrollo de software es bueno o no: 12 Pasos Hacia Mejor Código. La primera pregunta es: ¿Tu equipo usa manejador de versiones?

Aunque es fácil caer en la tentación de burlarse del creador del hilo en Reddit, me gustaría reflexionar sobre su situación.

Recordando que muchas personas crecimos con la idealización del trabajo duro, no es difícil ver cómo esa forma de pensar podría llevarnos a la progresión lógica de que cualquier cosa que le haga al programador la vida más fácil significaría que entonces la empresa no lo está aprovechando al máximo. Estoy seguro de que podrás identificar alguna persona en tu vida (probablemente alguien mayor, o “de la vieja guardia”) que defendería esta retórica. “Los programadores de verdad compilan su propio IDE.” Esto es lo que pasa cuando personas con esta mentalidad dirigen empresas.

(Dándoles el beneficio de la duda: es probable que esta persona esté trabajando en una industria donde únicamente se pueden utilizar tecnologías aprobadas y validadas por algún tipo de organismo o estándar. En este caso, entendería que, por regulación, no estuviera permitido que usaran tecnologías de código abierto.)

Por otro lado, es probable que el autor original del hilo simplemente se encuentre rodeado de gente que ignora la existencia de los controladores de versiones, así como sus beneficios. Un par de veces en mi vida me he encontrado con personas que encuentran abrumadora la idea de tener que aprender otra tecnología (Git) además del lenguaje de programación en el que están especializándose. Así que simplemente hacen lo que pueden con lo que saben: ponen su código en Dropbox, Google Drive, y listo. No es hasta que salen problemas que el valor de usar controladores de versiones se vuelve aparente.

La parte clave de su mensaje es esta:

No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git.

Apostaría que la persona que escribió esto encaja en el siguiente perfil: alguien joven, al inicio de su carrera en software, con grandes aspiraciones, en su primer trabajo formal. Probablemente, la empresa sea de una industria vieja (finanzas, construcción, legales, donde las cosas se hacen por regulación) que se está intentando renovar, y lo están haciendo contratando programadores, pero sin crear una cultura de desarrollo de software.

No conozco al autor del hilo, pero no me sorprendería si tuviera una carrera próspera en su futuro. Después de todo, está demostrando una capacidad que (desafortunadamente) no todos tienen: la de cuestionar el statu quo. No se está quejando, está haciendo una pregunta para educarse y crecer. Está buscando datos, consejos y soluciones.

Algunas lecciones que me gustaría que todos nos lleváramos de esta experiencia:

  1. No en todas las empresas se puede desarrollar software. Ve esta porción de una de mis charlas para entender más sobre esto.
  2. Algunas empresas solamente quieren programadores, no desarrolladores.
  3. Desarrollar software es mucho más que escribir código.
  4. Se vale preguntar, cuestionar y decidir si la situación en la que estás es en la que quieres estar.

El Open Source no se trata de ti

Rich Hickey, creador de Clojure, escribiendo en GitHub Gist:

Ser usuario de algo que es Open Source, no te hace merecedor de nada en absoluto. No necesitas contribuir. No tienes por qué exigir nuevas características. No te mereces la atención de otros. No significa que tus quejas tengan un valor para el producto. No te mereces esta explicación.

Si tienes expectativas (de otros) que no están siendo cumplidas, esas expectativas son tu propia responsabilidad. Eres responsable de tus necesidades. Si quieres algo, hazlo.

Hace un tiempo escribía sobre como ser desarrollador Open Source parecía no ser tan buena idea hoy en día. El Gist que publica Rich no es nuevo, tiene por lo menos unos 5 o 6 años, pero demuestra la tendencia hacia el burn-out que muchos administradores de proyectos Open Source hoy están reportando.

GitHub Copilot ahora disponible de manera general

Hace un par de días, GitHub anunció que Copilot está ahora disponible de manera general.

Cualquier persona, hoy puede pagar $10 USD mensualmente por un compañero de pair programming creado con inteligencia artificial.

Buen momento para recordar lo que escribí hace casi exactamente un año:

Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar.

Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc.

Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales.

Software Libre: ¿Vale la pena involucrarse?

El mundo del desarrollo de software libre ha estado en las noticias últimamente. Desde la vulnerabilidad de Log4j que mandó a todo mundo a actualizar sus servidores, hasta las controversias por grandes compañías construyendo servicios y productos encima de productos de código libre sin honrar la naturaleza del mismo.

Con iniciativas como GitHub Sponsors, las compañías que dependen del software libre buscan incentivar que las personas que mantienen los proyectos sigan trabajando en ellos. Sin embargo, el panorama no se ve tan alentador para aquellos que tienen que lidiar con las implicaciones de mantener proyectos que son usados por millones de personas.

Gavin Howard, escribiendo en su blog:

Esto es deprimente, por decir lo menos. Es deprimente porque no veo otra alternativa más qu dejar de escribir software. Después de todo, no puedo encontrar trabajo, no puedo hacer dinero trabajando en software libre, y el código que escriba puede terminar dañando a más personas de las que ayuda.

Mi interpretación del problema es que el propósito del software open source se ha pervertido a lo largo de los años. Inicialmente, la idea era poder colaborar para crear mejores soluciones. Durante un tiempo, cuando se construían las bases de la industria de la tecnología, eso era una realidad. Hoy en día, el que una solución sea de código abierto se utiliza como excusa para no dedicar tiempo a entender sus fundamentos.

¿Cuándo fue la última vez que realmente te dedicaste a entender la solución que un paquete de NPM implementaba? No importa, porque es de código abierto, y seguramente alguien más encontrará lo que está mal en ella — si es que hay algo mal, en primer lugar.

La comunidad de código abierto aporta muchísimo beneficio a la industria. ¿Cómo se logrará hacer que reconozca estos beneficios y corresponda de igual manera a la comunidad que habilitó su creación en primera instancia?

Aquí una idea de cómo puedes comenzar a influenciar un cambio positivo: si el producto en el que trabajas depende de una pieza en particular de código open source, pídele a los líderes de tu organización que asignen una parte del presupuesto para contribuir económicamente al mantenimiento de ese proyecto. Si la persona encargada no tiene habilitado un perfil de GitHub Sponsor, estoy seguro de que estará más que contenta de recibir un wire transfer mensualmente con la contribución de tu empresa.

Sentry dona $150 mil dólares a proyectos de código abierto

Es refrescante ver una compañía fundada gracias al código abierto que, literalmente, pone su dinero donde pone su boca.

En total, han donado $154,999.89 a proyectos e iniciativas de código abierto. Me encanta también el mensaje con el que lo hacen: “queremos sostener a la comunidad de manera sostenible.”

Tip: trabajar de tiempo completo en proyectos de código abierto es posible. Entre otras, puedes usar la plataforma de GitHub Sponsors para que otras personas u organizaciones patrocinen directamente tus contribuciones open-source.

Enlace: https://blog.sentry.io/2021/10/21/we-just-gave-154-999-dollars-and-89-cents-to-open-source-maintainers

GitHub Copilot: si solamente sabes programar, tu carrera tiene fecha de caducidad

Hay personas en esta industria que reducen su trabajo a algo meramente mecánico: escribir código.

Lo que uno como desarrollador de software está buscando constantemente es la automatización de tareas mecánicas y manuales. La ironía es que, en sí, programar también es una tarea mecánica y manual. Y como tal, eventualmente también será automatizada.

Hace unos días GitHub presentó Copilot — un servicio que prácticamente programa por ti. Lo único que tienes que hacer es describir a grandes rasgos qué es lo que quieres hacer. Copilot genera el código que tú habrías escrito.

Naturalmente los memes no se hicieron esperar. Tampoco las discusiones sobre si el código que está generando esta herramienta cumple con licencias de distribución adecuadas. Pero muy pocas personas se pusieron a ver lo que acababa de pasar: los soft skills en desarrolladores de software acaba de volverse mucho más valiosos.

La tendencia es clara. La verdadera ventaja competitiva para un desarrollador de software no será la parte técnica, sino las habilidades interpersonales.

Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar.

Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc.

Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales.

Mejorando la visibilidad de información en equipos remotos

Estás teniendo una acalorada discusión con tus compañeros de trabajo acerca de cómo resolver ese problema con el que llevan atorados un par de semanas. Todos están trabajando de manera remota, y están teniendo la discusión en el canal de chat de la empresa. Han intentado varias propuestas de diferentes miembros del equipo, pero ninguna parece terminar de lleno con el problema.

De repente a una de tus compañeras le llega a la cabeza la solución ideal que sí va a funcionar. Rápidamente la redacta y la publica en el mismo hilo de conversación que han estado usando para coordinar los esfuerzos de resolución de la situación. “Si quieren lo platicamos en una llamada”, escribes. Presionas Enter en tu teclado, y unos minutos después todo el equipo está platicando cara a cara en un Google Meet repasando el plan de acción.

Todos aceptan, entienden su rol, y comienzan a trabajar. Por fin encontraron la solución que les permitirá continuar con la siguiente fase de su proyecto, y la implementarán en tiempo récord.

Todo parece estar tranquilo. Un éxito seguro, un problema menos, y todo gracias a la excelente colaboración de los miembros del equipo.

Hasta que tiempo después alguien hace la pregunta: ¿Me pueden explicar por qué se resolvió esto así? Pero hace 6 meses que la persona que propuso la solución se fue de la organización.

La problemática

El escenario que describo anteriormente sucede más de lo que te imaginas, y no es exclusivo de organizaciones o empresas grandes. Seguramente alguna vez te has preguntado por cómo llegaste a cierta decisión en tu vida personal, o en tu proyecto individual. No es raro.

El cerebro humano está diseñado para generar ideas (y es excelente en ello), no para almacenarlas. El dicho reza que dos cabezas piensan mejor que una, no que dos cabezas recuerdan mejor que una. Reconociendo esto, podemos tomar acciones concretas para no complicarnos la vida a nosotros mismos al momento de que necesitemos recordar cómo fue que llegamos a una decisión.

Una técnica para esto es pensar en las ideas y acuerdos en términos de Flujo y Stock.

Flujo y Stock

Seguramente habrás escuchado en alguna ocasión que cierto producto se encontraba fuera de stock al momento de intentar comprar algo en una tienda. “Nos llega pedido en 15 días,” como es de costumbre.

En el mundo de la economía, los negocios, y la logística existe el término Flujo y Stock, que nos permite pensar de diferentes maneras en las unidades más importantes para un determinado contexto. Al enmarcar la unidad con la que estamos lidiando en el concepto de Flujo y Stock, se vuelve mucho más sencillo determinar cómo deberíamos de manejar dicha unidad.

Una manera más amigable para asimilar el concepto de Flujo y Stock es pensar en que tenemos una tienda de libros. Piensa en cuáles libros pondrías en las vitrinas para atraer clientes. Estarás de acuerdo que la respuesta es que en las vitrinas deberían ir los libros actuales, novedosos o que están en auge, pues son ellos los que atraerán a la tienda a los clientes potenciales que van pasando.

Y entonces, ¿cuáles libros deberías guardar en tu almacén? Los libros clásicos, de conocimiento antiguo; no son tan populares, pero debes tenerlos a la mano de una manera relativamente accesible porque eventualmente va a llegar un cliente a preguntarte por uno de ellos. Es ahí cuando dices “permíteme tantito, déjame ir por él a la bodega”.

De manera concreta:

  • Flujo hace referencia a una transacción que se haga con una unidad de medida durante un periodo de tiempo. Cuántos libros vendes por hora. Estos libros van en la vitrina.
  • Stock hace referencia a una unidad de medida en un marco de tiempo en particular. Cuántos libros tienes disponibles para venderhoy. En tu stock tienes los libros clásicos.

Flujo y Stock del conocimiento

Podemos categorizar cómo administramos nuestros bienes físicos, y determinar si los debemos de guardar en un almacén, o tenerlos en las vitrinas de una tienda. De la misma manera, podemos categorizar el conocimiento y la información que manejamos en el día a día. El concepto de Flujo y Stock, al ser asimilado y transportado al reino del conocimiento, nos permite discernir con mayor claridad cómo deberíamos administrar una idea.

Podremos decidir si un pedazo de información es de flujo (novedosa, popular, y que debería ir en la vitrina), o de stock (de valor histórico, clásica, y que debería ir en el almacén).

La información que determinemos flujo va en las vitrinas de la era digital: aplicaciones de chat, videollamadas, correos electrónicos, o cualquier otro medio de comunicación cuya naturaleza sea efímera. Estos medios de comunicación están hechos para ser consumidos “al pasar”, al igual que un exhibido afuera de una tienda.

Entre las características de los medios de comunicación ideales para transmitir información de flujo se encuentran:

  • se centran en la facilidad de transmitir, no preservar, la información (chats privados, videollamadas por Zoom o Google Meet),
  • usualmente ofrecen una experiencia personalizada para cada usuario (Facebook, Twitter, Instagram, WhatsApp), y
  • generan silos de información dentro de una organización (correo electrónico).

Por el contrario, la información que determinemos stock debería de ir en nuestros repositorios digitales de información: documentos en la nube, notas compartidas, o almacenes de código a los que todos los miembros del equipo tengan acceso. Si contrataras un nuevo vendedor en tu librería, él o ella necesitaría acceso a tu bodega de libros para poder hacer su trabajo. Sucede exactamente igual con el conocimiento.

Entre las características que hacen que un medio sea apto para almacenar información de stock se encuentran:

  • la habilidad de que todos los miembros de la organización estén viendo el mismo contenido al mismo tiempo (carpetas compartidas, como Google Drive o Dropbox),
  • la posibilidad de colaborar simultáneamente en la edición del contenido (Google Docs, Office365, Dropbox Paper)
  • la preservación de un historial de modificaciones, con marca de tiempo y detalle del cambio (Google Docs hace esto también)
  • el contenido es indexable y se pueden realizar búsquedas complejas

También es de vital importancia asegurarse que la información stock debe de contener todo el contexto necesario para ser útil. Para esto, te recomiendo que sigas el PURLÚ (Principio de la URL Única). De nada sirve tener información guardada, si es dificil interpretarla.

¿Cómo saber si una pieza de información es Flujo o stock?

Una definición muy personal para la información que considero como flujo en mi día a día es preguntarme si la idea podría caber en un Tweet. Si la respuesta es sí, entonces comunico la idea a través de un canal apto para información fluctuante.

Ejemplos de información que considero flujo:

  • Notificar al equipo que un proyecto se completó de manera exitosa.
  • Confirmar un dato con alguno de mis compañeros.
  • Pedir o dar una actualización de estatus de una iniciativa.
  • Pedir por referencias sobre algún trabajo previo.
  • Información relacionada con ocio.

Por otra parte, cualquier pieza de información que tenga un valor histórico dentro del contexto en el cual está siendo manejada, debería de ser considerada información de stock.

Notificar que un proyecto se completó de manera exitosa es claramente información de flujo, y podríamos hacer dicho anuncio a través de Slack, Google Chat, o en un correo electrónico sin problema. Sin embargo, el historial y resumen de entrega del proyecto completado es información de stock, y por lo tanto deberíamos de preservarlo en un folder compartido de Google Drive o Dropbox, al cual tienen acceso los miembros del equipo a quienes podría servirles dicha información.

Puedes aplicar esta misma forma lógica en tu día a día para determinar si algo debería ser comunicado como información de flujo, o información de stock. Además, puedes ir un paso más allá y pensar también en organizar los canales de comunicación de tu equipo, algo de lo que también escribí.

Conclusión

Estudiar otras áreas de la vida nos expone a ideas que podemos moldear para resolver problemas que ni siquiera estábamos conscientes que teníamos. En esta ocasión, hemos explorado un concepto de economía, nos hemos quedado con su esencia, y lo adaptamos a un área de interés muy particular: la administración de la información y conocimiento.

Ser eficiente, en esencia, se trata de remover fricciones. Al remover la fricción de recuperar conocimiento e información, estamos elevando nuestras probabilidades de tener éxito en lo que sea que estemos haciendo. Aplicando el concepto de Flujo y Stock en nuestro trabajo y vida personal, dejaremos de tener la incertidumbre naciente de la falta de organización del conocimiento.