grenade 2026-03-24 | comentario padre | en: Por qué amo NixOS (birkey.co)

Es demasiado difícil, lo intenté un poco y luego me rendí T_T
(I use Arch btw)

 

Hay muchísimos encuestados de nuestro país, más de lo que esperaba.

 

Lo estoy probando... no estoy muy seguro.
Puede que el problema sea que mi prompt está raro, pero la tipografía y el diseño están medio malos..

 

La verdad, si un LLM me recomienda cierto software de código abierto, pienso que tal vez lo probaría,
pero si me recomienda un producto para comprar, siento que más bien me haría desconfiar y lo evitaría aún más.
Bueno, quizá algún día eso también cambie.

 
ztaka 2026-03-24 | comentario padre | en: Por qué amo NixOS (birkey.co)

Quien sabe, lo usa de boca en boca jajaja
Una configuración reproducible implementada con un lenguaje funcional declarativo

 

Por favor, denle mucho amor a RollerCoaster Tycoon.

 
ytuniverse 2026-03-24 | comentario padre | en: Por qué amo NixOS (birkey.co)

La curva de aprendizaje es ridículamente empinada. Te exige un nivel alto, tanto como garantiza la reproducibilidad.
Incluso usando flake, sigue siendo complicado.

Además, parece que internamente usa SQLite, y el rendimiento también es inconsistente, así que hay cierta fluctuación en el tiempo que tarda volver a reproducir un entorno.

 

Se supone que funciona, pero a mí no me funciona :(

 
fantajeon 2026-03-24 | comentario padre | en: Tres tipos de malos managers (randsinrepose.com)

¿Qué hace a un buen líder, gerente o miembro de equipo? A veces, una persona que es gerente al mismo tiempo es miembro del equipo para alguien más, así que...

 

Gracias por normalizarlo con Electron...

 

Cada día salen montones de proyectos; si al menos hubiera capturas de pantalla, creo que me tentaría y lo probaría de inmediato.

 
seraphmate 2026-03-24 | comentario padre | en: Tres tipos de malos managers (randsinrepose.com)

Parece que, donde sea, la forma en que vive la gente es igual en todas partes. :)

 

No funciona en Linux 😭

 

Claro~ con solo un texto pensado para generar este tipo de debate, la intención ya quedaba bastante clara.

 

¿IDE y PR ya murieron todos, pero el código resucitó?

 

Sí, en este momento están chocando dos perspectivas. La que más se comenta es la teoría del reemplazo, y de vez en cuando aparece la postura optimista, como en este texto.
Nadie puede saber con certeza cómo será el futuro, pero si la postura dominante es la del reemplazo, creo que también vale la pena revisar la visión contraria.

Entre los muchos argumentos del optimismo, traje uno de los marcos teóricos antiguos: la paradoja de Jevons.
En el mercado actual, con la transformación de desarrolladores individuales en empresas unipersonales, los precios están bajando rápidamente, desde simples páginas web de presentación en adelante. Debido a esto, pequeños comercios o pymes que antes ni pensaban en tener un sitio web ahora también están terminando con páginas bastante decentes.
Es decir, concluí que la tendencia correcta es que el mercado en sí se está expandiendo. En especial, están apareciendo SaaS a un ritmo impresionante y, sin que muchos lo noten, la competencia de precios también se está intensificando. Si los precios bajan, aumentarán las empresas y personas que los adopten, y el mercado en sí claramente va a crecer.

Después, la dirección probablemente será una de dos: o una sola persona seguirá aumentando la cantidad de servicios que administra, o aparecerá otro desarrollador para absorber esa demanda.
Como claramente hay un límite en la cantidad que una persona puede procesar y gestionar, pensé que al final podría formarse otra vez una tendencia a contratar desarrolladores junior —porque el recurso que había quedado relegado en el mercado eran precisamente los juniors— para poder cubrir esa demanda.

Claro, las capacidades que se le exigirán al desarrollador junior de ese momento serán muy distintas a las de ahora. Y tampoco sé si el tema salarial será igual que antes. Además, sinceramente no tengo claro en qué momento podría llegar ese escenario...

Y gracias por leer el texto y también por hacer un análisis tan detallado. Da gusto porque se aprende.

 

Para incluir la perspectiva de la paradoja de Jevons, primero hay que definir cuál es el recurso.
Como este es un texto que analiza las perspectivas de la demanda de desarrolladores, en este texto el recurso debería ser el desarrollador.

  • Las industrias que la paradoja de Jevons ha explicado tradicionalmente (máquina de vapor <-> carbón) y la industria del software tienen muchas diferencias.
    • Los bienes digitales son bienes no rivales, y es una industria con costo marginal casi cero. Es decir, es una industria centrada en costos fijos.
    • En una industria así, las mejoras de productividad por lo general avanzan en la dirección de reducir o congelar personal, o de aumentar el apalancamiento del personal existente.
  • Para que se cumpla la paradoja de Jevons, la demanda debe ser muy sensible al precio, y la reducción de costos debe llevar directamente a una explosión de la demanda.
    • El desarrollo de software no lo hace una sola persona desarrolladora. El cuello de botella no es el "costo de programar", sino los costos de planificación, riesgo, operación, organización y regulación.
    • Hasta ahora, en la mayoría de los casos, no es que no se haya hecho software porque fuera caro, sino porque “no era necesario / no daba ROI / no se podía operar”.
  • Hay una ilusión en los indicadores de productividad.
    • Los indicadores usados en el texto (aumento en la generación de código, aumento de PR, aumento en los despliegues) son todos indicadores de “volumen de actividad”.
    • Que aumente la cantidad de código no significa que aumente el valor. El aumento de PR lleva a un aumento en los costos de revisión/validación, y el código generado por IA incrementa los riesgos de calidad/seguridad.
    • Es decir, el código generado por IA aumenta la deuda técnica, los costos de depuración y la complejidad operativa.
    • Por lo tanto, la mejora de productividad podría no aumentar de manera tan dramática como los indicadores de volumen de actividad.
  • Reconocer el "abismo junior" y al mismo tiempo mantener el optimismo es contradictorio.
    • A diferencia del carbón, los desarrolladores se forman creciendo de junior a senior.
    • Si disminuyen los juniors, también disminuirán los seniors del futuro. Por lo tanto, a mediano y largo plazo, el pool total de desarrolladores se reducirá.
  • El crecimiento del tamaño del mercado y el crecimiento del empleo no son lo mismo.
    • En particular, la IA es una industria intensiva en capital: no es una "industria que usa más personas", sino una "industria que crea una escala mayor con menos personal".
  • Los desarrolladores son personas, y los salarios de las personas tienen características distintas al precio del carbón.
    • En el mercado laboral, los salarios no caen de forma completamente flexible, por lo que la reducción de costos no se transfiere lo suficiente a una caída de precios.
    • De hecho, los salarios tienen rigidez a la baja. Esto se debe al salario mínimo, las leyes laborales, la estructura contractual, la equidad interna en la organización, la moral y el riesgo de rotación, entre otros factores.
    • Es decir, cuando aumenta la productividad, las empresas no bajan los salarios, sino que reducen la contratación.
 

"El problema es que te hace confundir una vaga intuición (vibe) con si fuera una abstracción precisa". Me identifico mucho con eso. La abstracción, justamente, solo es posible para quienes entendieron el bajo nivel desde una perspectiva bottom-up.

 

Es incómodo cuando algo que antes funcionaba deja de hacerlo, pero con solo quitar todo ese espagueti y esos apaños que se hicieron en X11 para que funcionara, ya hay razones suficientes para valorarlo.
Sin embargo, si uno busca por qué todavía hay cosas que no funcionan, al final el problema es que no se ha estandarizado, y también es cierto que ese proceso está tomando más tiempo de lo esperado.
Probablemente incluso cuando llegue 2030 se seguirá diciendo que todavía falta mucho para que esté terminado, pero volver a X11 será imposible.
Incluso si hay confusión por el cambio de ecosistema, cualquier alternativa va a escuchar exactamente las mismas críticas, y regresar probablemente provocaría rechazo dentro de un ecosistema al que la gente ya se acostumbró.