Chemaclass - career

Trabajar con la Puerta del Garaje Abierta

2026-07-14T00:00:00+00:00

La mayoría trabaja con la puerta del garaje cerrada. Trabajan en privado y solo la levantan cuando el coche está pulido y aparcado. Los vecinos ven algo terminado. Nunca el trabajo.

La frase viene del escritor Robin Sloan. El investigador Andy Matuschak la convirtió en una práctica: notas e ideas a medio hacer visibles para cualquiera que pase por delante.

Abre la puerta.

Significa mostrar el trabajo cuando todavía está en marcha. El borrador con los nombres de variables feos. El experimento que llevas a medias. No la demo. El proceso.

Por qué la mantenemos cerrada #

Miedo, sobre todo. Una puerta cerrada te protege. Nadie juzga un desorden que no puede ver.

Así que escondemos los borradores. Solo subimos código cuando está limpio para sobrevivir a la revisión. Para cuando alguien ve el trabajo, cada decisión de verdad ya se tomó en privado.

Ese instinto parece seguro. Te cuesta justo los momentos en los que la ayuda todavía era posible.

Un resultado terminado solo se puede admirar. Un trabajo en marcha se puede moldear.

Lo que te da la puerta abierta #

Cuando la gente ve el proceso, puede cambiarlo. Un compañero detecta el enfoque sin salida antes de que le dediques otro día. Un junior hace la pregunta “tonta” que resulta ser el problema de verdad. El pair programming es esto en estado puro: la puerta abierta, en directo.

La puerta abierta también mata el mito de que los seniors no sufren. Cuando un junior te ve atascarte y buscar en Google un error que “deberías” saber, aprende cómo es el trabajo real. No los mejores momentos.

Yo viví esto con bashunit, mi librería de testing para bash. La publiqué imperfecta. Todo el que miró dentro del garaje la moldeó: bugs reportados, peticiones de features, pull requests. Igual con Phel y mi carpeta .claude pública. El espíritu del open source.

Pero una puerta abierta no basta #

Aquí está la trampa. Dejas la puerta subida, abres una PR, escribes notas en un documento compartido y esperas.

No llega. Nadie se pasea por tu garaje.

La visibilidad es pasiva. “Público por defecto” es el suelo, no la meta.

Dejar la puerta abierta no es lo mismo que invitar a alguien a entrar.

El skill no es la apertura. Es empujar la señal correcta a la gente correcta, a propósito.

Empuja la señal a la sala correcta #

Cada canal viene con una expectativa de quién lo lee. Ajustar tu update a ella es todo el juego. Publica en la sala equivocada y serás ruido o invisible.

Toda la empresa lo lee. #general. Publica solo lo que le importa a todo el mundo.
El equipo técnico lo lee. #engineering. Donde va un update de trabajo en marcha.
Quien tiene interés se apunta. #insights: novedades del sector, señales de clientes. Útil, pero nadie tiene que leerlo.
Nadie tiene que leerlo. #random. Di lo que quieras.

Mismo update, cuatro resultados distintos según dónde caiga. Aprende el mapa antes de emitir.

Cómo es una buena señal #

Un buen update no es “eh, he subido algo”. Lleva suficiente contexto para engancharse sin hacerte ni una sola pregunta.

Digamos que voy por la mitad de un piloto: una nueva forma de trocear y revisar pull requests, probada en un equipo. No espero al final. Un update corto va a #engineering: dónde estoy atascado, más una petición explícita. “¿Alguien ha probado esto con un monorepo?” recibe respuestas.

Cuando el piloto termina, el resultado va a la misma sala:

Qué probé y por qué importaba.
Qué funcionó, con un antes y un después concretos.
Qué no, con honestidad. La parte que falló es la más útil.
Qué harías tú para probarlo por tu cuenta.

Ambas son señales, no estados. Convierten el experimento de un equipo en algo que toda la organización puede copiar o tumbar. Esto es Ship, Show, Ask aplicado más allá del pull request.

Empieza poco a poco #

Elige una cosa esta semana. Un experimento, un borrador, un momento de atasco. Haz dos cosas: deja la puerta abierta y luego sal y dile a la sala correcta que está ahí.

Recibirás ayuda que no esperabas. Enseñarás a alguien sin pretenderlo. Y el miedo que mantenía la puerta bajada se verá más pequeño desde el otro lado.

El resultado pulido impresiona a la gente. La señal empujada es lo que mejora el trabajo.

Abre la puerta. Y luego señálala.

El Eterno Retorno

2026-06-01T00:00:00+00:00

Nietzsche propuso un experimento mental en La gaya ciencia. Imagina que un demonio te visita por la noche y te dice: esta vida que has vivido, la vivirás otra vez, infinitas veces, exactamente igual. Cada alegría, cada arrepentimiento, cada detalle. ¿Te derrumbarías o lo celebrarías como un regalo?

No lo decía en sentido literal. Lo decía como prueba. ¿Puedes vivir de tal forma que querrías revivirla?

Pasaron años antes de que esa idea volviera a encontrarme. No como filosofía. Como patrón.

Eventos que riman #

Pasa algo. Tiempo después, pasa otra cosa distinta. Otra gente, otros riesgos, otra ciudad. Y aun así la forma resulta familiar. No la superficie, no un déjà vu, sino algo por debajo. El mismo tipo de presión, el mismo tipo de decisión, el mismo tipo de sala en la que tienes que entrar.

No es que los eventos estén conectados. No lo están. La causalidad no los une. Tu cerebro los une, porque exponerse a suficiente vida produce colisiones de forma. Cuanto más vives, más formas se acumulan. Tarde o temprano, la nueva rima con la antigua.

He sentido esto muchas veces. Cambiando de empresa, cerrando un capítulo de trabajo y empezando otro, con gente nueva y restricciones nuevas, y aun así el mismo clima interno creciendo dentro de mí mientras cruzo el umbral. También en momentos más callados: cierta luz en octubre, cierto silencio en enero, que vuelven cada año y traen con ellos el mismo tipo de pensamientos, las mismas curiosidades, las mismas preguntas que nunca terminé de hacerme.

La trampa de la falsa sabiduría #

La conclusión fácil es: ya he visto esto antes, sé qué hacer. Esa conclusión es errónea.

Los eventos no son los mismos. La lección del anterior no se traslada limpiamente. Actuar como si lo hiciera es la forma más común en que los expertos cometen errores de expertos. Confunden reconocimiento con comprensión.

La familiaridad de la forma no es conocimiento de la solución.

Lo que la repetición realmente te da #

Lo que se repite no es la situación. Lo que se repite eres tú, dentro de la situación.

El mismo tipo de presión saca a la superficie las mismas partes de ti. El mismo tipo de decisión expone los mismos instintos, los mismos miedos, los mismos movimientos por defecto. La primera vez, estás demasiado dentro para verlo. La segunda vez, empiezas a notarlo. La tercera, puedes nombrar lo que está pasando mientras pasa.

Ese es el regalo. No sabiduría predictiva sobre el mundo. Conciencia diagnóstica sobre ti mismo.

La exposición es la variable #

La gente que recibe este beneficio no son los listos. Son los expuestos. Los que aceptaron el trabajo difícil, dijeron que sí a la conversación difícil, se quedaron con el feedback incómodo en lugar de descartarlo, se mudaron de ciudad cuando habría sido más fácil quedarse, aceptaron el proyecto para el que no estaban listos.

Los patrones no pueden rimar si solo vives una forma.

Por eso importa mantenerse abierto. Abrazar el cambio no es personalidad, es método. Es cómo acumulas la materia prima que, mucho después, te permite reconocerte bajo presión.

Diez años después #

Hace diez años estaba escribiendo un libro de mis pensamientos. Escribía cada pocos días, solo para releerlos al día siguiente y entenderme mejor. Ya no soy esa persona.

Todo principio lleva la forma de un final. Aceptarlo te permite dejar de perseguir lo definitivo y prestar atención al proceso en sí.

Proceso por encima de meta. El papel que asumes importa menos que el personaje que construyes dentro de él. El impacto que dejas no es el que pretendías, es la forma del hueco que creas cuando ya no estás.

Lo que está en tu control #

Los eventos en sí casi nunca están bajo tu control. Qué complicaciones llegan, cuándo, con qué severidad: no te toca decidirlo.

Lo que sí te toca: si te quedas el tiempo suficiente para ver la forma. Si reflexionas después en lugar de pasar página limpiamente. Si dejas que la siguiente colisión te enseñe algo sobre ti mismo en lugar de insistir en que te enseñe algo sobre el mundo.

El mundo no repite nada. Tú repites casi todo.

El verdadero eterno retorno #

El demonio de Nietzsche no estaba preguntando por la reencarnación. Estaba preguntando si has vivido una vida digna de ser vivida. La prueba es interna.

Así que pregúntatelo. Si esta misma vida se repitiera para siempre, sin que cambie un solo detalle, ¿la respuesta honesta sería alegría o arrepentimiento? Eres el único que puede responder, y al que más le cuesta hacerlo con sinceridad.

Amo estar vivo. El hecho de que termine es justo lo que le da peso al tiempo dentro de él. Si no me gusta en quién me estoy convirtiendo, aún tengo tiempo de cambiar. Eso es lo único útil que el retorno ha ofrecido jamás. No conocimiento del futuro. Un espejo en el presente.

Tenemos una vida. Haz que sea una que querrías revivir.

Lo que el Éxito Significa para Mí

2025-09-15T00:00:00+00:00

Durante mucho tiempo, pensé que el éxito se trataba de alcanzar ciertos hitos. Conseguir esa promoción. Ganar un salario específico. Construir algo que la gente reconociera.

Pero me he dado cuenta de que eso no es lo que me hace levantarme por las mañanas.

La verdadera medida #

El éxito, para mí, ahora es directo: despertar sabiendo que lo que hago hace más felices a las personas a mi alrededor, y a mí mismo.

Me costó llegar a esto. Puede que esta definición no le parezca simple a todo el mundo, y está bien. Pero para mí, lo clarificó todo.

Sin fórmula complicada. Sin lista de logros.

El éxito son esos pequeños momentos: ayudar a un colega con un problema complicado, compartir algo que hace sonreír a alguien, terminar el día sintiendo que aportaste algo bueno al mundo.

Aplica tanto si lideras un equipo como si simplemente eres tú mismo. Como escribí sobre gran liderazgo, el verdadero liderazgo empieza con tu propia vida y comportamiento. Se trata de hacer mejores a quienes te rodean, no solo de alcanzar objetivos.

Por qué importa la felicidad #

Antes pensaba que enfocarse en la felicidad era algo trivial. Como si no fuera un objetivo “serio”. Pero he aprendido que hacer feliz a la gente de verdad es una de las cosas más difíciles y gratificantes que puedes hacer.

¿Qué significa esto en la práctica? #

Estar presente cuando alguien te necesita
Crear cosas que resuelvan problemas reales
Elegir la amabilidad sobre tener razón
Encontrar alegría en lo que haces, incluso en días difíciles

Cuando te enfocas en hacer felices a otros, sueles acabar más feliz tú también. No es un juego de suma cero. Se multiplica.

Conecta mucho con entender a las personas y cómo piensan. Cuando entiendes que cada uno procesa el mundo de forma diferente, te vuelves mejor creando felicidad genuina. No la que tú crees que debería hacerles felices.

La práctica diaria #

¿Cómo se ve esto en la vida diaria? #

Para mí, es preguntarme con frecuencia: “¿Lo que hice hoy mejoró las cosas?” No perfecto. No revolucionario. Solo mejor.

A veces es escribir código que ayuda a un equipo a trabajar mejor. A veces es tomarse tiempo para escuchar de verdad a alguien. A veces es simplemente tener paciencia cuando todo parece un caos.

No siempre es fácil. Algunos días fallas. Pero tener esta definición simple de éxito aclara las decisiones. Cuando dudas si aceptar un proyecto, una oportunidad, o decir que no a algo, puedes preguntarte: “¿Esto nos hará más felices a mí y a quienes me rodean?”

Consistencia sobre perfeccionismo #

Aquí hay algo que he aprendido por las malas: el éxito se construye a través de la consistencia, no la perfección.

El perfeccionismo te paraliza. Te susurra que nada es suficientemente bueno, que deberías esperar a que las condiciones sean ideales, que un error lo invalida todo. Es una trampa.

¿Qué funciona de verdad? Aparecer. Día tras día. Construir pequeños hábitos que se acumulan con el tiempo.

Como explica James Clear en Hábitos atómicos, el cambio real viene del efecto acumulado de cientos de pequeñas decisiones. No necesitas ser perfecto. Necesitas ser constante.

No intentes hacer un hábito perfecto, solo repítelo.

Eso significa:

Escribir unas líneas de código cada día supera esperar la arquitectura perfecta
Una conversación corta y genuina supera esperar el momento perfecto
Pequeñas mejoras constantes superan esperar el gran avance

El objetivo no es no fallar nunca. Es construir hábitos que te hagan más feliz a ti y a otros, y seguir apareciendo incluso cuando tropiezas.

Aquí es donde el proceso mismo se convierte en el objetivo. No se trata de llegar a un destino final de “ser exitoso”. Se trata de construir hábitos diarios que se alineen con lo que realmente te importa.

El éxito es personal #

Tu definición de éxito probablemente sea diferente a la mía. Y eso no solo está bien, es necesario.

“¿Siempre he sido así?” No. Claro que no. Lo que nos importa evoluciona mientras crecemos. Eso es parte del viaje.

Si te sientes atascado o no sabes hacia qué trabajas, prueba esto: descubre qué te hace feliz de verdad a ti y a quienes te importan. No lo que crees que debería hacerte feliz. No lo que queda bien de cara a los demás.

Solo lo que realmente funciona para ti.

Y prepárate para abrazar el cambio cuando tu definición cambie. Porque cambiará. Lo que el éxito significa hoy puede ser distinto mañana. Eso no es fracaso. Es crecimiento.

Al final del día, si despiertas sabiendo que lo que haces trae más felicidad al mundo (incluida la tuya), probablemente estás haciendo algo bien.

Eso se siente como éxito para mí.

Gracias a mi amigo Toni, por plantear esta pregunta e inspirar esta reflexión.

Principios de Economía

2025-06-22T00:00:00+00:00

¿Te has preguntado alguna vez por qué los precios suben o por qué el dinero pierde valor? Principios de Economía de Saifedean Ammous puede cambiarte la perspectiva.

No es el típico libro de economía aburrido. Es una guía directa para entender cómo funciona el mundo desde la economía austriaca. Esto es lo que más me marcó.

1. Economía = acción humana #

Ammous arranca con algo simple pero potente: la economía son personas tomando decisiones. Cada vez que eliges una cosa sobre otra, eso es economía en acción.

Olvídate de gráficos y ecuaciones. La economía real empieza contigo tratando de mejorar tu vida, una decisión a la vez.

2. Preferencia temporal = cuánto valoras el futuro #

Esta idea me cambió la forma de ver las cosas: tu preferencia temporal es cuánto valoras el ahora frente al después.

Si gastas todo hoy, tienes preferencia temporal alta.
Si ahorras y planificas, tienes preferencia temporal baja.

La preferencia temporal baja construye cosas grandes: negocios, familias, rascacielos, civilizaciones. La alta es comida rápida, compras impulsivas, pensamiento cortoplacista.

3. Buen dinero = sociedad fuerte #

La calidad del dinero afecta todo. Si tu dinero pierde valor constantemente (hola, inflación), la gente deja de ahorrar y vive solo para hoy.

Ammous señala al dinero fiat controlado por gobiernos como el problema. Y defiende volver al “dinero duro” (oro o Bitcoin) que mantiene su valor. El buen dinero permite planificar, ahorrar y crear riqueza a largo plazo.

4. Producir lleva tiempo, y eso importa #

Hacer cosas no es instantáneo. Requiere tiempo, herramientas y planificación. Ammous explica que las economías avanzadas existen porque la gente invierte a largo plazo: fábricas, máquinas, cadenas de suministro.

Eso solo ocurre cuando confías en tu dinero y en tu futuro. De nuevo, la preferencia temporal baja es clave.

5. Los emprendedores impulsan el progreso, no los gobiernos #

El héroe de este libro es el emprendedor: quien toma riesgos, construye negocios y crea valor.

Ammous no tiene simpatía por planificadores centrales, regulaciones ni rescates gubernamentales. Defiende mercados libres donde la gente resuelva problemas sin interferencias. Con precios honestos y dinero sólido, la gente se las arregla sola.

6. Inflación y planificación central: señales de alarma #

Ammous no se anda con rodeos. Critica duramente cómo los gobiernos gestionan el dinero.

Ve la inflación como robo encubierto. Y cree que la intervención constante (imprimir dinero, fijar tasas de interés) solo empeora las cosas. También cuestiona campos como la economía climática y ESG, que considera más políticos que económicos.

7. Bitcoin: el gran final #

El libro no trata solo de Bitcoin, pero claramente lleva hacia allí. Tras explicar por qué el sistema monetario actual está roto, Ammous presenta Bitcoin como la mejor solución en más de un siglo.

Es digital, limitado y nadie puede manipularlo. Bitcoin representa el regreso del dinero sólido. Una oportunidad de arreglar mucho de lo que hoy está mal.

Un curso intensivo de economía real #

“Principios de Economía” es una píldora roja. Directo, audaz y a veces brutal. Si estás cansado de las tonterías financieras habituales, este libro es aire fresco.

Sales con una lente nueva para ver el mundo: por qué suben los precios, por qué importa ahorrar y por qué el tipo de dinero que usamos lo moldea todo.

Economía Austriaca vs Economía Keynesiana #

Minimalismo digital

2025-02-16T00:00:00+00:00

Vivimos conectados todo el tiempo. El minimalismo digital de Cal Newport no propone rechazar la tecnología, sino usarla con intención. El resultado: recuperas tu enfoque, reduces la ansiedad y construyes relaciones más profundas.

Los tres principios del minimalismo digital #

Newport basa su enfoque en tres ideas:

El desorden cuesta caro: Las distracciones digitales fragmentan tu atención y agotan tu energía mental. Ordenar tu vida digital te devuelve el control.
Optimizar es esencial: No aceptes cada app o plataforma sin pensar. Elige solo las que encajan con tus valores y metas.
La intención lo es todo: No se trata solo de reducir el tiempo de pantalla. Se trata de decidir cuándo y cómo usas la tecnología.

El detox digital de 30 días #

Una de las estrategias más prácticas de Newport:

Descanso de 30 días de todas las herramientas digitales no esenciales.
Explora actividades offline que te satisfagan de verdad.
Reintroduce solo lo que añada valor real a tu vida.

Es un reinicio. Te ayuda a ver qué tecnologías mejoran tu vida y cuáles solo te roban tiempo.

Qué ganas con el minimalismo digital #

Quienes lo adoptan notan:

Mejor enfoque: Menos distracciones significa trabajo profundo más accesible.
Menos ansiedad: Sin redes sociales ni notificaciones constantes, tu mente se calma.
Relaciones más ricas: Priorizar lo presencial fortalece los vínculos reales.
Mayor productividad: Menos ruido digital, más eficiencia y creatividad.

Cómo empezar #

Algunos pasos concretos:

Audita tu vida digital: ¿Qué apps te quitan tiempo sin darte nada a cambio?
Pon límites de pantalla: Usa las herramientas del móvil para restringir ciertas apps.
Crea zonas libres de tecnología: El dormitorio o la mesa del comedor, por ejemplo.
Vuelve a lo analógico: Libros, hobbies, conversaciones cara a cara.
Programa horas offline: Momentos del día donde te desconectas del todo.

Para cerrar #

El minimalismo digital no rechaza la tecnología. La usa de forma que mejore tu vida, no que la consuma. Con un enfoque más consciente de tus hábitos digitales, recuperas tiempo, bienestar y atención para lo que de verdad importa.

Resumen en Video #

Cal Newport entrevistado por Lex Fridman #

El hombre en busca de sentido

2024-11-29T00:00:00+00:00

Frankl comparte sus desgarradoras experiencias del Holocausto y presenta una filosofía profunda sobre la condición humana. Un testimonio de la resiliencia del espíritu humano: incluso en los momentos más oscuros, uno puede encontrar propósito y sentido.

Su visión sobre la psicología de la supervivencia y el desarrollo de la logoterapia nos dan una perspectiva única para mirar nuestras propias vidas. Al adentrarnos en su narrativa, reflexionamos sobre nuestra propia búsqueda de sentido y cómo encontrar propósito entre las pruebas que nos pone la vida.

Parte 1: Experiencias en un campo de concentración #

Frankl, psiquiatra austriaco, relata sus experiencias en campos de concentración nazis como Auschwitz y Dachau durante la Segunda Guerra Mundial.

Describe las etapas psicológicas de los prisioneros: shock al llegar, apatía (se volvían emocionalmente insensibles para sobrevivir) y finalmente desilusión o amargura si eran liberados.

Frankl subraya que incluso en las condiciones más horribles, encontrar un propósito da fuerza para sobrevivir. Quienes tenían algo por lo que vivir (un ser querido, un proyecto personal) resistían mejor.

Parte 2: La logoterapia en pocas palabras #

Aquí Frankl presenta su método psicoterapéutico, desarrollado a partir de sus experiencias. La logoterapia se centra en el sentido de la existencia humana y la búsqueda de ese sentido.

A diferencia de la “voluntad de placer” de Freud o la “voluntad de poder” de Adler, Frankl propone la “voluntad de sentido” como la fuerza motivacional primaria del ser humano.

Tres caminos hacia el sentido:

Logro: hacer una obra o crear algo.
Experiencia: vivir algo o encontrar a alguien (amor).
Actitud: la postura que tomamos ante el sufrimiento inevitable.

Incluso en situaciones extremas, uno puede elegir su actitud. Y esa elección puede ser una fuente poderosa de sentido.

Frankl también habla del vacío existencial: la falta de sentido en la sociedad moderna, que lleva a problemas psicológicos. La logoterapia busca guiar a cada persona a encontrar su propio sentido.

Puntos clave #

Sentido de la vida #

Frankl sostiene que no hay un sentido universal de la vida. El sentido es único para cada persona y puede cambiar con el tiempo.

Sufrimiento y sentido #

El sufrimiento no tiene por qué carecer de sentido. Puede ser un camino para encontrarlo o reafirmarlo.

Responsabilidad #

Cada uno tiene la responsabilidad de encontrar su propio sentido, lo que implica también la libertad de elegir su camino.

El libro de Frankl no es solo unas memorias, sino un testimonio de la resiliencia humana y del poder del espíritu para trascender las peores circunstancias a través del descubrimiento del sentido.

Citas #

“En última instancia, el hombre no debería preguntar cuál es el sentido de su vida, sino reconocer que es él quien está siendo cuestionado.”

“Teníamos que dejar de preguntar por el sentido de la vida y pensar en nosotros mismos como quienes estaban siendo cuestionados por la vida, diaria y constantemente.”

“Todo puede arrebatársele a un hombre excepto una cosa: la última de las libertades humanas, elegir la actitud ante cualquier circunstancia, elegir el propio camino.”

“La libertad no es la última palabra. Es solo parte de la historia y la mitad de la verdad. La libertad es el aspecto negativo del fenómeno completo; el aspecto positivo es la responsabilidad.”

Notas personales #

Lo que más me gusta del libro es cómo presenta la vida como un cambio continuo de perspectivas, tanto desde dentro como en relación con el mundo. Es como ajustar el zoom de una cámara según el contexto, reconociendo que somos a la vez individuos y parte de algo más grande.

Este enfoque ayuda a ganar perspectiva: ser consciente de tus limitaciones y de tu importancia en cada situación. Al final, la vida no tiene un sentido inherente. Es el sentido que elegimos darle lo que da forma a nuestra existencia.

Resumen animado del libro #

Habilidades Interpersonales

2024-09-02T00:00:00+00:00

Así que eres desarrollador de software, y has dominado lenguajes de programación, algoritmos y todo lo técnico. ¡Genial! Pero aquí está el asunto: las habilidades técnicas por sí solas no te llevarán tan lejos como podrías pensar.

Si no puedes trabajar bien con otros, no importa lo bueno que sea tu código, nadie querrá trabajar contigo.

Por qué las habilidades interpersonales importan en software #

En el desarrollo de software, la colaboración lo es todo. Los proyectos no son solo esfuerzos en solitario. Serás parte de un equipo, con otros desarrolladores, diseñadores, o incluso personas no técnicas como gerentes y clientes. Cómo comunicas, colaboras y manejas las opiniones que recibes puede determinar tu éxito.

El compañero brillante pero difícil #

Piénsalo. ¿Alguna vez has tenido ese compañero de equipo que es brillante pero difícil o casi imposible de trabajar con él? Quizás no escucha, se lleva todo el crédito, o hace todo más complicado de lo necesario. A nadie le gusta trabajar con esa persona, ¿verdad? Es lo mismo para ti. Si no puedes llevarte bien con tu equipo, no importa lo bueno que sea tu código.

Qué significa ser un buen compañero de equipo #

Ser un buen compañero de equipo significa escuchar a los demás, estar abierto a la crítica constructiva, compartir ideas, y lo más importante, ser respetuoso y considerado. Quieres que la gente disfrute trabajando contigo, no que lo eviten.

Las buenas habilidades interpersonales te ayudan a construir relaciones de trabajo sólidas, resolver problemas más rápido y crear un mejor ambiente de trabajo para todos. No solo aspires a ser un experto en programación, asegúrate de que también seas genial para trabajar.

El impacto a largo plazo #

A largo plazo, tus habilidades interpersonales pueden impulsar tu éxito tanto, si no más, que tus habilidades técnicas. Juegan un papel vital en el éxito de un equipo y hacen que la experiencia de trabajo sea agradable para todos los involucrados.

Las habilidades interpersonales son tan necesarias como las habilidades técnicas. Nadie querrá trabajar contigo si no eres un buen compañero de equipo.

¿Qué son las habilidades interpersonales? #

Las competencias que te permiten interactuar efectiva y fluidamente con otros.

Habilidades de comunicación fundamentales #

Comunicación: La capacidad de transmitir ideas claramente, escuchar activamente y participar en conversaciones significativas. Esto incluye tanto la comunicación verbal como la no verbal.
Empatía: Entender y ser sensible a los sentimientos, pensamientos y experiencias de otros. Implica ver las cosas desde la perspectiva de otra persona.
Inteligencia emocional: Reconocer y gestionar tus propias emociones y entender e influir en las emociones de otros.

Habilidades de colaboración #

Trabajo en equipo: Trabajar bien con otros para lograr objetivos comunes. Esto incluye colaboración, compartir responsabilidades y apoyar a los colegas.
Resolución de conflictos: La capacidad de manejar desacuerdos y disputas de manera constructiva, encontrando soluciones que satisfagan a todas las partes involucradas.
Negociación: Encontrar soluciones o compromisos mutuamente aceptables durante discusiones o desacuerdos.

Crecimiento e influencia #

Adaptabilidad: Ser flexible y abierto al cambio, ajustando tu enfoque según sea necesario para enfrentar diferentes situaciones o personalidades.
Liderazgo: Inspirar y guiar a otros, proporcionar dirección y fomentar un ambiente positivo.
Networking: Construir y mantener relaciones profesionales que puedan proporcionar apoyo, oportunidades y recursos.

Estas habilidades son esenciales en casi cualquier trabajo y ayudan a construir relaciones sólidas, mejorar el trabajo en equipo y crear un ambiente de trabajo positivo.

Por qué son más difíciles de lo que piensas #

A menudo se les llama habilidades interpersonales o blandas, pero dominarlas puede ser sorprendentemente desafiante, quizás incluso más que muchas habilidades técnicas. A diferencia de las “habilidades duras”, que son tangibles y a menudo se pueden aprender a través de unas pocas horas o días de estudio, las habilidades interpersonales implican navegar la intrincada red de emociones, experiencias y expectativas humanas.

Mientras que las habilidades técnicas pueden requerir que te sumerjas en documentación, ejecutes experimentos y refines tu enfoque, entender y relacionarte con las personas es mucho más complejo.

Los humanos traen sus sentimientos, antecedentes y rutinas a las interacciones, añadiendo capas de complejidad más allá de la lógica directa de las máquinas. Estos detalles personales moldean la realidad que percibimos, haciendo que las habilidades interpersonales sean una parte esencial pero compleja de la comunicación y colaboración efectiva.

Gran Ingeniería

2023-12-30T00:00:00+00:00

Programar no es solo otro trabajo. Escribir software puede ser realmente divertido y, aún más, ¡puede ser tu hobby personal también! Podrías estar enfocado en programar, programar y más programar para subir de nivel tus propias habilidades profesionales.

Eso no tiene nada de malo. La práctica hace al maestro, y programar mucho te ayudará a mejorar tus habilidades de codificación. Pero hay otros aspectos que debes tener en cuenta para crecer como gran ingeniero.

Como ingeniero de software, tu trabajo no es “solo escribir código”, sino usar el software para resolver problemas reales de negocio. Para lograrlo, existen muchas metodologías. Pero en algo hay que estar de acuerdo: necesitas identificar y entender las necesidades de tu cliente para saber qué construir.

Necesitas conocer tu producto, al menos hasta cierto nivel, para diseñar tu software usando un lenguaje cercano al negocio. Esto ayuda a su evolución y calidad, y facilita el mantenimiento presente y futuro.

IT, Software, Producto y Personas están muy conectados. Entender la relación entre estos campos ayuda a cada persona a cumplir mejor sus objetivos.

Un gran trabajo en equipo no es solo la suma de las partes: multiplica el valor creado entre los compañeros. Para eso, saber comunicar bien es clave para generar claridad a cualquier nivel.

Por eso un gran ingeniero conoce de negocio, cliente, producto y programación. Entender estos puntos marca la diferencia entre un ingeniero promedio y uno excelente.

Imagen original de Nicola Ballotta.

El Alquimista

2023-11-07T00:00:00+00:00

Santiago es un joven pastor que tiene un sueño recurrente: hay un tesoro esperándole en las pirámides de Egipto. Decide ir a buscarlo. Por el camino encuentra mentores, se enamora y, sobre todo, aprende quién es realmente y qué es lo que importa de verdad en la vida.

Resumen en Video #

El Principio de Peter

2023-09-30T00:00:00+00:00

Cuando alguien es competente en su trabajo, lo ascienden a un puesto que requiere otras habilidades. Si no las tiene, será incompetente y no lo ascenderán más.

Si es competente en el nuevo rol, lo ascenderán otra vez. Y seguirá subiendo hasta alcanzar un nivel donde sea incompetente. Ahí se quedará atascado: la “meseta de Peter”.

Hay incentivos en juego. La gente trabaja duro para alcanzar cierta posición o salario. Una vez que lo logra, algunos se relajan. Cuando pierden la pasión, dejan de aprender. No se mantienen al día con los nuevos desarrollos y su trabajo empeora. Para proteger su zona de confort, rechazan cualquier idea o persona nueva que pueda incomodarlos. Los empleados incompetentes suelen estar insatisfechos.

¿Has vivido el Principio de Peter? #

Lo he visto varias veces en mis 10 años de carrera, trabajando en diferentes empresas, con personas de distintos departamentos y niveles. Es más peligroso de lo que parece porque puede matar el espíritu de un ambiente sano.

Ser consciente de esto te ayuda a evitar que te pase. O al menos a detectar las señales cuando empiece a ocurrirte.

¿Qué puedes hacer? #

Si reconoces esta situación en tu empresa, ayuda a crear conciencia. Hablad entre vosotros. Si sientes que no puedes, eso es síntoma de un ambiente de trabajo no saludable, y eso es un problema mayor.

Si eres tú quien lo está viviendo en primera persona, te recomiendo:

Habla con tu manager. Pide formación, mentoría o lo que necesites para adquirir las habilidades que te faltan: confianza, comunicación, o lo que ayude a tu nuevo rol. Quizás no recibiste la formación adecuada para un trabajo que requiere habilidades diferentes.
Considera volver a donde eras bueno y seguir dominando eso. Ayuda e inspira a quienes están a tu lado. No todo el mundo tiene que ascender siempre.

Bucle sin Fin

2023-07-05T00:00:00+00:00

A veces me cuesta irme a la cama con la mente en blanco porque muy a menudo pienso en mi próxima lectura, aprendizaje, charla, o qué escribiré este mes o el siguiente.

Es curioso recordar que hace ocho años, me quedaba despierto durante horas hasta que todo tipo de pensamientos salían en papel, así que solía escribir uno o más de ellos cada semana. A veces pensamientos inocentes venían a mi cerebro y no me dejaban dormir correctamente. A veces profundos y llenos de preocupación que reflejaban cómo luchaba con ciertas situaciones que estaba viviendo o recordando de mi pasada juventud.

Seguí escribiendo durante tres años; escribí mucho, otro formato del que suelo hacer hoy; un libro profundo y personal sobre mis pensamientos y sentimientos con la motivación principal de leerlos después y hacer algunas retrospectivas para ayudarme a entenderme mejor. Hoy en día, me gusta mezclar mi pasión por la calidad del software y los rompecabezas de personas para lograr la verdadera excelencia en mi profesión, siempre apuntando a un egoísmo honesto y saludable de ayudar a otros que podrían ayudarme después. Cuanto mejores sean las personas a mi alrededor, mejor ayudarán a otros y a mí.

En aquel entonces, solía escribir sobre mis sentimientos actuales y pasados, siempre con un toque de ilusión queriendo expresarme de manera diferente para mi yo futuro. Recuerdo claramente, al principio, quería que los lectores principales fueran mis hermanos, mi familia, para saber cómo me iba tan lejos de todos ellos, después de emigrar a otro país, lejos de mi familia. Sin embargo, a medida que pasaban los meses, el lector principal cambió a no ser nadie más que yo mismo.

Pasé horas en cada pensamiento, página, capítulo… Redactando la idea inicial y luego leyéndola en voz alta una vez, dos veces, de nuevo, y otra vez al día siguiente. Ayudando de esta manera a descubrir esa parte de mí mismo que intentaba reflejar lo que estaba pasando dentro.

Puedo ver algunas similitudes hoy en día. Sin embargo, ya no veo la necesidad de escribir sobre esos profundos pensamientos antiguos porque sanaron. En cambio, puedo reflexionar y ver cómo lo hicieron y cómo.

Escribir es una de mis formas favoritas de expresarme, especialmente cuando no puedo dormir. Me recuerda a esos años, y pienso enormemente en la increíble evolución desde entonces.

Fotos originales de mi viaje a la Toscana, Italia, el mes pasado.

Indefensión Aprendida

2023-06-08T00:00:00+00:00

La indefensión aprendida es el comportamiento que muestra una persona tras sufrir repetidamente situaciones adversas que escapan a su control.

Se origina cuando alguien acepta su impotencia y deja de intentar escapar o evitar dichas situaciones.

Experimentos #

Un aula con diferentes evaluaciones #

Charisse Nixon, Ph.D Psicóloga del Desarrollo en Penn State Erie, The Behrend College y Directora de Investigación y Evaluación para The Ophelia Project discute el fenómeno de la indefensión aprendida.

Original: Descargas eléctricas y arneses #

En 1967, el psicólogo americano Martin Seligman en la Universidad de Pennsylvania investigó descargas eléctricas y arneses.

En la Parte 1 de este estudio, tres grupos de perros fueron colocados en arneses. Los perros del Grupo 1 fueron puestos en un arnés durante algún tiempo y liberados después. Los Grupos 2 y 3 consistían en “parejas acopladas.” A los perros del Grupo 2 se les daban descargas eléctricas aleatorias, que el perro podía terminar presionando una palanca. Cada perro del Grupo 3 estaba emparejado con un perro del Grupo 2; cada vez que un perro del Grupo 2 recibía una descarga, su perro emparejado en el Grupo 3 recibía una descarga de la misma intensidad y duración, pero su palanca no detenía la descarga. Para un perro del Grupo 3, parecía que la descarga terminaba aleatoriamente porque su perro emparejado del Grupo 2 estaba causando que se detuviera. Así, para los perros del Grupo 3, la descarga era “ineludible.”

En la Parte 2 del experimento, los mismos tres grupos de perros fueron testeados en un aparato de caja de lanzadera (una cámara que contiene dos compartimentos rectangulares divididos por una barrera de unos pocos centímetros de altura). Los perros podían escapar de las descargas en un lado de la caja saltando sobre una partición baja hacia el otro. Los perros de los Grupos 1 y 2 aprendieron rápidamente esta tarea y escaparon de la descarga. La mayoría de los perros del Grupo 3, que previamente habían “aprendido” que nada de lo que hicieran afectaba las descargas, se tumbaban pasivamente y gemían cuando recibían descargas.

Aunque este experimento fue demostrado con diferentes tipos de animales, también aplica a las personas. Esto es visible en niños cuando integran fracaso temprano para pedir ayuda, frustración, rendirse, poca motivación y procrastinación. Y estos puntos continúan mientras las personas envejecen.

Porque, si “no puedes hacer nada”, ¿para qué intentarlo siquiera?

Todo esto lleva a ansiedad y depresión, y las personas piensan que nada se puede hacer sobre sus situaciones y sentimientos actuales.

Optimismo aprendido #

El antídoto para la indefensión aprendida es el optimismo aprendido. Estas personas son más exitosas, tienen mejor salud general y niveles más bajos de depresión.

¿Cómo lo practicas? #

Permanencia: los eventos malos o fracasos no son permanentes. Así, puedes recuperarte más rápido que las personas atrapadas en estas situaciones. Sin embargo, las cosas buenas o eventos suceden por una buena razón en la que has trabajado.
Omnipresencia: no generalices el fracaso. Fracasar en un área de tu vida no debería afectar otras áreas.
Personalización: los eventos malos son externos para culpar, fuera de ti mismo, ya que hiciste todo lo que pudiste haber hecho.

Aísla el problema y no lo extrapoles a otras áreas. Deja de generalizar el fracaso.

English #

Español #

¿Siempre Has Sido Así?

2023-03-16T00:00:00+00:00

Me han hecho esta pregunta varias veces últimamente. Es un buen tema para compartir.

“¿Siempre has sido así? ¿Constantemente leyendo libros, escribiendo posts de blog, speaker público en conferencias y meet-ups, aprendiendo en tu tiempo libre, etc…?”

La respuesta corta es: no, y déjame contarte cómo terminé en esta situación.

Solía ser introvertido #

Era introvertido, pero con trabajo y esfuerzo logré dominar algunas habilidades de hablar en público.

Compartir conocimiento es difícil porque primero hay que tenerlo.

Antes no me gustaba leer. Siempre preferí otras fuentes para aprender cosas nuevas. De todas, leer era la más aburrida.

Leer es difícil porque requiere toda tu atención.

Lo que siempre he disfrutado es escribir, desde niño. Por circunstancias personales, escribir era mi forma de expresarme y reflexionar, haciendo retrospectivas de las ideas en mi cabeza.

Escribir al rescate #

Combinando “compartir conocimiento” y “leer” de y para mí mismo.

Escribir era (y sigue siendo) una forma de ordenar mis pensamientos, especialmente en tiempos difíciles. Era una forma de escapar del mundo. Me ayudó a entenderme mejor al día siguiente. Y funcionó.

Conocer tus limitaciones ayuda a entender tu realidad y luchar contra ella. La vida es demasiado corta para aceptar lo que “está ahí” si no estás satisfecho, especialmente si tienes razones para cambiarlo.

Aprendí que no quiero desperdiciar mi tiempo en una vida de la que me arrepienta al morir. Por eso empecé a buscar oportunidades de crecimiento en todo lo que hago.

¿Siempre seré así? #

“¿Estás todo el tiempo al 100% aprendiendo y siendo productivo?”

No puedes ser 100% productivo todo el tiempo. Eso es imposible por nuestra naturaleza humana. La vida tiene constantes “subidas y bajadas”, y eso es parte de su belleza. Tu responsabilidad es entenderte de verdad: tus emociones y tu persona.

Estas preguntas pueden ayudarte a mantener el foco mientras te construyes. Al hacerlas, intenta verlo desde fuera, de forma racional. Deja a un lado las emociones.

¿Quién eres “tú”?
¿Qué te diferencia de otras personas?
¿Qué diferencia al “tú de hoy” del “tú de hace un año”?
¿Cómo será tu “tú” en un año?

Dentro de tu contexto y posibilidades, eres lo que eliges ser. Y eso te diferencia de tu pasado y tu futuro. Tus acciones, cómo te comunicas e interactúas con otros, las decisiones que tomas… todo eso te diferencia de ti mismo en otro momento.

Por eso disfruto leer (o escuchar) un libro al mes. Por eso disfruto aprender en cualquier momento. Por eso me gusta compartir lo que sé con otros. Esto es lo que elijo ser.

Hace unos años escribí sobre el proceso en sí mismo como objetivo: “La repetición es la clave. Facilita hacer lo que quieres hacer. Dificulta hacer lo que quieres dejar de hacer. Disfruta el proceso: ese es el objetivo.”

¿Cuánto tiempo tengo? #

Me gusta demostrarme que estoy equivocado y desafiar el statu quo. Por ejemplo, el año pasado investigué cómo ser speaker en una conferencia internacional. El paso más difícil siempre es el primero; una vez que estás ahí, es más divertido de lo que pensabas. Podría escribir un post sobre “hablar en público”. Por ahora, puedes ver algunos consejos que escribí sobre mejorar tus charlas públicas.

Sobre leer: necesito unas 4-6 horas de media para terminar un libro. Un día laboral se divide en 3 bloques de 8h: 8 dormir, 8 trabajo, 8 ocio (u obligaciones). No trabajo el fin de semana, así que esos días son 16h de ocio/obligaciones. Trabajando 5 días por semana, eso significa 5 días x 8 horas + 2 días x 16 horas = 72 horas de ocio/obligaciones por semana.

El tiempo no es el problema #

En un mes tengo 72 horas x 4 semanas = 288 horas de ocio/obligaciones para estar con mi novia, hablar con mi familia, tocar música, salir o relajarme con amigos, ir al gimnasio, pasear por un parque, viajar… Pero también ir al supermercado, fregar los platos, preparar cenas, limpiar el apartamento, ir al trabajo… Todo requiere tiempo.

El problema no es el tiempo sino las prioridades. En un mes puedo hacer muchas cosas. Lo que suelo encontrar es falta de claridad sobre qué quiero lograr a medio-largo plazo.

Hay más libros, pero El poder de los hábitos y Hábitos atómicos son los que más me han impactado. Pueden ayudarte si luchas con hábitos que quieres cambiar. Todo empieza por entenderte a ti mismo en tu contexto.

No espero que las cosas cambien de un día para otro. Disfruto experimentando, combinando hábitos y probando enfoques diferentes para mejorar con el tiempo. Perder el miedo al fracaso y buscar mejora continua es una mentalidad que cambia la vida.

Lo que me mantiene en movimiento es el tiempo que me queda y pensar: “¿Qué me habría gustado haber cambiado?” Y si es así, “¿Por qué no lo hice?”

Diferentes Creencias sobre la Calidad del Software

2022-10-08T00:00:00+00:00

Hace poco recibí una pregunta en Twitter que me hizo pensar bastante. Decidí compartir mis reflexiones al respecto.

El tweet que empezó esto #

Primero, algo de contexto: me siento muy bien porque el código base donde trabajo mejora cada vez más, así que tuiteé esto:

“A medida que el software mejora con el tiempo, puedes sentir que lo estás haciendo bien.”

Y entonces recibí una pregunta pidiendo sugerencias:

Así que aquí vamos…

Mi respuesta #

Crear acuerdos #

Lo primero es crear acuerdos sobre qué significa software de calidad para tu equipo y para ti. Esto aclara qué cultura de software quieres construir. Dejar tu empresa debería ser el último recurso.

Antes de pensar en irte, pregúntate:

¿Por qué crees que no puedes mejorar el código base de tu empresa?
¿Qué puedes hacer para reducir la fricción entre tus diferentes creencias sobre calidad?

No existe un código base perfecto. El software es una entidad viva que cambia constantemente. Para mí, software de calidad es el que puede adaptarse al cambio con facilidad.

Una vez que acordéis ese objetivo, hay muchas formas de lograrlo. Mi favorita es mantener una mentalidad agile con dosis de valores, principios y prácticas de Extreme Programming.

El software es sobre personas #

El software no es solo escribir código limpio y sólido. Eso es deseable, claro, pero primero hay que entender por qué lo queremos. El “por qué” se basa en los valores del equipo.

Si no compartís el mismo propósito, el mismo “por qué”, no disfrutaréis trabajando juntos. En ese caso, buscar otra empresa que comparta tus valores es una opción. Pero antes, intenta arreglar el problema de raíz y ayuda a tu equipo a mejorar.

Entendiendo tu por qué #

Primero necesitas entender tu “por qué” a fondo para transmitirlo a tus compañeros. ¿Has hecho todo lo posible para comunicar tu “por qué”?

Algunas ideas: fomentar la programación colaborativa (pair/mob), dar charlas técnicas internas, crear una cultura de compartir conocimiento a diario, cuestionar el statu quo y buscar oportunidades de mejora en todas partes.

Tu trayectoria profesional #

Si después de varios meses intentando estas ideas de verdad ninguna funciona, busca una empresa que comparta tus creencias. Al fin y al cabo, tú eres el principal responsable de tu carrera profesional.

Hilo de twitter original.

Pensamientos adicionales #

Si quieres que algo sea diferente, no esperes a que cambie solo. Intenta cambiarlo; si no funciona, déjalo. Quizás no es tu sitio.

Eso sí, reflexiona si ves este patrón repetirse a menudo (cambiar de empresa demasiado rápido). Si es así, quizás el problema no son las empresas sino tú.

El desarrollo de software no es solo código, es negocio. Hay que encontrar un equilibrio justo entre velocidad, costes y calidad según la situación. A veces conviene asumir algo de deuda técnica para llegar antes al mercado.

Ningún equipo debería tener “baja calidad” como parte de su identidad. Cada equipo tiene expectativas de calidad. La clave está en acordar qué es buena calidad.

El Camino a la Seniority en Software

2022-06-08T00:00:00+00:00

Todos hemos sido desarrolladores junior en algún momento. Esto es fácil de saber porque es al principio de tu carrera. Tus responsabilidades fueron delimitadas por otros compañeros que cuidaban de ti.

En algún momento, después de meses o años, conseguiste tu promoción u otro trabajo, donde ya no eras junior, sino intermedio.

Un intermedio (también conocido como middle) es algo entre junior y senior. Ahora sabes que ya no eres junior, sabes cómo entregar valor pero aún tienes sentimientos encontrados sobre la seniority. Quieres ser senior, pero no sabes cómo. No hay un camino claro para alcanzar este objetivo.

Espera un segundo… ¡en realidad hay dos formas fáciles de conseguir el título de senior! Puedes ser promovido como tal en tu empresa, o puedes empezar una nueva posición como “senior” en otra empresa, ¿fácil no?

Marketing y política #

Desafortunadamente, el nivel de “seniority” está muy contaminado por marketing y política. Primero, ¿qué significa “senior” en este contexto? En todas las empresas donde he trabajado (si no todas) siempre he estado rodeado de personas que afirmaban ser “seniors” cuando en realidad solo a unos pocos los consideraría como tales.

La etiqueta de senior está inflada por la necesidad de las empresas de tener expertos en papel más que en la realidad, y es un problema con el que debemos lidiar y del que debemos hablar.

Seniority generalmente significa más experiencia, pero ¿cómo calculas esto? Es fácil desde el punto de vista de una empresa: más años en la industria. Pero, ¿es realmente relevante el número de años que has estado trabajando en una industria que está en constante cambio y evolución? En realidad, esto no sería un gran problema si tienes los fundamentos del software bien interiorizados, pero curiosamente, he visto estos fundamentos solo en ~10% de los seniors que he conocido a lo largo de muchos años y varias empresas.

El hecho de que hayas estado trabajando durante 10 o más años no significa necesariamente que seas un “senior” con el software. ¿Qué más podemos medir para identificar si realmente mereces este título?

No todo se trata del dinero #

Seamos honestos, los títulos senior están mejor pagados que las posiciones junior o middle. Si tienes la oportunidad de conseguir un salario más alto porque tienes “senior” en tu título de trabajo, bueno, no sería inteligente rechazarlo. Pero, independientemente de la política y el marketing, debemos abordar algunos fundamentos de seniority para entender mejor qué significa la palabra “senior” en este contexto.

No todo se trata del dinero, sino también de las responsabilidades que vienen con la seniority.

Fundamentos de la seniority #

Ser senior en nuestra industria del software no se trata del “número de años de experiencia” sino:

¿Qué tan bien transmites tu conocimiento a otros? Compartir lo que sabes es una tarea esencial para una persona senior.
¿Qué tan bien colaboras con otras personas, incluyendo al PM/PO y a otros equipos? La colaboración es crucial para crear un bucle de retroalimentación constante.
¿Qué tan bien trabajas en conjunto con tus compañeros? El pair-programming fomenta la cohesión del equipo y ayuda a que todos mejoren.
¿Qué tan fuertes son tus habilidades de testing? El testing está ligado a la calidad de tu trabajo, y un senior debería apuntar a un diseño incremental.
¿Qué tan bien entiendes entregar valor constantemente en pequeñas partes? Cuanto antes entregues valor, antes obtendrás retroalimentación sobre ello.
¿Qué tan profundo es tu conocimiento técnico sobre software de calidad y los trade-offs para llegar allí? Principios SOLID, código limpio, TDD, refactoring como parte de tu trabajo diario, bajo acoplamiento, alta cohesión, estructuras de datos apropiadas y elegir la solución correcta (KISS, YAGNI…).
¿Qué tan bien te adaptas y lidias con el cambio? El cambio es inevitable, así que debemos aprender a gestionarlo, especialmente lo que no podemos controlar.
¿Qué tan desarrollado está tu pensamiento emprendedor? Siempre manteniendo los objetivos de la organización en mente.

Como puedes ver, no hay mención de tecnología concreta o años de experiencia. ¿Por qué? Porque la tecnología es solo un “detalle de implementación”, y la experiencia viene de practicar y la actitud, no de dejar pasar el tiempo.

La actitud es importante #

Tenemos dos personas:

A) una persona que trabaja desde hace 15 años, haciendo relativamente lo mismo cada día, y sin preocuparse por sus propias habilidades. Simplemente hace lo que otros le dicen que haga.

B) una persona que trabaja desde hace 5 años, desafiándose a sí misma cada semana, probando diferentes enfoques al lidiar con problemas, y afilando sus propias habilidades constantemente.

¿Puedes ver la diferencia principal? No, no son los 10 años de diferencia de “experiencia” entre ellos, sino su actitud.

Entendemos erróneamente que un año de experiencia debe venir con aprendizaje y conocimiento, así que tendemos a usar el tiempo como medida de seniority. Pero argumento que el “factor actitud” es igual o incluso más importante. He estado rodeado de muchas personas que se llaman a sí mismas seniors con 3, 6, 10 y más años de “experiencia” pero sin actitud, y podías ver claramente este problema a diario.

Necesitas esta combinación para construirte como un desarrollador verdaderamente senior; tiempo, experiencia, y lo más importante: actitud hacia mejorar tus propias habilidades y las de quienes te rodean.

Por dónde empezar #

La seniority no se concede, se practica. No esperas el título, construyes el comportamiento hasta que el título te alcanza. Empieza pequeño, y empieza ahora:

Enseña lo que sabes. Elige una cosa que entiendas y explícasela a alguien esta semana. Si no puedes explicarla, aún no la dominas.
Busca lo incómodo. Ofrécete para la tarea que te queda algo grande. El crecimiento vive en el borde de lo que ya sabes hacer.
Reflexiona con intención. Después de cada proyecto, pregúntate qué harías diferente. Experiencia sin reflexión es solo repetición.

El camino no es una promoción. Es la decisión diaria de mejorarte a ti mismo y a quienes te rodean. Hazlo el tiempo suficiente, y el título se vuelve un trámite.

Juan Salvador Gaviota

2022-01-08T00:00:00+00:00

Una fábula corta sobre una gaviota que quiere aprender sobre la vida y el vuelo. Una reflexión sobre la autoperfección.

Trama #

Jonathan Livingston Seagull es una gaviota aburrida de las peleas diarias por comida. Le apasiona volar y se esfuerza por aprender todo lo posible. Su negativa a conformarse termina en su expulsión de la bandada. Como marginado, sigue aprendiendo y se vuelve cada vez más satisfecho con sus habilidades mientras lleva una vida pacífica y feliz.

Un día conoce a dos gaviotas que lo llevan a un “plano superior de existencia”. No hay cielo, sino un mundo mejor que se alcanza perfeccionando el conocimiento. Allí conoce a otra gaviota que también ama volar. Descubre que su tenacidad y deseo de aprender lo hacen “prácticamente un pájaro entre un millón”. En ese nuevo lugar, Jonathan se hace amigo de Chiang, la gaviota más sabia. Chiang lo lleva más allá de lo que había aprendido solo y le enseña a moverse instantáneamente a cualquier lugar del universo. El secreto: “empezar sabiendo que ya has llegado”.

Pero Jonathan no está satisfecho con su nueva vida. Regresa a la Tierra para encontrar a otros como él, compartir lo aprendido y difundir su amor por el vuelo. Su misión tiene éxito. Reúne a su alrededor una bandada de gaviotas marginadas por no conformarse. Su primer estudiante, Fletcher Lynd Seagull, acaba convirtiéndose en maestro. Jonathan se va a enseñar a otras bandadas.

Esta novela corta se ha traducido a más de treinta idiomas.

Audiolibro #

Empieza con el porqué

2021-11-28T00:00:00+00:00

¿Por qué algunas personas y organizaciones son más innovadoras, influyentes y rentables que otras? ¿Por qué algunas consiguen mayor lealtad de clientes y empleados? Incluso entre las exitosas, ¿por qué tan pocas pueden repetir su éxito?

La capacidad de inspirar y lograr cosas notables empieza con el POR QUÉ. Quienes empiezan con el POR QUÉ no manipulan, inspiran.

Martin Luther King Jr., Steve Jobs y los hermanos Wright tenían poco en común. Pero todos empezaron con el POR QUÉ. Entendieron que la gente no compra un producto, servicio o idea hasta que entiende el POR QUÉ detrás.

Inspirar y lograr cosas notables empieza con el POR QUÉ.
Cualquier organización puede explicar qué hace. Algunas pueden explicar cómo lo hacen. Muy pocas articulan claramente por qué.
Tu POR QUÉ es tu propósito, causa o creencia.
Todo líder y organización inspiradora, sin importar tamaño o industria, empieza con el POR QUÉ.
Cuando tu POR QUÉ se vuelve borroso, cuesta mantener el crecimiento, la lealtad y la inspiración que impulsaron tu éxito original.

La gente no compra LO QUE haces, compra POR QUÉ lo haces.

Los grandes líderes inspiran a la gente a actuar. Quienes inspiran dan un sentido de propósito o pertenencia que tiene poco que ver con incentivos externos.

Video Resumen #

Cómo ser un Engineering Manager efectivo

2021-06-27T00:00:00+00:00

Una recopilación completa de temas clave para la gestión: 1:1s, evaluaciones de desempeño, contratación, despidos, política laboral y trabajo remoto.

El libro tiene 3 partes: la primera cubre lo que un manager nuevo debería saber; la segunda y tercera profundizan en temas que todo manager debería dominar.

Aunque asentía con los consejos, a veces sentía que era demasiado extenso o entraba en detalles que no me interesaban. Aun así, me alegro de haberlo terminado. Saqué muchos consejos útiles.

Mis aprendizajes de este libro:

Parte 1 - Orientarse #

Capítulo 01: Una nueva aventura #

Consejos prácticos para tu primera semana y cómo detectar señales de desalineación.

Capítulo 02: Gestiónate a ti mismo primero #

Buen recordatorio de que ordenar tus propias cosas es lo primero. Es prerrequisito para ser eficiente como manager.

“Tu calendario es para ti y para los demás. Mantenlo ordenado y con sentido. Te representa. Hacer las reuniones públicas por defecto ayuda a otros a entender cómo agendar tiempo contigo.”

Parte 2 - Trabajar con personas #

Capítulo 03: Comunicarte con humanos #

Mucho terreno sobre cómo comunicarte con otros.
Piénsalo dos veces antes de compartir información.
Sé consistente en tu estilo de comunicación.

“No comuniques cuando quieras, sino cuando necesites.”

Capítulo 04: Uno a uno #

Es su reunión, no la tuya.

“Intenta que hablen el 70% del tiempo. Si quieres resolverles el problema, no lo hagas. Haz otra pregunta y deja que lleguen solos a la conclusión. Es un arte que requiere práctica.”

Capítulo 05: El trabajo adecuado para cada persona #

Motivación y jerarquía de necesidades. Ejemplos prácticos de cómo desarrollar habilidades.

“Como manager, puedes trabajar con ellos para situar sus metas de carrera en la base de su árbol de habilidades. Luego planificar hitos intermedios con progreso medible, empujando la frontera de su zona de desarrollo cada vez más lejos.”

Capítulo 06: Evaluaciones de desempeño #

Prepáralas con antelación. Recoge feedback de compañeros, por ejemplo por email.

Capítulo 07: Contratación #

No siempre necesitas al candidato más senior.
El encaje cultural importa.
Cómo montar un proceso de entrevistas.

Capítulo 08: Rotación #

Que la gente se vaya es normal.
Renuncias voluntarias:
- “Buenas razones”: no podrías haber hecho mucho.
- “Malas razones”: podrías haber detectado y abordado cosas antes (conflictos, falta de reto, salario).

“Estás condenado al fracaso si crees que vas a retener a todos indefinidamente. […] No luches por retener a alguien si no puedes ofrecer las condiciones para que sea más feliz. Solo retrasarás su partida.”

Capítulo 09: Construir tu red #

Hacer presentaciones, mantenerte en contacto.
Coaching y mentoría.

Parte 3 - El panorama general #

Capítulo 10: Las personas son difíciles #

No te centres en trabajar más duro o más rápido. Crea las condiciones para que tu equipo sea feliz y productivo: autonomía, maestría y propósito.

“En niveles senior, cuando las cosas van mal, te señalarán a ti. Eres el responsable aunque no sea tu culpa.”

Capítulo 11: Los proyectos son difíciles #

“El ojo de Sauron”: trabajar en proyectos de alto riesgo.
Todo se ralentiza cuando el equipo crece. Más código legacy, más problemas.
Equilibrio entre alcance, recursos y tiempo.

“Lidera desde el frente. Da el ejemplo. Pon el trabajo. Los proyectos difíciles pueden definir tu carrera. Adueñátelos y estate ahí.”

Capítulo 12: La bolsa de información #

Espías y guardianes.

“Como manager, deberás decidir constantemente cuánto compartes y cuándo.”

Política laboral.

“Tu red de compañeros te permite saber cómo el resto del negocio percibe tus iniciativas y prioridades.”

Capítulo 13: Soltar el control #

Elimina distracciones y recarga fuera del trabajo.
Dedica el 10% de tu semana a no hacer nada y dejar que tus pensamientos fluyan.

“Suelta los resultados que no puedes controlar. Haz lo mejor que puedas y fomenta lo mismo en tu equipo. Los resultados impredecibles son normales. El fracaso es aceptable. Si haces lo mejor que puedes, no tienes de qué preocuparte.”

Capítulo 14: Buen mantenimiento #

Convierte problemas en oportunidades de aprendizaje.
Mejora la comunicación del equipo.

Capítulo 15: Escaleras duales #

Diseñar trayectorias de Contribuidor Individual y Manager es vital para una cultura de ingeniería sana.

Capítulo 16: El lugar de trabajo moderno #

Diversidad e inclusión.
Trabajo remoto.
Lidera con el ejemplo: equilibrio vida-trabajo.

Capítulo 17: Startups #

Gestión no es burocracia.
La buena gestión es toque ligero y colaboración continua.

“La experiencia en startups es muy valorada porque implica ser emprendedor, automotivado, colaborativo y rápido aprendiendo. Aunque la startup fracase, tu siguiente trabajo será mejor por ello.”

Capítulo 18: La bola de cristal #

Tu visión de carrera. Mirar atrás, mirar adelante.

“Una parte importante de una vida larga y satisfactoria es el propósito. No se trata de estatus ni de sentirse bien. Se trata de una vida que valga la pena vivir.”

Software de Código Abierto

2021-05-03T00:00:00+00:00

Cada proyecto que publicas se apoya en software de código abierto. Tu framework, tu test runner, tu compilador, la pequeña librería en la que nunca piensas.

Lo usas cada día. La pregunta de verdad es si alguna vez devuelves algo.

Devolver no es caridad. Es una de las formas más rápidas de crecer como desarrollador.

¿Qué es OSS? #

El código abierto no es lo mismo que el software libre. El software libre es una forma de código abierto, pero el código abierto no tiene por qué ser gratis. Dos ejemplos marcan la línea. PHPUnit es código abierto y gratuito. Spryker es código abierto y de pago. Ambos publican su código para que cualquiera lo lea.

OSS es software público, abierto al mundo.

Beneficios #

Dos grupos ganan con el código abierto: las empresas que lo publican, y la gente que contribuye.

Para empresas #

El acceso abierto impulsa la adopción. Cuanto más fácil es conseguir el código, más rápido construye la gente sobre él. La formación y los tutoriales atraen a los que empiezan y hacen crecer el ecosistema. El código suele estar en la vanguardia, porque el software que se queda quieto se vuelve obsoleto. Un proyecto público reúne una comunidad a su alrededor, y los canales públicos hacen fácil unirse a ella.

Y como cualquiera puede leer el código, cualquiera puede comprobar su calidad. Esa confianza no se puede fingir.

Para contribuidores individuales #

Tú eliges en qué trabajas. Practicas habilidades reales sin la presión de una caída en producción. Puedes jugar con las últimas novedades de tu lenguaje, o probar un lenguaje que nunca has tocado.

También afilas las habilidades blandas que sostienen una carrera: escribir con claridad, explicar un cambio, mantener tu postura cuando la gente no está de acuerdo.

El código enseña las habilidades técnicas. Los desacuerdos enseñan el resto.

Contribuyendo a OSS #

Empezando con GitHub #

Empezar es fácil, y tienes dos puertas. Abrir tu propio proyecto, o contribuir a uno que ya existe. Un proyecto personal encaja perfectamente en la primera puerta.

Proyectos personales #

Un proyecto personal es un terreno de juego para crear software real y entrenar habilidades reales. Ponlo en tu perfil público de GitHub y tienes todos los beneficios de contribuir a OSS, más uno: no le respondes a nadie. Tú marcas la hoja de ruta. Tú decides qué construir y cómo. Eres tu propio jefe.

El proyecto está ahí para ti. Tú eres responsable de jugar, explorar y superar tus límites.

Mis proyectos personales #

Activos:

agnostic-ai: escribe agents, skills, rules y hooks de IA una vez, úsalos en cada CLI de IA.
bashdep: un gestor de dependencias sencillo para Bash.
phel-snake: el juego de la serpiente en tu terminal, escrito en Phel.
edifact-parser: un parser para formato de archivo UN/EDIFACT en PHP.
unspent: una librería PHP para contabilidad tipo UTXO con entradas no gastadas.

Inactivos:

create-pr: un script de Bash para abrir un pull request desde tu rama y contexto.

Abandonados:

stock-ticker: recibe una notificación con las noticias de tus Tickers favoritos.
jira-status-notifier: notifica cuando los tickets de JIRA no avanzan.
php-best-practices: lo que consideraba mejores prácticas para desarrollo web (archivado).
php-scaffolding: un scaffolding básico de PHP con Docker (archivado).
knob-mvc: un framework para crear plantillas WordPress (2015/2017).

… y muchos más en github.com/Chemaclass

Mis contribuciones a organizaciones OSS #

Activas:

phel-lang: Phel es un lenguaje de programación funcional que compila a PHP. Es un dialecto de Lisp inspirado en Clojure y Janet. Ya escribí un post sobre esto: Phel: Un Lisp que compila a PHP
gacela-project: Gacela es un framework PHP que te ayuda a mejorar el diseño de tu aplicación dividiendo la lógica en diferentes módulos.

Abandonadas:

nm_template: La plantilla base para NuevaMetal (2013-2016).

Compartir Conocimiento e Impacto #

El código es solo la mitad. La otra mitad es lo que escribes y le entregas a la siguiente persona.

Posts del blog #

… y muchos más en https://chemaclass.com/es/blog/

La belleza del OSS #

Contribuye en público el tiempo suficiente y empiezas a ver tu propio crecimiento. Las correcciones que sigues haciendo. El código que escribiste el año pasado, ya envejecido. Los errores, todos ellos, a la vista. Y por debajo, la prueba lenta de que estás mejorando.

Vas desarrollando un sexto sentido para detectar patrones que ya has visto, los buenos y los dolorosos.

Muestra tus habilidades. Ayuda a la gente a tu alrededor. Eso es trabajar con la puerta del garaje abierta.

El Software de Código Abierto te ofrece una de las mejores oportunidades para empezar a construir una carrera hacia la mejora continua.

Esta es una charla (en español) que hice de forma remota en abril de 2021, para la Comunidad PHPMad Madrid. Presento todas estas ideas junto con una demo en vivo de cómo contribuir a un OSS real.

Abraza el Cambio

2021-03-01T00:00:00+00:00

El libro ¿Quién se ha llevado mi queso? presenta un cuento dentro de la historia principal que consiste en 4 personajes: dos ratones, Sniff y Scurry, y dos pequeñas personas, Hem y Haw.

Se publicó en 1998 y lo leí a principios de 2021. Mejor tarde que nunca. Mi hermano Jesús me lo recomendó.

Viven en un Laberinto (que representa nuestro entorno) y para sobrevivir necesitan salir de su zona de confort y buscar queso (que representa la felicidad y el éxito).

El cuento empieza cuando ambos grupos llegan a la “Estación de Queso C”, llena de queso. Los humanos establecen rutinas; los ratones mantienen sus instintos activos.

Un día los ratones llegan y no queda queso. Salen a buscar más en otro lugar. Hem y Haw, en cambio, se quejan. Hem, enfadado, exige “¿Quién se ha llevado mi queso?!”. Ambos contaban con que el queso sería eterno, así que no estaban preparados. La diferencia clave es cómo reaccionan.

Hem se niega a marcharse de la “Estación de Queso C”. Sigue yendo cada día esperando encontrar queso, cada vez más débil y con miedo de hacer algo diferente. Haw, en cambio, decide reírse de la situación, vence su miedo y sale a buscar más queso.

… Te dejo el resto del cuento para ti.

El cuento es una metáfora de las diferentes actitudes que adoptamos cuando tenemos que enfrentar cambios.

Notar pequeños cambios temprano te ayuda a adaptarte a los cambios más grandes que están por venir.

El libro está lleno de lecciones aplicables a cualquiera, sin importar quién seas o cuándo lo leas. Lo recomiendo.

Mis lecciones favoritas del libro #

El cambio sucede. Siguen moviendo el queso.
Anticipa el cambio. Prepárate para que muevan el queso.
Monitorea el cambio. Huele el queso a menudo para saber cuándo se está poniendo viejo.
Adáptate al cambio rápidamente. Cuanto más rápido sueltes el queso viejo, antes podrás disfrutar del nuevo queso.
Cambia. Muévete con el queso.
Disfruta el cambio. Disfruta el sabor del nuevo queso.
Prepárate para cambiar rápidamente y disfrutarlo de nuevo. Siguen moviendo el queso.

“Todos saben que no todo cambio es bueno o necesario. Pero en un mundo en constante cambio, nos conviene aprender a adaptarnos y disfrutar de algo mejor. No es lo que dice la historia de ‘¿Quién se ha llevado mi queso?’, sino cómo la interpretas y aplicas a tu situación lo que le da valor.” - Ken Blanchard.

“La vida sigue adelante y nosotros también deberíamos” - Spencer Johnson

¿Quién se ha llevado mi queso?

2021-01-16T00:00:00+00:00

El libro cuenta una fábula con cuatro personajes: dos ratones, Fisgón y Escurridizo, y dos personitas, Hem y Haw.

Es una metáfora brillante sobre las diferentes actitudes que adoptamos cuando nos toca enfrentar un cambio.

Mis lecciones favoritas del libro #

El cambio ocurre. Siguen moviendo el queso.
Anticipa el cambio. Prepárate para que el queso se mueva.
Monitorea el cambio. Huele el queso a menudo para saber cuándo se está poniendo viejo.
Adáptate al cambio rápidamente. Cuanto más rápido sueltes el queso viejo, antes podrás disfrutar del queso nuevo.
Cambia. Muévete con el queso.
Disfruta el cambio. Disfruta el sabor del queso nuevo
Prepárate para cambiar rápidamente y disfrutarlo de nuevo. Siguen moviendo el queso.

“Todo el mundo sabe que no todo cambio es bueno o incluso necesario. Pero en un mundo que está cambiando constantemente, es ventajoso para nosotros aprender a adaptarnos y disfrutar de algo mejor. No es lo que hay en la historia de ‘¿Quién se ha llevado mi queso?’ sino cómo lo interpretas y lo aplicas a tu propia situación lo que le da valor.” - Ken Blanchard.

Escribí un artículo sobre este libro: Abraza el cambio

El Proceso en Sí Es la Meta

2020-09-08T00:00:00+00:00

Ninguna meta debería ser un logro en sí misma, sino el proceso que nos ayuda a ir en la dirección de esas metas.

Las metas, en los negocios y en la vida, deberían verse como direcciones. Su intención es ayudarnos a lograr más de la manera que queremos.

Si solo nos recompensan por resultados y no por procesos, nos volveremos miserables.

La sociedad recompensa resultados, no el viaje. Ese es parte del problema cuando te enfocas demasiado en lo que la sociedad espera de ti. Es importante escuchar a la sociedad, pero más importante escucharte a ti mismo para mejorar constantemente. La mejora continua no aplica solo al software sino a todo en la vida.

¿Cómo me mantengo enfocado? #

Es un tema subjetivo. Lo que funciona para uno puede no funcionar para otro. Aun así, creo que puede ser útil compartir lo que me funciona a mí.

Auto-reflexión #

Durante algunos años escribí mis pensamientos en un “diario”. En 2015, cuando me mudé a Alemania, no conocía a mucha gente y todo era nuevo. Decidí escribir mis pensamientos para leerlos al día siguiente y reflexionar sobre ellos. Tres años después, en diciembre de 2017, publiqué “Ojos en un recuerdo”. Es la compilación de esos pensamientos, tal como vinieron. Puedes ver la evolución de los temas y cómo fueron escritos.

El ejercicio de auto-reflexión fue más importante que el libro. La meta no era escribir un libro. Era entender qué pasaba dentro de mí. Publicarlo fue un accidente. Un hermoso accidente. Este hábito de pensar sobre mis acciones y decisiones me ayudó a desarrollar quién soy hoy.

Deportes #

El ejercicio ayuda a mi mente a desconectar de lo técnico. Mantiene mi cuerpo activo usando energía en otro entorno. Pero lo más importante: llego cansado a la cama y descanso mejor. Ya sea deportes de contacto, gimnasio o correr.

El deporte específico es un detalle. Lo importante es hacer deporte.

Libros #

Leo tecnología de día y no-tecnología de noche. Antes o después del trabajo, un libro técnico. Antes de dormir, uno no técnico. Así alimento mi cerebro con conocimiento y le doy espacio para descansar del código y disfrutar otros “universos”.

Algunos libros que me ayudaron a entender cómo nos comportamos y por qué hacemos lo que hacemos:

El poder de los hábitos, de Charles Duhigg.
Hábitos atómicos, de James Clear.
Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo, de Jeff Sutherland.

Trucos personales #

Ojalá hubiera leído mucho más. Con tantas distracciones, mantenerte enfocado es difícil. Algunos trucos que me ayudan:

Teléfono siempre en silencio y vibración.
Antes pasaba horas en redes sociales. Mucho tiempo perdido. Eliminé las apps que me impedían ser productivo. Algunas del teléfono, otras directamente la cuenta.
Antes jugaba videojuegos. Ahora voy a GitHub a trabajar en proyectos personales, contribuir a código abierto, o leer un libro.
Cuando salgo a correr, escucho un podcast que quería escuchar desde la mañana. Vinculé la recompensa del podcast con el acto de correr. Creé ese hábito a propósito.

No se trata de eliminar tus viejos hábitos sino de reemplazarlos por nuevos.

Cómo mejorar tus hábitos #

Los hábitos emergen sin nuestro consentimiento. El cerebro crea bucles de hábito buscando disparadores para ahorrar energía.

La fuerza de voluntad se puede entrenar, como un músculo.
Los pequeños éxitos construyen victorias más grandes.
Enfócate menos en metas y más en sistemas y procesos.
Para cambiar hábitos, cambia cómo te identificas.
Para construir buenos hábitos, el entorno importa más que la motivación.
Para romper un mal hábito, reduce exposición a sus señales.
Combina algo que quieras hacer con algo que necesites hacer.
No busques el hábito perfecto. Solo repite.
Reduce fricción para buenos hábitos, auméntala para los malos.
Como en Scrum, eliminar desperdicio es clave para mejorar.

La repetición es la clave. Facilita lo que quieres hacer. Dificulta lo que quieres dejar de hacer. Disfruta el proceso: esa es la meta.

Enlaces interesantes #

Siete lenguajes en siete semanas

2020-05-21T00:00:00+00:00

El Programador Pragmático recomienda aprender un lenguaje nuevo cada año. Pero si uno por año está bien, ¿por qué no siete en siete semanas?

Este libro te lleva de paseo por Clojure, Haskell, Io, Prolog, Scala, Erlang y Ruby. Aunque tu lenguaje favorito no esté en la lista, vas a ampliar tu forma de pensar al ver estos lenguajes lado a lado. Aprenderás algo valioso de cada uno. Y lo mejor: aprenderás a aprender lenguajes rápido.

Creé este repositorio con todo lo que fui aprendiendo mientras leía y experimentaba con los lenguajes del libro: https://github.com/Chemaclass/7LangIn7Weeks

Cómo Mejorar tu Charla Técnica (o Cualquier Otra Presentación)

2019-11-18T00:00:00+00:00

A todos nos ha pasado estar en reuniones que parecían una pérdida de tiempo, con un “monólogo” difícil de seguir o menos interesante de lo que podría ser. Vamos a arreglar esto.

Por eso estuve pensando en ello e intenté obtener algunas claves para mejorar su calidad general. Se aplica a todas las presentaciones, pero también a las charlas técnicas y otras presentaciones técnicas en las que los ingenieros suelen estar involucrados.

Estructura de la charla #

Para explicar cómo creo que debería ser una buena presentación, abordaré tres temas principales relevantes para estructurar y diseñar tu presentación.

Contenido de la presentación: ¿qué mensaje quieres transmitir, a quién y cómo?
Diseño y maquetación: cómo puedes diseñar una presentación fácil de seguir que apoye tu charla en lugar de desviar la atención de lo que realmente intentas decir.
Por último, creo que la audiencia también es responsable de que una charla técnica sea exitosa, así que añadiré un recordatorio sobre el rol y las responsabilidades de los oyentes.

Considera tu audiencia #

Cuando prepares tu presentación, pregúntate:

¿Quién asiste a la charla?
¿Qué formación tienen?
¿Qué posición ocupan?
¿Qué información es relevante para ellos?
¿Tienen que conocer todas las palabras clave que te gustaría usar?

Introduce el tema #

Crea algo de atmósfera. Intenta responder estas preguntas:

¿Por qué deberían escucharte?
¿Por qué deberían pasar su tiempo en otra reunión?
¿Qué habrán aprendido al final de la charla?
¿Cuál es tu mensaje principal?

Cada reunión debería tener un resultado tangible y un objetivo claro. Tenlo en mente.

Crea una línea argumental #

Al preparar el contenido principal de tu charla, piensa en una línea argumental que conecte tus argumentos. Esto facilita que la audiencia te siga.
Limítate a los mensajes necesarios para explicar tu idea o concepto.
Deja fuera cualquier información innecesaria que no sea relevante para el núcleo de tu mensaje.

Construye una conclusión #

Resume la(s) conclusión(es) principal(es) de forma concisa:

¿Cuál es la conclusión de esta reunión?
¿Cuáles son los aprendizajes de esta reunión?
¿Cuáles son las preguntas abiertas o los siguientes pasos?

Diseño y maquetación #

Escribe menos, habla más #

Una charla técnica trata sobre aprender nuevas ideas y conceptos.
Una presentación debería apoyar tu charla, no reemplazar o replicar lo que has dicho.
Cuantas más palabras en la diapositiva, menos se recordarán.
Usa visuales/gráficos que apoyen tu charla en lugar de texto adicional.

Fuentes grandes #

Si tienes código que presentar, considera:

Si es una imagen: usa fuentes grandes dentro. Recomiendo usar https://carbon.now.sh/ para snippets simples. O simplemente capturas de pantalla de tu IDE favorito.
Si programas en vivo: prepara tu editor de antemano. Usa el Modo Presentación de tu IDE.

Rol de la audiencia #

Responsabilidades del asistente #

Nada de uso innecesario del móvil, como Twitter, Instagram, Facebook, WhatsApp, Telegram, etc.
Guarda tus preguntas para el tiempo de preguntas, a menos que el presentador mencione al principio que puedes preguntar en cualquier momento. Normalmente es mejor no interrumpir el tema, así que podemos hacer las preguntas al final.
Muestra interés en el tema. El presentador ha dedicado tiempo a preparar las diapositivas para ti.
Comparte el entusiasmo del presentador por el tema. Esto también es responsabilidad del presentador: ambos deberíais tener ganas de aprender más sobre el tema.

Preguntas internas #

¿Valió la pena el tiempo que todos pasamos en esta sala?
¿Nos arrepentimos de haber asistido a esta reunión?

Al final de la reunión, deberíamos hacernos estas preguntas para mejorar. Pide opiniones a otras personas para que podamos crecer más y juntos.

Hábitos Atómicos

2019-11-12T00:00:00+00:00

Solemos creer que para cambiar nuestra vida hay que pensar en grande. James Clear propone otra cosa: el cambio real viene del efecto acumulado de cientos de pequeñas decisiones. Las llama hábitos atómicos.

Aprendizajes #

Enfócate más en sistemas y procesos y menos en metas
Cambia cómo te identificas a ti mismo
El entorno es más importante que estar motivado
Para romper un mal hábito, reduce la exposición a las señales que lo causan
Combina una acción que quieres hacer con una acción que necesitas hacer
En lugar de decir “tengo que”, di “puedo”
No intentes hacer un hábito perfecto, solo repítelo
Reduce la fricción para buenos hábitos y aumenta la fricción para malos hábitos
Para que algo no parezca una tarea, hazlo durante períodos cortos de tiempo
Para lograr metas a largo plazo, haz que los pequeños hábitos sean gratificantes
Nunca faltes más de una vez a un hábito

Escribí un artículo sobre este tema: El proceso en sí mismo es la meta

El poder de los hábitos

2017-03-20T00:00:00+00:00

Aprendizajes #

Todos los hábitos operan de la misma manera
Cambiar un hábito significa cambiar un aspecto clave…
…y cambiar un hábito puede cambiar muchas cosas
La fuerza de voluntad es un músculo
Practica, practica, practica

El Programador Pragmático

2016-10-01T00:00:00+00:00

Aprendizajes #

No te repitas.
La mentalidad importa tanto como el conocimiento.
El buen código es más fácil de cambiar que el mal diseño.
Elige buenas herramientas y domínalas.

No Te Repitas (DRY) #

Cada pieza de conocimiento debe tener una única representación clara dentro del sistema.
DRY trata sobre la duplicación de conocimiento, de intención. Es expresar lo mismo en dos lugares, quizás de formas diferentes.

La mentalidad importa tanto como el conocimiento #

Aspectos clave:

Asume la responsabilidad de tu trabajo. Sin excusas ni culpas cuando algo sale mal.
Escribe software “suficientemente bueno”. No pierdas tiempo perfeccionando lo que ya funciona para el producto.
No ignores la deuda técnica. Los autores usan la analogía de las ventanas rotas:

No dejes “ventanas rotas” (malos diseños, decisiones incorrectas o código pobre) sin reparar. Arregla cada una cuando la descubras. Si no hay tiempo, al menos tápalas. Comenta el código problemático, muestra un mensaje de “No Implementado” o usa datos ficticios temporalmente.

El Programador Limpio

2016-08-01T00:00:00+00:00

Los programadores que triunfan bajo presión e incertidumbre comparten algo: les importa de verdad crear buen software. Lo tratan como un oficio. Son profesionales.

Aprenderás #

Qué significa ser un verdadero artesano del software
Cómo lidiar con conflictos, plazos ajustados y jefes difíciles
Cómo entrar en flujo y superar el bloqueo
Cómo manejar la presión y evitar el agotamiento
Cómo combinar actitudes clásicas con nuevos paradigmas de desarrollo
Cómo gestionar tu tiempo y evitar atascos
Cómo crear entornos donde los programadores y equipos prosperen
Cuándo decir No y cómo hacerlo
Cuándo decir Sí y qué implica realmente

Resumen #

Capítulo 1: Profesionalismo #

Ser profesional significa asumir responsabilidad total de tus acciones.
Primera regla: no dañes ni la función ni la estructura del software.
Siempre cometerás errores, pero aprende de cada uno.
Confía en el código que liberas. Espera que QA no encuentre nada.
- Prueba una y otra vez.
- Automatiza tus tests.
- Diseña el código para que sea fácil de probar.
Sigue la regla del Boy Scout: deja el código un poco más limpio de como lo encontraste.
Tu carrera es tu responsabilidad, no la de tu jefe.
- Dedica 20 horas semanales extra a mejorar tus habilidades.
- Lee, experimenta, practica (katas), habla con otros, colabora, mentoriza.
- Que sea divertido.
Conoce tu dominio e identifícate con tu cliente (nunca “nosotros vs. ellos”).

Capítulo 2: Decir No #

Los profesionales tienen el coraje de decir no a sus jefes.
Managers y desarrolladores a menudo chocan porque sus objetivos a corto plazo entran en conflicto.
Cuanto mayor el riesgo, más valioso es un “no” y más difícil de decir.
Los buenos equipos trabajan hacia un sí, pero solo un sí correcto que funcione en la práctica.

Capítulo 3: Decir Sí #

Hay tres partes para hacer un compromiso:
- Dices que lo harás
- Lo dices en serio
- Realmente lo haces
Tu compromiso debe respetar los límites de lo que esperas (basado en tu experiencia) poder y no poder hacer.
- Si reconoces que probablemente no podrás cumplir un compromiso, necesitas levantar una bandera roja inmediatamente.

Capítulo 4: Codificación #

Programar requiere un nivel de concentración que pocas disciplinas exigen.
“La zona” (o flujo) no es tan buena como parece: serás productivo localmente, pero puedes perder la visión global y producir diseños mediocres.
Las interrupciones son malas distracciones.
- El pair programming ayuda a gestionarlas.
- TDD hace que el contexto pre-interrupción sea reproducible.
  - Minimiza el tiempo de depuración.
Programar es una maratón, no un sprint. Conserva energía y creatividad.
Vete cuando sea hora, aunque estés en medio de algo importante.
Reestima continuamente tu tiempo de finalización y avisa en cuanto veas que llegarás tarde.
- No dejes que nadie te meta prisa.
- Define bien qué significa “terminado”, con requisitos de calidad altos.
Programar es difícil para todos. Pide ayuda y ofrécela, especialmente como mentor.
- No tengas vergüenza de preguntar.

Capítulo 5: Test-Driven Development #

TDD no es una cura milagrosa y es impráctico o inapropiado en algunos casos (raros).
Ciclo TDD:
1. Añade un test
2. Ejecuta todos los tests. El nuevo test debería fallar por razones esperadas
3. Escribe el código más simple que pase el nuevo test
4. Todos los tests deberían pasar ahora
5. Refactoriza según sea necesario
6. Repite

Capítulo 6: Practicar #

Una Kata de programación es un conjunto preciso de pulsaciones de teclas y movimientos de ratón coreografiados que simula la resolución de algún problema de programación.
- Una Kata es sobre el proceso, no la solución.
- No estás resolviendo el problema porque ya conoces la solución.

Capítulo 7: Tests de Aceptación #

Evita “basura entra, basura sale”. Asegúrate de entender los requisitos.
- Entenderlos bien significa eliminar ambigüedad.
La mejor forma es definir tests de aceptación:
- Los tests automatizados verifican que el software cumple las condiciones del cliente.
- Pasar esos tests define “Terminado”.
Empieza a implementar solo cuando los tests estén definidos.
Los tests unitarios son para programadores. Los tests de aceptación son para negocio y desarrolladores.
Ejecuta todos los tests en integración continua y arregla los fallos de inmediato.

Capítulo 8: Estrategias de Testing #

QA es parte del equipo. Escriben tests de aceptación, casos de fallo, casos límite y hacen testing exploratorio.
Pirámide de testing:
- La mayoría son tests unitarios: por y para desarrolladores.
- Muchos son tests de componentes o integración: por QA/Negocio con ayuda de desarrolladores, para ambos.

Capítulo 9: Gestión del tiempo #

En desarrollo de software, gestionar bien el tiempo es esencial.
Las reuniones son necesarias pero a menudo una pérdida de tiempo. Evita las que no aporten valor claro: es una obligación profesional.
Las reuniones deben tener agenda y objetivo claro.
- Las dailies ágiles son un formato eficiente.
- La planificación de iteración debería ocupar el 5% de la iteración.
La concentración es un recurso escaso.
- Úsala cuando la tengas y recarga con tareas simples y descansos.
- Para mejorarla:
  - Haz deporte.
  - Busca estímulos creativos.
  - Toma descansos cortos cada 45 minutos.

Capítulo 10: Estimación #

Las estimaciones son la mayor fuente de desconfianza entre negocio y desarrolladores. Los desarrolladores dan estimaciones que negocio trata como compromisos.
- Ambos olvidan que una estimación es una distribución de probabilidad, no un número fijo.

Capítulo 11: Presión #

El profesional mantiene la calma bajo presión. Sigue sus disciplinas porque sabe que es la mejor forma de cumplir plazos.
Evita situaciones de presión:
- Haz solo compromisos que puedas cumplir.
- Mantén tu código limpio.
- Trabaja de forma que no necesites cambiar de método en crisis.
No entres en pánico. Habla con tu equipo. No te aceleres. Confía en tus disciplinas.
Ofrece hacer pairing a compañeros en crisis.

Capítulo 12: Colaboración #

A la mayoría de programadores les gusta trabajar solos. Pero hay que entender los objetivos de quienes nos rodean, incluido negocio.
- Eso requiere comunicación.
Dentro del equipo: solo la propiedad colectiva del código y el pairing producen buena comunicación.
- Programar es comunicarse.

Capítulo 13: Equipos y proyectos #

Los equipos necesitan meses para consolidarse, conocerse y aprender a trabajar juntos.
- Asignar personas a varios proyectos a la vez es mala idea. Romper un buen equipo también.
- Mejor asignar varios proyectos a un mismo equipo.

Capítulo 14: Mentoría, aprendizaje y artesanía #

Los programadores jóvenes necesitan mentoría, ya sea implícita o explícita.
El software controla todos los aspectos de nuestras vidas. Un período de entrenamiento y práctica supervisada es más que apropiado.

En esta lección, Uncle Bob explica por qué es necesario escribir código limpio y establece las bases para lograrlo, tanto sociales como técnicas. El futuro de la programación se basa en un código ético y bien educado.

En esta segunda lección, Uncle Bob habla del propósito de los comentarios. Rompe la idea de que comentar es algo que “hay que hacer” por ser supuestamente buena práctica. Para él, escribir un comentario es señal de fracaso: el buen código se explica solo. Menos comentarios = mejor código.

En esta tercera lección, Uncle Bob quiere crear conciencia sobre la necesidad de elevar el criterio al producir código. Señala la falta de preparación de muchos programadores como una de las principales causas de la ineficiencia en el desarrollo de software actual.

En esta cuarta lección, Uncle Bob introduce el Test-Driven Development (TDD). Es una práctica con curva de aprendizaje larga, pero produce código más robusto, seguro, mantenible y desarrollado con mayor eficiencia.

97 cosas que todo programador debería saber

2016-07-15T00:00:00+00:00

97 consejos cortos y útiles para programadores. Da igual qué lenguaje uses: aquí encontrarás nuevos enfoques para viejos problemas, buenas prácticas y consejos de expertos para mejorar tu oficio.

Mis principales aprendizajes #

01.- Paga la deuda técnica lo antes posible.

02.- Aprende y domina la programación funcional.

Hace tu código menos propenso a errores y más fácil de depurar.

03.- No adivines lo que haría un usuario; haz que los usuarios hagan cosas y obsérvalos.

04.- Automatiza los estándares de código.

05.- Escribe código simple, nombres descriptivos simples, relaciones simples.

06.- Antes de refactorizar: considera los tests existentes y el código.

Trabaja en incrementos, asegúrate de que los tests sigan pasando después de cada cambio.

08.- Siempre deja el código más limpio de lo que lo encontraste, incluso si no lo escribiste.

10.- Elige tus librerías/frameworks cuidadosamente para evitar complejidad innecesaria.

11.- Haz tu código fácil de entender usando términos del dominio.

13.- El formato del código también es importante.

14.- Usa revisiones de código enfocándote en compartir conocimiento entre miembros del equipo.

15.- Objetos inmutables siempre que sea relevante. Cada variable debería tener el menor alcance posible. Nunca incluyas más de cuatro argumentos de función.

18.- Toma responsabilidad de tu propia educación. Nunca dejes de aprender.

Basta con dedicar un poco de tiempo cada semana: podcasts, cursos, libros…

19.- Al diseñar una API, apunta a hacerla fácil de usar, no conveniente de codificar.

20.- Despliega temprano y frecuentemente. No lo dejes hasta el final del proyecto.

22.- Mejorar tus habilidades debería ser algo diario.

23.- Adapta el nivel técnico de tu lenguaje específico del dominio a tu audiencia.

24.- No tengas miedo de romper cosas si eso es lo necesario para arreglar cosas.

25.- Ten cuidado con tus datos de prueba porque podrían hacerse públicos accidentalmente.

26.- Maneja tus errores cuando aparecen, no lo dejes para después.

27.- Aprende diferentes lenguajes de programación.

Aprende su propia “cultura” o forma de hacer las cosas.
Definitivamente te hará un mejor programador.

28.- No solo captures tus errores, realmente manéjalos.

29.- Entiende al menos algunas complejidades de tu negocio, no solo programación.

30.- DRY: No Te Repitas.

32.- Encapsula comportamiento, no solo estado.

33.- Los números de punto flotante inevitablemente pueden crear errores en los cálculos.

34.- El código abierto es una gran oportunidad para hacer trabajo interesante y desarrollar habilidades de programación.

36.- Da el contexto adecuado cuando pidas ayuda, porque la gente no puede adivinar lo que está pasando.

37.- No se trata de echar muchas horas. Aprende a trabajar con eficacia.

Dedica tiempo a aprender y a pensar en lo que haces.

38.- Escribe reportes de bugs apropiados:

Precisamente cómo reproducir el bug,
con qué frecuencia aparece,
qué debería haber pasado,
qué realmente pasó.

39.- No escribas código innecesario.

Solo escribe código que añada valor y se necesite ahora mismo.
Elimina código muerto.

41.- La causa principal de lentitud en aplicaciones suele ser el exceso de llamadas remotas entre procesos, no el algoritmo.

Por ejemplo, conexiones a base de datos.

42.- Si aparece una advertencia del compilador, arréglala.

No lo dejes para después, aunque no vaya a ser problema en producción.
“Compilador” incluye cualquier análisis estático en lenguajes no compilados.

43.- Aprender a usar herramientas de línea de comandos es una experiencia educativa valiosa, y podrías terminar prefiriéndolas.

44.- Aprende (al menos) dos lenguajes y paradigmas diferentes bien.

45.- Invierte algo de tiempo para dominar el IDE que usas.

Te hará la vida más fácil y te ahorrará tiempo a largo plazo.

46.- Conoce y trabaja con tus limitaciones: presupuesto, recursos, tiempo, etc.

47.- Trabaja en tareas pequeñas. No tengas miedo de descartar cambios.

El conocimiento adquirido no se pierde.
Ten claro qué quieres lograr antes de empezar.

48.- Usa una BD relacional si tu aplicación va a manejar un conjunto grande, persistente e interconectado de datos.

49.- Aprende a comunicar bien: no solo con tu máquina, también con negocio. Y quizás otro idioma.

Es bueno para las conexiones y para la vida.

54.- Piensa dos veces antes de implementar “soluciones temporales”.

55.- Haz la GUI fácil de usar bien y difícil de usar mal.

Anticipa errores y busca cómo prevenirlos.
Se trata de la experiencia del usuario, no de la tuya.

56.- En proyectos, encuentra formas de hacer lo invisible visible.

57.- El paso de mensajes lleva a mejor escalabilidad en sistemas paralelos.

58.- Escribe código que otras personas puedan entender fácilmente.

59.- El polimorfismo reduce la necesidad de if/else, lo que produce código más corto y seguro.

60.- QA es tu amigo, no tu enemigo.

61.- Versiona tus releases.

62.- Asegúrate de que tu código fuente indique claramente lo que el programa está haciendo.

63.- Aprende sobre el proceso de build. Es una parte importante del desarrollo.

64.- Practica pair programming.

65.- Prefiere tipos específicos del dominio sobre tipos primitivos.

Hacen el código más legible y menos propenso a errores en el desarrollo.

67.- Un profesional toma responsabilidad personal por su carrera y su código.

68.- Usa control de versiones.

69.- A veces la mejor forma de resolver un problema es alejarte del ordenador y dejar que la solución aparezca mágicamente en tu mente.

70.- Leer código es una buena forma de aprender. El código de otras personas o tu código antiguo.

72.- Reinventar la rueda es una gran forma de desarrollar tus habilidades.

75.- Si el código que escribiste es verdaderamente horrible, no intentes arreglarlo. Bórralo y empieza de nuevo.

76.- Aplica el Principio de Responsabilidad Única (SRP).

77.- Si alguien pide un cambio de producto, no lo descartes aunque no estés de acuerdo. Pregunta por qué.

Llegarás a conversaciones más productivas y mejores resultados.

78.- Si estás haciendo lo mismo una y otra vez, intenta encontrar una forma de automatizarlo.

79.- Aprovecha las herramientas de análisis de código.

80.- Escribe tests basados en la funcionalidad deseada de tu programa, no en comportamiento incidental.

83.- El testing toma tiempo, pero asegura la calidad del producto final. Hazlo.

85.- Hay muchos beneficios en el trabajo colaborativo y pair programming.

86.- A veces arreglar un error en el código lleva a descubrir un error oculto.

87.- Escribe código pensando en otros programadores.

88.- Aprende a usar herramientas Unix. Aprende a usar el terminal.

89.- Usa el algoritmo y estructura de datos correctos para el trabajo.

Para hacer eso, necesitas entenderlos bien.

90.- Ten una buena política de logging.

91.- Usar el principio DRY te ayuda a identificar y reparar cuellos de botella de rendimiento.

92.- Testers y programadores deberían colaborar.

93.- Escribe código como si tuvieras que mantenerlo el resto de tu vida.

94.- Intenta escribir funciones “pequeñas”.

Los buenos tests actúan como documentación para el código que prueban.

Describen cómo funciona el código.

Para ser un buen programador, tienes que preocuparte por la calidad del código.

97.- Habla con tus clientes antes de asumir que entiendes lo que quieren. De verdad.