Confesiones de un desarrollador de software: ya no más autocensura

• Un desarrollador que durante meses dejó de escribir y de participar en línea por miedo cuenta cómo decidió dejar la autocensura y confesar carencias técnicas y personales que no había podido reconocer hasta ahora
• Reconoce que no entendió el concepto de polimorfismo (polymorphism) durante más de 10 años, que perdió soltura con SQL y que ha desplegado la mayor parte de su código sin pruebas automatizadas
• Al intentar adaptarse a cambios en el stack tecnológico de su empresa, abandonó el aprendizaje de C# y Blazor; también habla de cómo sigue amando Ruby pero no puede usarlo profesionalmente, y de la carga psicológica que siente al saber que sus gerentes y colegas leen su blog
• Relata su experiencia de acoso cibernético tras enviar un PR escrito con ayuda de IA, además de sus sentimientos sinceros sobre el trabajo remoto y su opinión sobre la falta de necesidad de procesos de desarrollo personalizados dentro de una organización
• Cierra con la decisión de soltar el miedo y continuar con el aprendizaje constante y la escritura pública sin seguir autocensurándose

---

Inicio: por qué decidió dejar el miedo y la autocensura

• Desde abril hubo un periodo en el que el miedo era tan grande que no podía publicar nada, y terminó alejándose por completo de redes sociales, agregadores de noticias y foros
  • Sintió que no podía seguir así y decidió volver a escribir, superando ese miedo
• Había pasado mucho tiempo ocultando sus vacíos por no querer exponer sus debilidades básicas, pero terminó viendo que muchos desarrolladores trabajan con lagunas de conocimiento similares
  • Su forma de aprender hasta ahora se parecía a un moho mucilaginoso que solo crece en las áreas que usa, mientras que el conocimiento que no utiliza simplemente se seca
• Hace poco comenzó a reconstruir esos fundamentos y, al reorganizar en texto y en palabras lo aprendido, empezó a desarrollar la capacidad de admitir con ligereza que “no sabe”
• Al sentir por sí mismo que los fundamentos pueden reaprenderse, empezó a convencerse de que nunca es demasiado tarde

El tiempo en que no entendió el polimorfismo durante más de 10 años

• Desde 2012 pensaba que escribía código orientado a objetos, pero terminó admitiendo que hasta hace apenas un año no entendía realmente el polimorfismo
  • Enfrentó la realidad de que el código que había escrito hasta entonces se parecía más a programación estructurada que a orientación a objetos
  • Nunca había pensado en reemplazar condicionales con clases para cambiar el diseño
• Leyendo textos de Sandi Metz y materiales de Martin Fowler, entendió por fin el concepto y quedó claro cuánto se había perdido en el camino

• Por qué le costaba exponer esto

  • Le resultaba muy duro revelar que justamente él, que en entrevistas laborales había evaluado conceptos de orientación a objetos, en realidad no entendía el polimorfismo
  • También implicaba dejar en evidencia que al inicio de su carrera se inclinó más por aprender herramientas que principios, y que, al no venir de una formación en CS, había dejado pasar demasiados fundamentos

La experiencia de olvidar SQL

• Hubo una época en la que resolvía ejercicios de libros de SQL y escribía con soltura JOINs y subconsultas
• Pero, a medida que su trabajo se centró por completo en frontend y dejó de usar SQL, se dio cuenta de que una habilidad entera había desaparecido de su cabeza
  • Aún recuerda consultas básicas, pero para explicar la diferencia entre left join y outer join tendría que volver a abrir la documentación

• Por qué le costaba admitirlo

  • Cuando era joven creía que, incluso después de varios años, los hechos y habilidades podían revivirse con solo una pequeña pista
  • Ahora siente en carne propia que esa capacidad ya no se conserva igual, y le impactó descubrir que SQL fue la primera habilidad que se le borró por completo de la memoria
  • No le resultaba fácil escribir públicamente sobre envejecer y sobre cómo cambia el funcionamiento de la memoria

La realidad de haber desarrollado sin pruebas automatizadas

• Admite que más del 95% del código que ha puesto en producción funciona sin pruebas automatizadas
  • Al principio de su carrera ni siquiera conocía bien el concepto de testing, y en su etapa con Ember era difícil aprovechar correctamente las herramientas de pruebas
• Últimamente ha trabajado mucho con código legado, así que no ha podido dedicar suficiente tiempo a preparar el código para que sea testeable
  • Solo ha logrado incluir pruebas en subsistemas nuevos

• Por qué le costaba revelar esto

  • Sentía que esta confesión era la más devastadora para su carrera
  • Desde la perspectiva de Uncle Bob, ejecutar código en producción sin pruebas podría verse como una postura poco ética, y le daba miedo enfrentarse a la distancia entre ese estándar y su realidad
  • Le parecía muy probable que, si esto se hacía público, afectara negativamente evaluaciones en procesos de contratación, así que fue posponiendo incluso el registro de su propio proceso de aprendizaje

Por qué no logró aprender Blazor

• Cuando su empresa decidió pasar de Angular a Blazor, él era la única persona del equipo sin experiencia en C#, así que empezó a estudiar apresuradamente para ponerse al día
• Unos meses después se canceló la migración y perdió por completo la motivación, al punto de no terminar ni el libro que estaba leyendo
• En realidad, C# y .NET nunca fueron lenguajes que quisiera usar en proyectos personales; desde el principio estuvo claro que los estudiaba solo por trabajo

• Por qué le costaba escribir sobre esto

  • En una publicación anterior había prometido escribir una continuación, y cada vez le incomodaba más escribir otros textos sin haber cumplido esa promesa
  • Como su texto sobre Blazor había tenido muchas visitas, temía que admitir el cambio de rumbo se viera como una derrota

Las ganas de usar más Ruby

• Ruby sigue siendo el lenguaje con el que se siente más cómodo y el que más disfruta; es el que naturalmente elige para ejemplos, open source, katas y hackatones
• Sin embargo, desde 2013 no ha vuelto a recibir un salario por escribir Ruby, y en el trabajo usa lenguajes como TypeScript
• Como aprecia mucho a los colegas con los que ha trabajado en distintas empresas, ha seguido tomando decisiones en las que elige a las personas y cede en el lenguaje
• Le gustaría dedicar sus noches y fines de semana a Ruby, pero entre otras obligaciones y metas de aprendizaje, casi no le queda tiempo suficiente para usarlo

• Por qué le costaba decirlo

  • Como su gerente y el CTO leen este blog, temía que decir que quiere usar más Ruby se interpretara como una señal de que quiere renunciar
  • Tampoco quería parecer alguien que intenta imponer en la empresa un lenguaje que no es familiar allí

El acoso cibernético también duele en la adultez

• Cuando envió un pequeño parche generado con LLM a un proyecto open source y compartió esa experiencia en un foro en línea,
  se encontró con una avalancha de ataques personales como “incompetente”, “repugnante” y “amenazante”
• El acoso no se quedó en ese sitio, sino que se extendió a otras páginas web, correo electrónico, SMS y llamadas telefónicas, haciéndole sentir directamente que no estaba seguro
• Pidió a los administradores del foro que borraran su nombre real, pero en lugar de eso añadieron todavía más PII a su perfil,
  e incluso quedó fijada de forma permanente una afirmación falsa diciendo que había inventado la historia de los contactos externos
• Al final no tuvo otra opción que desactivar la cuenta y abandonar el sitio

• Por qué le costaba escribir sobre esto

  • El acoso que duró varios días fue la experiencia en línea más tóxica que ha vivido, y hasta ahora sigue sintiendo sus efectos
  • Le sigue dando miedo que, si cuenta esta historia públicamente, sus agresores vuelvan a buscarlo
  • Pensar además en la posibilidad de que la información falsa de su perfil perjudique sus oportunidades laborales hizo todavía más difícil hablar del tema

La idea de que un equipo SaaS no necesita un “proceso especial”

• En la industria del software ya existen procesos refinados durante décadas,
  y enfoques como Agile, Lean, Kanban y XP ya ofrecen estructuras comprobadas
• Poco a poco se le hizo natural pensar que, con capacidades limitadas dentro de una empresa, es mejor concentrarse en desarrollar producto que en inventar procesos nuevos

• Por qué le costaba expresar esta idea

  • Al escribir, siempre procura hacerlo a partir de temas que conoce bien, y en este caso el detonante había sido un proceso de desarrollo de software personalizado propuesto por un colega de la misma empresa
    • Sintió que existía el riesgo de que el texto pareciera una crítica pública dirigida a una persona concreta o a su idea
  • Envidia la capacidad de autores como Kent Beck y Martin Fowler para explicar mejores formas de colaboración sin apuntar directamente contra colegas que se equivocaron
    • Como siente que todavía no tiene ese equilibrio, dudó en escribir sobre ello

Cómo el trabajo remoto obstaculiza la colaboración real

• El trabajo remoto resuelve muchos problemas, pero no puede quitarse de encima la sensación de que el desarrollo de software funciona mejor cuando las personas comparten el mismo espacio
• Las videollamadas son una forma de comunicación de bajo ancho de banda y baja riqueza sensorial, y al perder percepción periférica se vuelve más difícil detectar cuándo un colega está teniendo problemas
• También cuesta más pedir ayuda, y formas de pensamiento espacial como usar pizarras o notas adhesivas se rompen fácilmente en herramientas en línea
• Los conflictos se agravan más rápido porque es más fácil convertir a la persona detrás del monitor en una figura enemiga

• Por qué le costaba escribir sobre esto

  • Después de la pandemia, su empresa pasó a ser totalmente remota, y gracias a eso pudo construir una vida con 27 acres de terreno e incluso una vaca lechera para la familia
  • Como ahora tiene una forma de vida difícil de mover a la ciudad, sentía que decir que no prefiere el trabajo remoto podría dar una mala impresión tanto en su trabajo actual como en cualquier empleo remoto al que postule en el futuro

Planes a partir de ahora

• Siente que con este texto volvió a dar un primer paso para superar el miedo,
  y planea seguir estudiando fundamentos y escribir sin ocultar nada de lo que vaya aprendiendo
• También indica que quienes hayan vivido algo parecido, quieran ayudar o tengan curiosidad por sus próximos textos
  pueden seguir sus novedades a través de Mastodon, RSS y su lista de correo

[GN⁺]

Opinión de Hacker News

• Aprendí algo de un colega muy inteligente. No le teme a no saber y sigue preguntando hasta entender. Me impresionó la confianza y paciencia que se necesitan para aprender en público
• Me gustaron la humildad y la honestidad del texto. No hay por qué avergonzarse de no saber algo. Llevo 37 años aprendiendo y todavía sigo adquiriendo cosas nuevas.
  Yo también prefiero trabajar en la oficina, pero eso no significa que esté defendiendo el RTO (regreso a la oficina). Es solo mi preferencia personal.
  Parece que la ansiedad de la industria y el síndrome del impostor vuelven agresiva a la gente. Si todos fueran más sinceros, creo que estaríamos más tranquilos.
  Y, para confesar algo, nunca he escrito nada más complejo que Fibonacci en Lisp o Haskell. Mi cabeza simplemente no funciona de esa manera
  • No estoy de acuerdo con tu postura sobre el trabajo remoto, pero como la expresaste como una opinión personal, me parece bien.
    El problema es que el texto original presenta su experiencia como si fuera una verdad objetiva generalizable. En especial, la narración en segunda persona me pareció arrogante.
    Cómo lo dices importa tanto como el contenido. En temas sensibles como el trabajo remoto, hay que cuidar mucho la forma de expresarse.
    Yo también tuve que trabajar en remoto por temas de salud en mi familia, así que el tono del texto me pareció frívolo y me molestó.
    Al final, antes de decir que la gente está reaccionando de más, habría que reflexionar primero sobre el impacto que tienen las propias palabras
  • Antes de participar en un proyecto basado en Lisp, yo tampoco podía escribir nada más allá de Fibonacci. Después de usarlo todos los días, terminé acostumbrándome
  • ¿Por qué te atacan si dices que prefieres el trabajo remoto? Porque la gente que ganó libertad después del COVID siente que la están volviendo a limitar. Por eso la reacción parece tan fuerte
  • Hoy en día, los gurús de programación de YouTube dicen que ellos tienen razón en todo. Hagasm lo que hagas, siempre te dicen que está mal
• Cada vez que escucho hablar de trabajo remoto, extraño la época de IRC. En ese entonces ya colaborábamos bien a distancia.
  En vez de conversaciones de pasillo, resolvíamos problemas en el chat del equipo, y todos ayudaban activamente.
  Ahora más bien da la impresión de que usamos peor las herramientas
  • Hoy en día hay mucha gente que tiene miedo de escribir en canales públicos. Antes había anonimato, pero ahora todo está más basado en la identidad real, así que la gente se cuida más.
    A medida que se reducen los espacios para hablar de forma anónima, surge una cultura donde es difícil hablar con libertad
  • Antes, usar Slack en la oficina era mucho más eficiente que ahora.
    En ese tiempo, si algo fallaba, simplemente ibas al escritorio de al lado y lo resolvías; ahora, si falla, ahí queda
  • El trabajo remoto de la época del COVID no era trabajo remoto de verdad. Era aislamiento, y ni la cultura ni los procesos estaban preparados.
    Por eso la gente terminó culpando al trabajo remoto de la soledad
  • Creo que la causa del cambio no tiene tanto que ver con la demografía como con cambios de personalidad. Antes había más “chicos raros”, y ellos no tenían miedo de hacer preguntas.
    Ahora hay más personas socialmente adaptadas, y eso las hace peores para la comunicación asíncrona
  • Arreglar bugs por chat no es lo mismo que “respirar el mismo aire”.
    La densidad con la que se leen las señales no verbales es menor, así que también se pierden pistas sociales
• Aunque estemos en la misma industria SaaS, siento que vivimos en mundos completamente distintos.
  Muchos desarrolladores están siguiendo rutas de carrera más que el interés.
  He reaprendido SQL tres veces. La tecnología cambia todo el tiempo, así que no se puede recordar todo.
  Lo importante no es la sintaxis, sino la capacidad de resolver problemas y colaborar.
  No creo que la IA pueda reemplazar eso fácilmente
• El 95% del código que escribí tenía 0% de cobertura de pruebas. Fue así en varios países y varias empresas. Me pregunto si soy el único
  • Las pruebas automatizadas son una herramienta que da confianza cuando desarrollas de forma repetida. Una vez que te acostumbras, ya no quieres volver atrás
  • A mí me pasó algo parecido, pero ahora estoy intentando cambiar. Agregar pruebas después en un proyecto que no las tiene es realmente difícil
  • Las pruebas tienen algo de sobrevaloradas. A veces dan una falsa sensación de seguridad. También hay muchos casos en los que el propio lenguaje no se presta bien para probar
• El ambiente de la gente que trabaja a mi alrededor me ayuda a concentrarme.
  Existe un efecto contagio de la concentración. Compartir un espacio de trabajo aumenta la productividad
  • Yo también soy de ese tipo. Pero la empresa me obliga a seguir una “política de escritorio limpio”, y eso me incomoda. Necesito un entorno personalizado
  • Siento algo parecido incluso en cafeterías animadas. La productividad de otras personas me estimula
  • Esto es parecido al “body doubling” del ADHD
  • Yo también prefiero trabajar en la oficina, pero necesito sí o sí un espacio con puerta.
    La puerta es la mejor herramienta para regular la colaboración y la concentración.
    Es una señal mucho más clara que el estado “away” en línea
  • Pero no todo el mundo trabaja bien en ese tipo de entorno.
    Obligar a otras personas a ir a la oficina por la fuerza para que alguien más pueda concentrarse es inhumano
• Este texto es valiente. Pero también muestra bien el problema de generalizar experiencias personales.
  Puede que el problema no sea el trabajo remoto, sino haber trabajado en una empresa con malos sistemas de apoyo
• El autor es demasiado duro consigo mismo. Reconocer que uno no sabe algo da una sensación de liberación.
  Yo también digo “no sé” con frecuencia. Creo que eso es una característica de la gente con alta EQ
  • A mi jefe le gustaba que yo dijera “no sé”. La honestidad genera confianza
  • En el trabajo está bien, pero en línea es difícil decir “no sé” por la preocupación por la reputación
  • Cuando en una entrevista preguntan por git rebase, me parece que importa más la capacidad real de usarlo que los detalles técnicos
• Me gustó la honestidad del autor. Yo también pasé por algo parecido.
  Mientras hacía live coding en Kotlin, me bloqueé porque no me salía la sintaxis de switch.
  Ahí me di cuenta de que incluso un lenguaje que usas todos los días se puede olvidar rápido
  • Yo también busco la sintaxis de switch cada vez. Si no lo usas seguido, es normal olvidarlo
  • A medida que haya más desarrolladores mayores, creo que seremos más tolerantes con estos “momentos de olvido”
  • Todo el mundo se equivoca. Incluso los jefes a veces olvidan el atajo de pegar
  • Si no usas una habilidad con frecuencia, se deteriora rápido, pero en cuanto la vuelves a usar, regresa enseguida.
    Los conceptos duran mucho, pero los detalles de sintaxis se van rápido
• Al principio pensé que el texto trataría sobre la desaparición de los desarrolladores por culpa de la IA.
  Pero en realidad, el ambiente es tal que hasta resulta difícil hablar de esa ansiedad.
  Yo también disfruto escribir código con Claude, pero al mismo tiempo siento miedo.
  Si somos la generación que mejor entiende la naturaleza de los cambios que se vienen, entonces tenemos que hablar de eso
  • El código que hace Claude no va a ser mejor que el código humano. Lo que sí hace es aumentar la velocidad de producción.
    El problema es que eso podría ser solo aumentar la productividad de personas sin habilidades reales
  • Durante los próximos años, seguiremos siendo los team leads de agentes de IA.
    Pero si las empresas empiezan a usar IA en roles de gestión, habrá cada vez menos espacio para los desarrolladores humanos.
    Desde ahora habría que prepararse para moverse hacia roles como consultor de eficiencia de IA
  • Yo simplemente pienso colaborar con la IA o hacer otra cosa interesante. Programar no lo es todo
  • ¿Una empresa con una política “AI doomer”? Eso es una cultura organizacional tóxica. Hay que buscar otro trabajo de inmediato