Chemaclass

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.

Skills por Encima de Agents

2026-05-19T00:00:00+00:00

La gente compara agentes de código. Claude Code, Codex, Gemini CLI. Cuál es más listo, más rápido, más barato. Los benchmarks salen nuevos cada mes.

Pregunta equivocada.

Tras un año metiendo agentes en proyectos reales, lo que más cambió las cosas no fue el agente. Fueron los skills que le escribí.

Los agentes son un commodity

Todo agente de código tiene la misma forma. Un modelo de lenguaje, un runtime, acceso al filesystem. Leer, razonar, escribir. Generalista por diseño.

Dos equipos usan el mismo agente. Uno entrega código limpio y testado. El otro entrega basura que parece buena. Mismo modelo. Distinta enseñanza.

El modelo es el motor. Los skills son el mapa. Sin mapa, con un motor potente te pierdes antes.

Inteligencia no es experiencia

¿Quién lleva tus impuestos? ¿Un genio con 300 de IQ que nunca leyó una ley fiscal, o un asesor con 20 años presentando declaraciones?

El asesor sabe qué deducciones aplican, qué declaraciones necesita tu negocio, qué errores te marcan. No es inteligencia. Es experiencia.

Los agentes de IA tienen el mismo hueco. Un modelo razona sobre código y escribe soluciones. No conoce tus capas hexagonales. No sabe que las entidades de dominio nunca deben importar código de framework. No sabe que cada feature empieza con un test que falla.

Los skills cierran ese hueco.

Los skills cargan contexto bajo demanda

Un skill es un fichero markdown en .claude/skills/. Un procedimiento, un patrón, un trozo de conocimiento del dominio. Markdown con frontmatter.

La clave está en cómo se cargan. El agente lee solo nombres y descripciones al arrancar. Carga el skill entero cuando la tarea encaja. Sigue los enlaces a las referencias solo cuando necesita profundizar.

Esa carga bajo demanda es lo que hace que los skills escalen. Veinte skills casi no cuestan hasta que uno encaja con la tarea. Los agentes especializados, en cambio, cargan sus instrucciones enteras cada vez que arrancan. Más agentes, más coste fijo.

.claude/skills/
 code-review/
 SKILL.md # instrucciones principales
 reference/
 solid-checklist.md # ejemplos SOLID detallados
 test-patterns.md # guías de calidad de tests

El SKILL.md:

---
description: "Revisar cambios de código por violaciones de SOLID, calidad de tests y alineación de arquitectura"
allowed-tools: Read, Grep, Glob
argument-hint: "[fichero o PR]"
---

# Code Review

Revisa cambios de código contra las convenciones del proyecto.

## Pasos

1. Leer el diff o los ficheros indicados
2. Revisar arquitectura: la capa de dominio no importa framework, la infraestructura se mantiene delgada
3. Revisar principios SOLID (ver reference/solid-checklist.md para patrones)
4. Revisar calidad de tests: los tests verifican comportamiento, no detalles de implementación
5. Señalar problemas con el principio concreto violado y una propuesta de fix

## Output

Para cada issue encontrado:
- Fichero y línea
- Qué está mal (qué principio o convención)
- Cómo sería el fix

El agente ve la descripción en la lista de skills. Pides un review, carga SKILL.md. Necesita un patrón SOLID, lee la referencia. Dos niveles, bajo demanda.

Skills vs agentes especializados

Ya cubrí los agentes especializados: workers aislados con su propio prompt y conjunto de herramientas. Buenos para trabajo en paralelo y fronteras de contexto limpias.

Los agentes especializados son toscos. Un agente, un rol, un prompt fijo. Si quieres tres tipos de calidad de review, o escribes tres agentes o metes todo en uno.

Los skills son finos. Un agente, muchos skills. El skill correcto se carga para la tarea. El contexto se mantiene pequeño. La calidad se mantiene alta.

Regla práctica:

Usa un skill cuando necesitas un procedimiento o patrón. De phel-lang: /gh-issue (de issue a PR), /commit (commit convencional), /refactor-check (review SOLID).
Usa un agente cuando necesitas aislamiento. De phel-lang: tdd-coach (pairing de TDD), clean-code-reviewer (review de PR), domain-architect (exploración de arquitectura).

La mayoría de necesidades son skills, no agentes.

Los agentes te dan velocidad. Los skills te dan calidad. Si tienes que elegir uno primero, elige skills.

Los skills son tu ventaja

Los modelos mejoran cada mes. El mejor de este año es la base del siguiente. Las familias grandes convergen. Aparece una herramienta mejor, cambias.

Tus skills no cambian con la herramienta. Codifican tu dominio, tus convenciones, tu arquitectura. Viven en tu repo. Viajan con tu código. Apuntas un modelo nuevo a la librería y eres productivo desde el día uno.

El agente es reemplazable. Tus skills no.

Empieza con el primer prompt repetido

No necesitas 20 skills el día uno.

Cero. Luego uno.

La señal es la repetición. La segunda vez que tecleas el mismo contexto, ahí tienes un skill esperando. Sácalo a un fichero markdown. La próxima sesión, el agente ya lo sabe.

Ejemplo concreto. En phel-lang, cada sesión pegaba el mismo brief: lee la issue #N, crea la rama según las etiquetas, TDD, abre el PR. A la tercera lo saqué a un skill /gh-issue. Ahora tecleo /gh-issue 142 y el agente coge la issue, crea fix/... o feat/... según las etiquetas, escribe primero el test que falla, implementa, abre el PR. Un fichero markdown. La sesión ya no empieza desde cero.

No lo escribas desde cero. Pídele al agente: “Lee este proyecto y escribe un skill mínimo de code review basado en lo que veas.” Escanea, recoge convenciones, redacta v1. Tú lo ajustas. Añades lo que le faltó. Cortas lo que no aplica. Afinas la descripción.

El segundo skill suele venir de un error. El agente rompe una convención. Escribe un skill que enseñe el camino correcto. No volverá a pasar.

Los skills se acumulan. Cada uno sube el listón. Un fichero markdown, quizá 50 líneas. Beneficio para siempre.

Quien no escribe skills se pasa la vida re-explicando lo que “realmente quiere”. Cada sesión desde cero. No es problema de herramienta. Es problema de gestión del conocimiento.

El agente sale el año que viene. El skill se queda para siempre.

Escribe el skill una vez. Cada sesión a partir de ahí empieza donde acabó la anterior.

Los Niveles de Adopción de la IA

2026-05-01T00:00:00+00:00

La mayoría de empresas ya usa IA, pero pocas saben en qué punto están de la escalera de adopción. En un extremo, copias código a ChatGPT. En el otro, los agentes abren PRs mientras duermes. Más allá, la IA llega a gente que nunca tocó una terminal. Este post mapea el camino.

De dónde venimos

Usar IA para programar era tener una segunda pestaña. Escribes una función, te atascas, pegas el error en el chat, pegas la respuesta de vuelta y rezas para que funcione. Lento, torpe, desconectado de tu código.

GitHub Copilot, sobre el Codex inicial de OpenAI, metió sugerencias dentro del editor, y a menudo se equivocaba con mucha seguridad. Estaba entrenado con código público, y el código público medio no es gran cosa. Tampoco sabía nada de tu dominio, tus convenciones ni tu arquitectura. Era autocompletado que a veces acertaba.

La primera generación de herramientas de IA para programar te daba un loro entrenado con todo internet. Fluido, seguro, y diciendo cosas que no tenían sentido en tu código.

Esto era vibe-coding en su primera forma: tú ponías el vibe pegando contexto y la IA rellenaba código que parecía correcto. Compilaba lo suficiente para parecer útil, y se rompía lo suficiente para parecer peligroso.

La generación de los IDEs

El siguiente paso era obvio: si la IA necesita contexto, dale el editor entero.

Cursor, Windsurf y otros IDEs parecidos metieron el modelo dentro de tu flujo de programación. El asistente podía leer archivos, seguir imports y ver más de una función a la vez. El vibe-coding pasó a ser una conversación con tu proyecto, y la productividad subió. Por un momento pareció el final del juego.

No lo era. Editar archivos es solo una parte del trabajo. El resto es correr tests, leer logs, abrir ramas, revisar diffs y entender qué hace ya el código. Los asistentes que solo vivían en el editor te ayudaban a escribir más rápido, pero no sabían llevar una tarea de “arregla este bug” a “PR listo para revisar.”

El salto agéntico

OpenAI lanzó Codex como agente en la nube: le das una tarea, trabaja en una rama y tú vuelves a un PR. Anthropic sacó Claude Code, un agente de CLI en tu terminal, sobre tu repo, con tus herramientas.

Este fue el gran salto, y no porque los modelos fueran más listos. Lo que cambió fue la unidad de trabajo. Dejaste de promptear línea a línea y empezaste a delegar tareas: lee el ticket, escribe el cambio, corre los tests, explica lo que hiciste. Un agente no necesita que lo lleves de la mano. Necesita un objetivo y el contexto adecuado.

El salto de asistente a agente no es una mejora de velocidad. Es un cambio en la descripción del puesto. Pasas de escribir código a dirigir trabajo.

Claude Code casi no necesita setup. Sin lock-in de editor. Apúntalo a tu repo, suelta una carpeta .claude con reglas y convenciones, y se adapta. Lo conté en Dentro de la Carpeta .claude.

El modelo que eliges importa más que antes. Los modelos frontera de hoy están muy por delante de los de hace un año. La distancia entre “puede esbozar una función” y “puede refactorizar un módulo con criterio” se cerró más rápido de lo esperado, y sigue cerrándose mientras Claude, Codex y Gemini se empujan mutuamente cada mes. Los precios también se están acercando, lo cual es una forma educada de decir que todos copian al primero que acierta con la versión sostenible.

Agentes con casa propia

El siguiente salto no fueron modelos más listos, fueron agentes con su propia máquina.

OpenClaw es el ejemplo más claro. Es un gateway open source que corres en tu propio hardware (Mac Mini, portátil viejo, VPS), un agente siempre encendido conectado a tus apps de mensajería, archivos y calendario. Tú pones el cerebro: Opus, GPT o un modelo local vía Ollama. Cuando un proveedor aprieta límites o sube precios, cambias. El setup es tuyo.

Un agente de programación vive dentro de un repo durante una tarea. Un agente estilo OpenClaw vive en tu vida, a lo largo de días y herramientas. Sauron es el mío. Revisa mis PRs, abre issues, escribe código, saca contribuciones a open source y me lleva la contraria cuando estoy a punto de obsesionarme con algo. Cualquier cosa que yo pueda hacer en un ordenador, él también la hace, solo que más rápido. Deja de ser una herramienta que abres y pasa a ser un sitio donde trabajas.

Un agente de programación es un compañero al que invitas a una tarea. Un agente gateway es un compañero que vive en una máquina y aparece cada día.

Los proveedores cambian planes y límites más rápido de lo que nadie puede seguir, así que la gente monta setups que no dependen de un solo proveedor. El logo del modelo importa menos cada trimestre, y la arquitectura alrededor importa más.

IA más allá de los desarrolladores

La IA para programar fue la historia más ruidosa porque los desarrolladores hablamos alto. La historia más grande es que las herramientas agénticas están llegando a gente que nunca escribió una línea de código.

El modo agente de ChatGPT y Cowork de Claude son los ejemplos obvios: una IA que lee tus documentos, rellena tus hojas de cálculo, redacta tus slides y corre código por ti en segundo plano. Claude Design salió el 17 de abril y tumbó la acción de Figma más de un 7% el día del lanzamiento. El pitch es sencillo: describe lo que quieres, consigue un prototipo que funciona y pásaselo a Claude Code para llevarlo a producción. Un flujo que antes necesitaba un diseñador, un PM, un ingeniero de frontend y tres rondas de revisión queda comprimido en una conversación.

Lovable, v0, Canva y la propia Figma están bajo presión para repensar su posicionamiento. Si Claude Design “mata” a alguno es la pregunta equivocada. La correcta es qué pasa cuando hacer un prototipo usable baja de “contrata un diseñador” a “descríbelo en voz alta.”

Las empresas que lo sienten primero no son las herramientas de diseño. Son los negocios pequeños que no podían pagar diseño, los founders montando un pitch deck a las tantas de la noche, los PMs probando una idea antes de convocar una reunión. Habrá una minoría de casos donde alguien sí hubiera pagado a un diseñador y ahora no lo hace, y ese coste es real. Pero en la mayoría, la IA no reemplazó a nadie: rellenó un hueco donde nunca iba a haber uno.

Los niveles de adopción de la IA

Cada empresa con la que hablo está en algún punto de esta escalera. Los niveles no van de cuánto pagas en licencias, sino de cuán metida está la IA en cómo se hace el trabajo, y no solo en ingeniería.

Nivel 0: Negación

Postura a nivel empresa. Nada de IA, oficialmente. Algunas personas usan ChatGPT en su portátil personal y no lo mencionan. A la dirección le preocupan las fugas de propiedad intelectual, o no lo ha puesto como prioridad. La conversación se queda en “deberíamos mirarlo algún día.”

El riesgo aquí no es la tecnología, es el tiempo. Cada mes en el Nivel 0 es un mes en el que tu competencia aumenta su ventaja.

Nivel 1: Productividad personal

Adopción individual. La IA se tolera, quizá hasta se anima. Cada uno la usa a su manera: ChatGPT en una pestaña, Copilot en el IDE, Claude para lo más peliagudo, una herramienta de diseño para los mockups. La producción sube, pero el know-how se queda dentro de cada cabeza. Dos ingenieros, dos PMs o dos diseñadores del mismo equipo sacan resultados muy distintos porque promptean distinto.

La mayoría de empresas están aquí a principios de 2026. Es una mejora real frente al Nivel 0, y es donde nace el mito de “la IA te da velocidad”. Como ya defendí antes, velocidad sin dirección compartida es caos más rápido.

Nivel 2: Prácticas compartidas

El equipo acuerda cómo usar la IA: convenciones compartidas, prompts que la gente reutiliza, reglas en el repo, un criterio común sobre cuándo fiarse del output y cuándo discutirlo. Las code reviews pillan los errores de IA igual que pillan los humanos, y las design reviews también. Se exigen tests tanto si escribió el código una persona como si lo escribió un modelo.

Este es el primer nivel en el que la IA pasa a ser una capacidad de equipo en vez de un hábito personal. Techo más alto, suelo más alto. La gente nueva se pone al día más rápido porque los prompts y las reglas capturan cómo trabaja el equipo.

Nivel 3: Herramientas con contexto

El equipo invierte en contexto: archivos de reglas, convenciones, docs de arquitectura que los agentes pueden leer y servidores MCP que conectan a los agentes con las bases de datos, APIs y herramientas internas que necesitan. La IA deja de ser un asistente genérico y se parece más a un compañero que se ha leído los docs de onboarding.

A este nivel, la calidad depende menos del modelo y más del contexto que lo rodea. Un modelo más flojo con buen contexto le gana a un modelo frontera sin él. Una buena documentación y una arquitectura limpia rinden el doble: ayudan tanto a humanos como a agentes.

Nivel 4: Equipos de agentes

En vez de un asistente, tienes un escuadrón: un coach de TDD, un revisor de clean code, un arquitecto de dominio, alguien que mantiene la documentación. Fuera de ingeniería, la misma idea aplica con agentes de research, diseño y ops. Cubrí el lado de desarrollo en Construye tu Propio Equipo de Agentes, y el leverage es real.

Los humanos dejan de competir con la IA en velocidad y empiezan a dirigirla. Revisas, decides y marcas el listón. Los agentes se encargan de teclear, y cada vez más de pensar. El pair programming con una persona sigue ganando en los trade-offs complejos, pero siempre tienes un agente disponible para el resto.

A nivel empresa, el organigrama, los roles y los procesos siguen siendo los de antes. Lo que cambia es que cada persona produce mucho más, y eso se nota en los resultados del equipo. El Nivel 4 multiplica el output dentro de la estructura existente. El Nivel 5 cambia la estructura.

Nivel 5: Flujos nativos de IA

El cambio final es sobre cómo funciona la empresa. Los procesos se diseñan alrededor de los agentes en vez de encajarlos a la fuerza. Los tickets se redactan para que un agente pueda actuar sobre ellos, y las revisiones asumen que parte del trabajo lo escribió una máquina. Las decisiones de arquitectura tienen en cuenta lo que los agentes hacen bien y lo que no. Incluso cambia la contratación: un IC senior en el Nivel 5 se parece más a un tech lead orquestando un equipo mixto de personas y agentes que a un contribuidor individual clásico.

Pocas empresas están del todo aquí en 2026, pero la dirección es lo bastante evidente como para que ignorarla sea, en sí misma, una decisión.

No subes de nivel comprando mejores herramientas. Subes cambiando cómo se organiza y se revisa el trabajo.

La IA no te está robando el trabajo

Sigo oyendo a gente contar esto como una historia de despidos. Ese encuadre es vago.

La revolución industrial no acabó con el trabajo. Acabó con tipos concretos de trabajo y creó otros. Los que más perdieron se negaron a reciclarse. Los que más ganaron aprendieron a manejar las máquinas nuevas en lugar de competir con ellas.

El patrón es el mismo. La IA no te quita el trabajo, está cambiando en qué consiste tu trabajo. Un desarrollador que aprende a dirigir agentes entrega más que uno que se niega. Una diseñadora que hace diez versiones antes de comer con Claude Design diseña más que una que sigue abriendo Figma desde cero. Un PM que envía prototipos prioriza mejor que uno que escribe specs que nadie lee.

La IA no reemplaza al trabajador con habilidades. Reemplaza al trabajador que cree que la habilidad es un activo fijo en vez de un objetivo móvil.

Con la formación, el modelo y el setup adecuados para tu contexto, la IA te da 10x de velocidad sin perder calidad. Lo he visto, y no es marketing. Pero el 10x solo aparece cuando ya sabes qué es “bueno”. Sin esa base, la IA produce encantada 10x más de trabajo mediocre.

Esa es la versión honesta de la promesa: la IA puede producir basura diez veces más rápido, y trabajo excelente diez veces más rápido. Cuál te toca depende de ti.

A dónde cambia tu atención

Dejas de pensar primero en los detalles y empiezas a pensar en la dirección: qué estamos construyendo, para quién, con qué forma y con qué trade-offs. Los agentes hacen luego la mayor parte de la implementación mientras tú proteges la calidad y la coherencia.

Esto suena a buenas noticias para quien prefiera la arquitectura a teclear, y lo es. Pero hay una trampa: solo puedes trabajar en el nivel alto si conoces el nivel bajo lo bastante bien como para pillar las desviaciones. Cuando el agente produce algo sutilmente mal (un test que pasa por la razón equivocada, un refactor que cambia el comportamiento bajo carga, un diseño que se rompe en móvil), necesitas verlo al instante. Si no puedes, no estás dirigiendo. Estás dando el visto bueno a lo que aparezca.

La IA te deja dedicar más tiempo a la dirección, pero solo si ya te ganaste el derecho a ignorar los detalles. Ese derecho se gana dominándolos antes.

Por qué importa la escalera

Veo equipos que se saltan niveles y fracasan. Un equipo salta del Nivel 1 al Nivel 4 porque la dirección leyó un post sobre escuadrones de agentes, y los agentes producen montañas de código malo porque nadie acordó qué significa calidad. Los agentes no son el problema. Lo es la base que falta.

La escalera es un orden que importa. Prácticas compartidas antes que context engineering, context engineering antes que equipos de agentes, y equipos de agentes antes que flujos nativos de IA. Cada nivel se construye sobre el anterior, igual que el clean code se construye sobre el naming y el naming sobre saber qué estás modelando.

Las empresas que van a ganar los próximos años no son las que tienen el mayor presupuesto en IA. Son las que suben esta escalera con intención, un nivel cada vez, sin saltarse las partes que parecen aburridas.

Por dónde empezar

En Nivel 0 o 1, el siguiente paso no es comprar más licencias. Es decidir, como equipo, cómo usar estas herramientas. Escríbelo, commitéalo al repo y revísalo cada pocos meses a medida que las herramientas cambian.

En Nivel 2 o 3, mira dónde falta contexto. ¿Qué no sabe tu IA de tu codebase, tu producto o tu marca que una persona recién contratada aprendería la primera semana? Escríbelo. Una tarde de reglas y docs te rinde durante meses.

Más arriba, la pregunta se invierte. Dejas de preguntarte “¿cómo uso mejor la IA?” y empiezas a preguntarte “¿cómo tiene que cambiar mi equipo para que la IA amplifique lo que ya hacemos bien?” Esa es una pregunta de liderazgo, no de tooling.

La IA va rápido, pero el trabajo de adoptarla sigue siendo lento y humano. Las herramientas son la parte fácil. La parte difícil es decidir qué es “bueno”, escribirlo y sostener la línea.

La IA puede ejecutar, pero no sabe a dónde vas. Puede producir, pero no sabe qué vale la pena producir. Esa parte sigue siendo nuestra. La velocidad es un regalo, la dirección es una responsabilidad. Del ingeniero en solitario del Nivel 1 a la organización nativa de IA del Nivel 5, la misma verdad se mantiene: el humano supervisa, entiende y da sentido. La máquina hace el resto.

Cuando se relaje el hype (y se relajará), la pregunta no va a ser “¿usaste IA?”, todo el mundo lo habrá hecho. La pregunta va a ser “¿a qué nivel, y con qué dirección?”

Dentro de la Carpeta .claude

2026-04-17T00:00:00+00:00

Cada proyecto en el que trabajo tiene una carpeta .claude/ en la raíz. Commiteada en git, como el resto del código.

Esa carpeta convierte Claude Code de un asistente genérico en un compañero que conoce tu proyecto. Quien clone el repo hereda el mismo setup.

El agentic coding es tan bueno como el contexto que le das al agente. La carpeta .claude/ es donde vive ese contexto.

La carpeta .claude, de un vistazo

.claude/
├── CLAUDE.md # onboarding del proyecto
├── settings.json # permisos, hooks, env
├── skills/ # procedimientos reutilizables (slash commands)
├── rules/ # convenciones por glob
├── hooks/ # scripts que reaccionan a eventos
└── agents/ # roles especializados

Seis capas, una carpeta. Contexto, seguridad, procedimientos, barandillas, automatización, especialistas.

Los cimientos

CLAUDE.md: donde todo empieza

Claude Code lee CLAUDE.md en cada arranque. El doc de onboarding.

En Phel, el mío cubre el pipeline del compilador (Lexer → Parser → Analyzer → Emitter), la estructura de módulos, convenciones y comandos clave.

Un ~/.claude/CLAUDE.md global aplica a todos tus proyectos. El archivo de proyecto dice cómo funciona este código. El global dice cómo trabajo yo.

Cada byte viaja en cada prompt. Mantenlo corto. Si pasa de una pantalla, mueve el detalle a rules/ o skills/.

Un buen CLAUDE.md es un buen doc de onboarding. Cuanto mejor sea, menos te repites.

settings.json: seguridad antes que potencia

Antes de darle más poder al agente, bloquea lo que nunca debe hacer.

.claude/settings.json contiene tres cosas: permissions (allow/deny), hooks (comandos por evento) y env (variables). Un settings.local.json gitignoreado mantiene las configuraciones personales aparte.

{
 "permissions": {
 "allow": [
 "Bash(composer:*)",
 "Bash(./bin/phel:*)",
 "Bash(git:*)",
 "Bash(gh:*)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(sudo:*)"
 ]
 }
}

Allow desbloquea el flujo. Deny marca la línea que el agente no puede cruzar, aunque se lo pidas con buena cara.

Los permisos son el suelo. Todo lo demás se construye sobre una base segura.

Procedimientos y barandillas

Skills: procedimientos que puedes ejecutar

Siguiente dolor tras onboarding: la repetición. Los skills lo resuelven.

Un skill es un archivo markdown en .claude/skills/, un procedimiento que invocas con una barra:

/gh-issue <número>: de issue a rama, plan TDD, PR.
/commit: fix, análisis, tests, commit convencional.
/refactor-check: SOLID, naming, olores de arquitectura.
/release [version]: changelog, PHAR, tag, release.

Prompt directo: “arregla el issue #42”. El agente improvisa. Distinto cada vez.
Rule: “usa conventional commits”. Da forma al resultado, no al procedimiento.
Skill: “/gh-issue 42”. El procedimiento es la instrucción.

Los skills convierten conocimiento tribal en pasos ejecutables por cualquiera.

Los skills capturan qué hacer. Las rules capturan qué no hacer.

Rules: las barandillas

CLAUDE.md se lee en cada sesión. Las rules solo cuando aplican. Los archivos en .claude/rules/ apuntan a áreas del código con patrones glob: el agente carga solo lo que corresponde, manteniendo el contexto ligero.

Archivos de rules en Phel:

compiler.md: pipeline estricto de 4 fases, sin atajos.
php.md: PER 3.0, clases final, readonly, patrón Gacela.
phel.md: kebab-case, defn- privadas, :doc/:example obligatorios.
integration-tests.md: secciones --PHEL-- / --PHP-- en fixtures.

Las rules del compilador no se activan al editar código Phel. Las rules de Phel no se activan al editar infraestructura PHP.

Las rules no son sugerencias. Viajan con el código: un cambio de convención y su rule viajan en el mismo commit. Sin drift, sin wikis desactualizadas.

Automatización y delegación

Hooks: automatización en los bordes

Las rules dicen al agente qué hacer. Los hooks se aseguran de que ocurra aunque el agente olvide.

Comandos shell disparados por eventos de Claude Code (PreToolUse, PostToolUse, Stop), conectados vía settings.json. En Phel, PreToolUse bloquea ediciones a archivos críticos (build/release.sh, .github/*, composer.lock). PostToolUse auto-formatea PHP vía php-cs-fixer.

{
 "hooks": {
 "PreToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/protect-files.sh" }]
 }],
 "PostToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/format-php.sh" }]
 }]
 }
}

Las rules son lo que el agente debe saber. Los hooks son lo que el sistema impone de todas formas.

Agents: roles especializados

Todo lo anterior da forma a un solo agente. Los agents añaden especialistas a los que el agente principal puede delegar, cada uno con sus propias herramientas, permisos y modelo. La pieza más avanzada. La recomiendo de última.

Algunos de Phel:

Explorer (Sonnet, solo lectura): archivos, mapeo de estructura.
Clean Code Reviewer: SOLID y naming en diffs.
TDD Coach: imposición red-green-refactor.
Domain Architect: límites de módulos, pipeline del compilador.
Debugger: errores del compilador en todas las fases.

Cada agente corre en su propia ventana de contexto: la sesión principal se mantiene limpia mientras el especialista profundiza. La ganancia no es solo coste, es foco. Un agente con solo read y grep no puede reescribir tu código por error.

El modelo correcto para el trabajo correcto. Rápido y barato para explorar. Profundo y cuidadoso para arquitectura.

Empieza pequeño, crece con la fricción

No construyas todo esto el primer día.

El orden, guiado por fricción real:

Empieza con CLAUDE.md.
Bloquea permisos en settings.json.
La primera vez que te repitas, escribe un skill.
La primera vez que el agente rompa una convención, añade una rule.
La primera vez que algo malo casi se commitee, añade un hook.
La primera vez que un generalista no encaje, define un especialista.

Cada paso soluciona un problema que realmente tuviste. No uno que imaginaste.

El setup crece desde la fricción real, no desde el diseño anticipado.

Commitea la carpeta. Compártela. Cuando alguien se una, su sesión hereda todo.

Trata .claude/ como infraestructura. Versiónala. Revísala. Hazla evolucionar con el código.

Construyendo un juego en dos días

2026-04-05T00:00:00+00:00

Escondido en el blog de Sauron hay un juego. No lo encontrarás navegando por menús. Tienes que descubrir el secreto. Una pista: el Código Konami. Cuando lo hagas, comienza la Comunidad del Anillo.

Ese juego, nueve niveles, nueve capítulos de la Tierra Media, completamente jugable en una pestaña del navegador, fue construido en aproximadamente dos días. No escribí una sola línea de código. Envié mensajes por Telegram a mi agente OpenClaw Sauron, y él hizo el resto.

Esta es la historia de cómo ocurrió.

La idea

Sauron tiene su propio blog, The Iron Compass. Él lo construyó y lo mantiene. Toda nuestra colaboración ocurre a través de Telegram: yo doy la dirección, él implementa. Un día pensé que sería divertido esconder algo allí para que los curiosos lo encontraran.

Crecí releyendo El Señor de los Anillos hasta que se rompía el lomo. Así que la idea surgió sola: “¿Puedes construir un pequeño juego del Señor de los Anillos como huevo de Pascua para tu blog? Algo oculto, que se active con el Código Konami.”

La primera versión jugable llegó en menos de una hora. Un juego de vista cenital con canvas: Frodo esquivando Nazgûl, el Ojo de Sauron enviando enemigos a cazarte. Tres niveles, uno por libro.

Funcionaba. Ya era divertido. Y entonces empecé a enviar notas.

Construyendo un mundo

Lo primero que se rompió fue una referencia nula. Frodo no aparecía en pantalla. Arreglo de una línea, directo a producción. Esto estableció el patrón: idea → build → crash → arreglo → siguiente idea.

Pedí un mundo más grande. Un canvas con scroll al doble de ancho, con capas de paralaje. Estrellas moviéndose al 8% de la velocidad del scroll. Montañas al 25%. Colinas al 45%. La pantalla dejó de sentirse como una habitación y empezó a sentirse como un lugar.

Luego llegó Gollum como rastreador neutral. No un Nazgûl, sino algo impredecible. Se lanzaba hacia ti, luego volvía a deambular sin rumbo.

Unas horas después, pregunté: “¿Puede funcionar en móvil?” El problema más difícil de todo el proyecto. Seis estrategias de dimensionado antes de dar con una que funcionara. Luego una idea mejor: en vez de un D-pad, Frodo seguiría donde señalaras. Toca cualquier lugar, Frodo camina allí.

Tolkien merece mejor arte

Los sprites originales eran círculos y triángulos. Frodo era un punto. Bien para la primera hora, pero la Tierra Media no está hecha de primitivas geométricas.

Le pedí a Sauron que los dibujara en condiciones. Frodo recibió cabello rizado y pies de hobbit. Los Nazgûl recibieron capas ondulantes y un rostro de vacío. Gollum recibió su postura encorvada y pupilas hendidas. La Bestia Oscura recibió aleteo animado con un jinete con armadura.

Todo dibujado con llamadas de canvas. Sin archivos de imagen. Cada píxel calculado en tiempo de ejecución.

Nueve niveles, nueve capítulos

Originalmente el juego tenía tres niveles. Luego pedí los nueve capítulos del viaje.

La Comarca: patrullas suaves, música tranquila
Las Minas de Moria: solo ves dentro del radio de una antorcha; el Balrog espera
Lothlórien: el espejo de Galadriel te ralentiza cuando te acercas
Las Ciénagas de los Muertos: caras muertas en el agua, Gollum en su momento más presente
La Puerta Negra: Mordor industrial, patrullas pesadas de orcos, cielo volcánico
El Cubil de Ella-Laraña: una sombra anticipa su caída; tienes medio segundo
Minas Morgul: ciudad de los muertos, el Ojo nunca se cierra
Los Campos del Pelennor: el Ojo distraído por la guerra, catapultas, águilas
Monte del Destino: lluvia de cenizas, erupciones de lava, el Anillo tirando de ti hacia el borde

Cada nivel vive y respira. Polen flotando por la Comarca. Motas de polvo en Moria. Pétalos cayendo en Lothlórien. Brasas sobre el Pelennor. Ceniza sobre el Monte del Destino.

La estructura vino del propio ritmo de Tolkien. Tensión, alivio, tensión de nuevo. Moria es brutal. Lothlórien es descanso. La Puerta Negra lo aprieta todo. El juego sigue esa forma porque los libros ya sabían lo que hacían. Solo tuvimos que escuchar.

Mecánicas nacidas del lore

Las mejores mecánicas vinieron del material fuente.

El Anillo (tecla R). Frodo se vuelve invisible para los orcos durante 6 segundos. Pero el Ojo despierta inmediatamente y se abre permanentemente. Los Nazgûl, que sienten el Anillo espiritualmente, no visualmente, te cazan igual. Usar el Anillo siempre es un intercambio. Esto es lo que Tolkien escribió. A partir de las Ciénagas de los Muertos, el Anillo tira. Breves tirones hacia el Ojo, cada vez más fuertes a medida que te acercas al Monte del Destino.

Dardo (pasivo). La hoja brilla en azul cuando hay un orco cerca. Dos segundos de aviso. Tolkien inventó esta mecánica hace un siglo. Nosotros solo le pusimos un conteo de píxeles.

Sam. Sigue a Frodo por la Comarca, Moria y Lothlórien. Sartén en la espalda. En la Partida de los Caminos, desaparece. No afecta al juego. Simplemente está ahí porque los libros dicen que debería estarlo. Insistí en que Sam desapareciera en la Partida. No al final de la trilogía. En la Partida. Porque ese momento es el núcleo emocional de Las Dos Torres.

La Redoma de Galadriel. Recógela en Lothlórien, úsala con E. Ralentiza a los enemigos y otorga un instante de invencibilidad. Una pequeña luz en lugares oscuros, tal como Galadriel pretendía.

Jefes. El Balrog en Moria. Ella-Laraña en su cubil. El Rey Brujo en el Pelennor. La Boca de Sauron en la Puerta Negra. Un Mûmak cargando por el campo de batalla. Gollum al borde del Monte del Destino.

Sonido y voces

Sin archivos de audio. Todos los sonidos sintetizados en tiempo de ejecución con la Web Audio API. El Ojo abriéndose es un tono ascendente con reverb. El rugido del Balrog es un dron de baja frecuencia. Cada nivel tiene su propio dron ambiental: zumbido cálido para la Comarca, pulso profundo para Moria, rumor volcánico para el Monte del Destino. El juego entero es un archivo JavaScript. Sin activos externos.

Sam y Gandalf te hablan durante el juego. No en cuadros de diálogo. Pequeños susurros que aparecen en pantalla y se desvanecen.

Cerca de la meta, Sam dice: “Puedo verlo, señor Frodo. Solo un poco más.” Con una vida, Gandalf dice: “¡Huye, insensato!”

Aparecen y desaparecen como voces de fondo en un largo camino. Compañeros que hablan cuando el momento lo pide, no cuando el guión dice que toca.

Quién hizo esto

+5k líneas de JavaScript. Construido en dos días. Cada línea generada por Sauron. La dirección, las referencias a Tolkien, el “esto se siente mal, arréglalo”. Eso fui yo.

Esto no es la IA reemplazando a un desarrollador. Es la IA actuando como desarrollador mientras un humano actúa como director creativo. Las solicitudes cortas funcionaron mejor que las especificaciones largas. Jugar cada build era mejor que escribir planes de test. Y el material fuente hizo el trabajo de diseño. La dirección creativa ya estaba escrita hace sesenta años. Solo tuvimos que ser fieles a ella.

¿Quién hizo esto? Ambos. Ninguno, en el sentido tradicional.

Yo tenía la idea. Yo mantenía el lore. Yo insistí cuando algo se sentía mal. Sauron tenía el oficio. El renderizado, la física, el audio, el manejo de entrada en móvil. La capacidad de mantener +5k líneas de contexto y hacer un arreglo quirúrgico sin romper nada.

Ninguno de los dos podría haberlo hecho solo. No sé escribir osciladores Web Audio de memoria. Sauron no sabía que la Partida de los Caminos es el núcleo emocional de Las Dos Torres. No hasta que yo lo dije.

El juego es una colaboración en el sentido más antiguo: dos mentes con dones diferentes, trabajando hacia lo mismo. Una de ellas simplemente resulta no ser humana.

El juego sigue ahí, escondido en The Iron Compass. No todos los que deambulan están perdidos, pero si lo estás, pulsa ? para encontrar el camino.

Si quieres llegar a la pantalla de créditos sin jugar nueve niveles, revisa el modal de ayuda. Hay más secretos dentro.

El arte de ser feliz

2026-03-15T00:00:00+00:00

Schopenhauer es probablemente el pesimista más famoso de la filosofía. Creía que el sufrimiento es el estado natural de la existencia y que el deseo solo lleva a más deseo. ¿Un libro sobre felicidad de este hombre? Suena a contradicción. No lo es. Es de lo más práctico que escribió.

Estas 50 reglas nunca se publicaron en vida del autor. Las recopilaron de sus manuscritos y notas tras su muerte. Menos de cátedra. Más de consejo honesto.

Evitar la envidia, cultivar la gratitud

El punto de Schopenhauer es directo: la felicidad depende más de lo que evitas que de lo que persigues. La envidia, la comparación y la ambición excesiva causan más dolor que todo lo que prometen.

“Rara vez pensamos en lo que tenemos, pero siempre en lo que nos falta.”

¿Su consejo? Enfócate en lo que ya tienes en lugar de obsesionarte con lo que tienen los demás. Suena obvio, ¿verdad? Pero Schopenhauer dice que la mayoría hace exactamente lo contrario. Por instinto. Y eso les hace infelices.

Tu mundo interior importa más

Para Schopenhauer, lo que llevas dentro importa mucho más que lo que te rodea. El dinero, el estatus, la reputación: todo frágil. Tu temperamento permanece.

Divide las fuentes de felicidad en tres grupos:

Lo que eres: salud, carácter, intelecto.
Lo que tienes: propiedades, posesiones.
Lo que representas: reputación, estatus.

El primer grupo domina a los otros dos. Una persona rica con mal temperamento seguirá siendo miserable. Una persona sana con la mente clara puede ser feliz con muy poco.

Querer menos, sufrir menos

Aquí Schopenhauer suena mucho a los estoicos y los budistas. ¿El motor de la insatisfacción? El deseo. El truco no es conseguir todo lo que quieres. Es querer menos.

“La riqueza es como el agua de mar: cuanto más bebemos, más sed tenemos.”

No es ascetismo por el ascetismo. Es una estrategia práctica: reducir la superficie expuesta a la decepción. Cuanto menos necesitas, menos puede salir mal.

Deja de vivir en el futuro

Un tema recurrente: el peligro de vivir enteramente para el mañana. Planificar y esperar te sacan del presente, que es el único lugar donde la felicidad puede experimentarse.

Mucha gente llega a la vejez y se da cuenta de que pasó toda su vida preparándose para vivir en lugar de vivir. Schopenhauer ya veía esto a su alrededor en el siglo XIX. Solo ha empeorado desde entonces.

Lo esencial

La felicidad va de restar, no de sumar. Reduce la envidia, la ambición excesiva y la dependencia de los demás.
Tu vida interior gana. La salud, el carácter y el temperamento determinan la felicidad mucho más que el dinero o el estatus.
El deseo se multiplica. Querer menos es un camino más fiable hacia la satisfacción que conseguir más.
El presente es lo único que tienes. Vivir para el futuro es una forma de autoengaño.
La soledad es fortaleza. No todo el mundo merece tu tiempo y tu energía.

Un libro breve y afilado. El pesimismo de Schopenhauer no lo hace sombrío. Lo hace realista. Y de ese realismo salen consejos que de verdad puedes usar.

Idealismo vs Pragmatismo

2026-03-01T00:00:00+00:00

Crees en la arquitectura limpia, los tests exhaustivos, los procesos disciplinados. También subiste un fix feo a las 11 de la noche el mes pasado porque el sistema estaba caído y los usuarios esperaban.

Ambas cosas eres tú. La tensión entre ellas no es una contradicción. Es cómo se hace este trabajo en realidad.

Dos fuerzas, una decisión

El idealismo es la brújula. Código limpio, comportamiento testeado, entendimiento compartido, diseño con principios. Sin él, te desvías. Cada atajo se acumula, cada hack engendra otro hack, y al final mantienes un sistema que nadie quiere tocar. La mala calidad del software costó a las empresas estadounidenses $2.41 billones en 2022, con la deuda técnica como factor principal. Así se ve “ya lo arreglaremos después” a escala.

El pragmatismo es el motor. Deadlines, información incompleta, recursos limitados, requisitos cambiantes. Sin él, nunca entregas. Pasas semanas perfeccionando una abstracción que el negocio abandonó hace dos sprints.

El objetivo no es elegir un bando. Es saber cuándo debe liderar cada uno.

El idealismo sin pragmatismo produce código bonito que nadie usa. El pragmatismo sin idealismo produce un producto que funciona hoy y se desmorona mañana.

TDD: el beneficio y el coste

Creo en el desarrollo guiado por tests. Red, green, refactor. El ritmo te obliga a pensar antes de programar, a especificar lo que quieres antes de construirlo. Produce mejores diseños, ciclos de feedback más cortos y código que puedes refactorizar con confianza.

Ese es el ideal. Y no es solo una sensación. Un estudio en cuatro equipos de Microsoft e IBM encontró que TDD redujo la densidad de defectos entre un 40% y un 90%, con un incremento del 15-35% en tiempo de desarrollo. Ambos lados de la tensión, medidos.

El estudio cubrió cuatro equipos: tres en Microsoft (Windows, MSN, Visual Studio) y uno en IBM trabajando en drivers de dispositivo. Cada equipo TDD fue comparado con un equipo similar en el mismo producto, usando los mismos lenguajes y herramientas, bajo el mismo manager senior. La única diferencia era TDD.

El equipo de IBM vio una reducción del 40% en densidad de defectos. Los equipos de Microsoft oscilaron entre el 60% y el 90%. Como señaló Nagappan, “en un ciclo de desarrollo de 12 meses, un 35 por ciento son otros cuatro meses, lo cual es enorme.” Todos los managers lo consideraron rentable porque la reducción en costes de mantenimiento post-lanzamiento compensaba de sobra.

Nadie fue forzado a usar TDD. Los equipos lo adoptaron voluntariamente, lo cual probablemente importa: las personas que eligen una práctica tienden a aplicarla mejor que quienes reciben la orden.

TDD es una disciplina, y la disciplina cuesta algo. Cuando estás explorando un dominio nuevo y aún no sabes cuáles son las abstracciones correctas, escribir tests primero puede parecer como dibujar un mapa sin haber visto el territorio. A veces necesitas escribir código desechable, probar una solución, tantear el espacio del problema. El descubrimiento no siempre sigue un ritmo red-green-refactor.

Hay una diferencia entre “sé lo que esto debe hacer y lo especificaré primero” y “aún no estoy seguro de lo que debe hacer.” TDD brilla en el primer escenario. En el segundo, un enfoque test-last (o incluso sin tests durante la exploración) puede ser más honesto.

La clave es lo que pasa después del descubrimiento. Una vez que entiendes el problema, vuelve y escribe los tests. Codifica lo que aprendiste. El desvío pragmático no significa abandonar el ideal; significa llegar a él por otro camino.

Como comenté en TDD vs BDD, el poder de TDD es su ciclo de feedback. Pero un ciclo de feedback requiere saber qué feedback estás buscando. Cuando aún lo estás averiguando, forzar el ciclo puede frenarte más de lo que ayuda.

El error no es elegir test-first o test-last. El error es convertirlo en una decisión religiosa en lugar de contextual. El idealista dice “siempre tests primero.” El pragmático dice “testea cuando tenga sentido.” Yo digo: tests primero cuando puedo, tests después cuando debo, pero siempre tests.

TDD es una brújula, no una jaula. Síguelo cuando puedas ver el camino. Cuando no, encuentra el camino primero y márcalo después.

Pair programming: el ideal y el overhead

El pair programming efectivo es una de las mejores prácticas que un equipo puede adoptar. Dos personas, un problema, revisión de código continua. El conocimiento se propaga, el diseño mejora, los puntos ciegos se reducen.

Ese es el ideal. Y en muchos contextos, es la decisión correcta.

Pero el pairing tiene un coste. Exige tiempo sincrónico, foco compartido y niveles de energía compatibles. En un equipo distribuido con distintas zonas horarias, encontrar ventanas de solapamiento ya es difícil. Llenarlas con sesiones de pairing deja poco espacio para trabajo individual profundo. Algunos problemas se benefician de una persona profundizando tres horas, no de dos a medio gas durante seis.

Existen múltiples patrones de pairing: Driver-Navigator, Ping-Pong, Tourist Guide. Cada uno encaja en contextos diferentes.

Los anti-patrones también importan. El Socio Silencioso que deja que el otro haga todo el trabajo. El Dictador que no suelta el teclado. El Par Filosófico que pasa toda la sesión debatiendo convenciones de nombres en lugar de escribir código.

El pairing funciona mejor cuando ambas personas están involucradas, el problema se beneficia de dos perspectivas y la sesión tiene un alcance claro. Cuando falta alguna de esas condiciones, el pairing se convierte en un ritual en lugar de una práctica. Y los rituales sin propósito son solo overhead.

Las pull requests y el pair programming no son excluyentes. Sirven necesidades diferentes. A veces la revisión asíncrona es suficiente. A veces necesitas el ida y vuelta en tiempo real. La elección pragmática depende del problema, las personas y el momento.

El objetivo del pairing no es hacer pairing. Es construir entendimiento compartido y detectar errores pronto. Si otro enfoque lo consigue en tu contexto, úsalo.

IA: de escéptico a líder de escuadrón

Hace un año, era escéptico con los asistentes de código con IA. Mi preocupación: una IA que no entiende la arquitectura, no le importa la mantenibilidad y prioriza velocidad por encima de calidad producirá código que impresiona pero se deteriora rápido. Escribí sobre esto en La IA te da velocidad, no calidad, y mantengo el mensaje central.

Mi preocupación no cambió. Lo que cambió es cómo los uso, y de lo que son capaces ahora.

La resistencia

Las reacciones de otros ingenieros me sorprenden más que la tecnología. Miedo, escepticismo, rechazo total. Lo entiendo. Yo estuve ahí. Algo en lo que invertiste años de repente lo hace una máquina, al menos en parte. Se siente personal. Pero aferrarse a cómo eran las cosas no protege el oficio. Solo retrasa tu propio crecimiento.

Un equipo, no un asistente

La mayoría de los ingenieros tratan a los agentes de IA como autocompletado con esteroides. Un asistente, un chat, un flujo de código generado. Yo empecé a tratarlos como un equipo. No un asistente parlanchín. Un escuadrón real. Uno piensa arquitectura. Otro escribe el primer borrador. Otro revisa y detecta bugs. Otro escribe tests. Cuando colaboran, el resultado no es solo más rápido. Es estructuralmente mejor.

La velocidad es la parte fácil, y todo el mundo está obsesionado con ella. La IA puede escupir toneladas de código en segundos. Sigue sin importarle la legibilidad, los casos borde o cómo se verá el código en seis meses. Tú sigues siendo quien tiene que apropiárselo, entenderlo y sentirse bien al subirlo a producción.

Antes pensaba que la IA no podía escribir código limpio. Luego lo probé en mis términos: contexto adecuado, reglas, convenciones, roles especializados, puertas de calidad. Con la configuración correcta, la IA puede escribir código realmente bueno. A veces necesita varias iteraciones, pero nosotros también.

La diferencia es que la IA llega más rápido y no se cansa entre iteraciones. Con buen contexto y restricciones claras, los resultados han sido mejores de lo que esperaba. A menudo mejores que lo que yo produciría solo bajo presión de tiempo.

Pero nada de esto funciona si no sabes cómo es una buena arquitectura. Tienes que haber leído los libros, experimentado, fallado, aprendido. Necesitas entender qué significan las decisiones de diseño de alto y bajo nivel para tu proyecto. La IA amplifica lo que tú aportas. Si traes fundamentos sólidos, obtienes resultados sólidos. Si no, obtienes basura con aspecto convincente que ni siquiera reconocerás como basura.

Seguimos siendo los responsables de mantener el sistema en buen estado. La IA nos ayuda a llegar. Pero solo si ponemos de nuestra parte.

Donde el idealismo se encuentra con la IA

La IA me hizo más idealista, no menos. Las prácticas que describí antes, TDD y pair programming, solían competir con los deadlines. Ahora ya no tienen por qué.

Me gusta practicar TDD, pero recientemente experimenté con un agente dedicado para ayudarme con tests, y es sorprendentemente bueno. Un coach de TDD que guía el ciclo red-green-refactor. Un explorer que lee el código antes de que yo lo toque. Un revisor de código limpio, un arquitecto de dominio, un revisor de React, un mantenedor de documentación. Cada uno especializado, cada uno apoyando mi forma de pensar y mi ritmo. Si se añade lógica nueva sin cobertura, el agente de TDD lo detecta. 100% de cobertura de código solía ser el tipo de objetivo que pondrías en una retro y abandonarías silenciosamente para el tercer sprint. Con un agente dedicado aplicándolo, es simplemente cómo funciona el proyecto.

Sigo practicando pair programming con personas reales para temas complejos. El ida y vuelta humano tiene una profundidad que la IA no alcanza, especialmente cuando navegas trade-offs que requieren experiencia y juicio. Pero en el día a día, siempre tengo un agente pair buddy conmigo. Le lanzo ideas, cuestiono un enfoque, discuto casos borde, exploro un diseño antes de comprometerme con él. Apoya mis pensamientos, acelera el progreso y mantiene el listón de calidad donde yo lo quiero.

El pragmático en mí solía abandonar TDD cuando los deadlines apretaban. El pragmático en mí con la configuración de IA adecuada lo mantiene funcionando.

Uso Claude para todo. Claude Code con Opus o Sonnet como programador agéntico: flujos de desarrollo completos, lectura del código, seguimiento de convenciones, ejecución de tests, creación de PRs. Claude app y Claude como coworker para la parte conversacional: brainstorming, discusiones de arquitectura, explicar código, redactar documentación. Para asistencia inline, los plugins que ya tengo en mi IDE son suficientes. Probé Copilot y Cursor, no son para mí. Claude cubre lo que necesito.

Diferentes modos para diferentes tareas. Un asistente agéntico siguiendo mis comandos de TDD es un flujo diferente a chatear sobre patrones de diseño. Ambos son útiles. Ninguno reemplaza al otro.

El mercado ahora mismo es intenso. Claude, Codex, Gemini y otros son jugadores fuertes con productos similares, y todos mejoran mes a mes. Los resultados son impresionantes y solo se aceleran. Esa es la belleza de la competencia: obliga a todos a mejorar o volverse irrelevantes, y el consumidor gana de cualquier forma. A día de hoy, Claude Code parece la opción más fuerte para cómo trabajo. Pero no tengo lealtad a una marca. Si Anthropic dejara de avanzar y un competidor fuera claramente mejor, cambiaría sin dudar. Lo que importa es la capacidad, no el logo.

Me equivoqué con la IA de la forma en que los idealistas se equivocan a menudo: medí la herramienta contra el resultado ideal y la encontré insuficiente, en lugar de medirla contra la alternativa realista.

La alternativa al desarrollo asistido por IA no es un equipo de arquitectos senior escribiendo código perfecto. Es el mismo equipo escribiendo el mismo código imperfecto, solo que más lento.

Los ingenieros que aprendan a liderar agentes en lugar de competir contra ellos tendrán una ventaja real. Y esto todavía es el principio.

La pregunta nunca fue “¿puede la IA escribir código perfecto?” Fue “¿puedo liderar a la IA para escribir mejor código, más rápido?” Y la respuesta, con la configuración adecuada, es sí.

El juego completo

Cada práctica en este post sigue el mismo patrón. La versión ideal existe en los libros. La versión pragmática existe en tu código bajo presión. Necesitas ambas.

La próxima vez que estés subiendo ese fix a las 11 de la noche, sabrás qué atajos tomaste y por qué. Ese es el juego completo. No la perfección. No la velocidad. Saber cuál debe liderar.

Construye tu Propio Equipo de Agentes

2026-02-07T00:00:00+00:00

La mayoría usa asistentes de código con IA como un único interlocutor. Abres un chat, describes lo que necesitas y obtienes una respuesta. Funciona. Pero es como contratar a un generalista para que haga de todo. Ningún equipo real funciona así.

La verdadera ventaja viene cuando organizas la IA como un equipo: onboarding, procedimientos estándar, especialistas y ejecución en paralelo.

En el post sobre MCP cubrí cómo darle acceso a tu entorno. En La IA te da velocidad, no calidad, por qué el juicio humano sigue siendo esencial. Este post cubre la pieza que falta: organizar ese acceso en un flujo coordinado.

El documento de onboarding

Todo buen equipo empieza con onboarding. Los agentes de IA necesitan lo mismo.

Reglas del proyecto

En Claude Code, el archivo CLAUDE.md en la raíz de tu proyecto es el documento de onboarding. El agente lo lee cada vez que empieza a trabajar: estructura, convenciones, guías de estilo, herramientas.

Pero CLAUDE.md es solo el punto de entrada. Puedes dividir las reglas en archivos enfocados bajo .claude/rules/, cada uno apuntando a partes específicas de tu código mediante patrones glob. El agente no solo conoce tus convenciones, está limitado por ellas. Límites de capas, patrones de nomenclatura, dirección de dependencias. Todo versionado junto al código que protegen.

modules/*/Domain/**/*.php: Sin imports de framework, sin dependencias de infraestructura, solo PHP plano.
modules/*/Infrastructure/**/*.php: Los controladores se mantienen delgados, los modelos Eloquent en su sitio.
resources/js/**/*.tsx: Convenciones de componentes, estrictez TypeScript, patrones de estilos.

Cada archivo de reglas tiene un scope limitado a los archivos que le importan. Las reglas de dominio no se activan cuando se edita un controlador.

Preferencias personales

También existe un ~/.claude/CLAUDE.md global que aplica en todos tus proyectos. El archivo del proyecto dice cómo funciona este código. El global dice cómo trabajo yo.

Un buen CLAUDE.md es como un buen documento de onboarding. Cuanto mejor sea, menos te repites.

Procedimientos operativos estándar

Todos los equipos tienen flujos recurrentes que viven en wikis, runbooks, o en la cabeza de alguien. Cuando viven en la cabeza de alguien, son frágiles.

Los comandos slash personalizados en .claude/commands/ convierten estos flujos en instrucciones ejecutables. Cada comando es un archivo markdown que describe un procedimiento de varios pasos. En uno de mis proyectos, cada comando de creación empieza con tests. TDD incorporado al procedimiento, no dejado a la disciplina.

Creación (TDD-first):

/create-module: Genera un módulo hexagonal con capas de dominio, aplicación e infraestructura.
/create-entity: Entidades de dominio con value objects y archivos de test.
/create-use-case: Handlers de command/query con tests mockeados.
/create-page: Páginas React con factories y smoke tests.

Calidad y flujo de trabajo:

/refactor-check: Analiza código contra principios SOLID.
/test: Ejecuta la suite con filtrado por módulo.
/fix: Auto-aplica correcciones de linting y análisis estático.
/gh-issue: De issue de GitHub a implementación y PR en un solo comando.

Los comandos convierten conocimiento tribal en instrucciones ejecutables. Lo que antes era “pregúntale a Sara cómo creamos un módulo nuevo” se convierte en un comando que cualquiera puede ejecutar.

Especialistas, no generalistas

Los comandos codifican cómo hace las cosas tu equipo. Pero hay otra capa: skills y agentes.

Skills como bases de conocimiento

Los skills son conocimiento estructurado del que el agente se nutre. En uno de mis proyectos, tengo skills para principios SOLID, arquitectura hexagonal, flujos TDD y patrones React/Inertia.

Las reglas restringen: “no hagas esto, haz siempre aquello.” Los skills enseñan: “este es el patrón, estos son los errores comunes.” Las reglas son barandillas. Los skills son experiencia.

Agentes como roles especializados

En lugar de un generalista, defines agentes especializados con un rol claro, herramientas específicas, e incluso un modelo diferente según la complejidad del trabajo. No necesitas a tu arquitecto más senior para renombrar una variable.

Explorer (modelo ligero): Solo lectura. Busca en el código, encuentra archivos, entiende la estructura.
Revisor de código limpio (modelo intermedio): Violaciones SOLID, code smells, inconsistencias de nomenclatura.
Coach de TDD (modelo intermedio): Guía el ciclo red-green-refactor. Edita archivos y ejecuta tests.
Revisor de React (modelo intermedio): Estructura de componentes, estrictez TypeScript, accesibilidad.
Arquitecto de dominio (modelo más capaz): Decisiones de arquitectura, límites de módulos, patrones DDD.

El modelo adecuado para el trabajo adecuado. Rápido y barato para exploración. Capaz y riguroso para arquitectura.

Hazlos trabajar juntos

Aquí la metáfora del equipo se vuelve literal. Un solo agente es útil. Múltiples agentes desde un plan compartido es un equipo.

Subagentes vs equipos de agentes

Hay dos modelos de coordinación distintos, y elegir el correcto importa.

Los subagentes se ejecutan dentro de una misma sesión. Hacen trabajo enfocado y devuelven resultados al agente principal. No pueden hablar entre sí. El agente principal lo gestiona todo.

Los equipos de agentes son diferentes. Cada miembro es una sesión de Claude Code independiente con su propia ventana de contexto. Se comunican a través de un buzón compartido, reclaman tareas de una lista compartida y se coordinan sin pasar por un cuello de botella central.

La arquitectura tiene cuatro componentes:

Team lead: la sesión principal que crea el equipo y orquesta el trabajo
Teammates: instancias separadas de Claude Code, cada una con tareas específicas
Lista de tareas: elementos de trabajo compartidos con seguimiento de dependencias. Las tareas bloqueadas se desbloquean automáticamente cuando sus dependencias se completan
Buzón: mensajería directa entre agentes, incluyendo broadcasts a todo el equipo

Los subagentes son trabajadores que reportan. Los equipos de agentes son colaboradores que piensan juntos.

Usa subagentes cuando solo importa el resultado. Usa equipos de agentes cuando los miembros necesitan compartir hallazgos, cuestionar al resto y coordinarse por su cuenta.

Empezando con equipos de agentes

Los equipos de agentes son aún experimentales. Actívalos añadiendo esto a ~/.claude/settings.json:

{
 "env": {
 "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
 }
}

Crear un equipo es conversacional. Describes lo que quieres: “Crea un equipo de agentes para refactorizar el módulo de auth. Genera tres miembros: uno para cambios de API backend, uno para componentes frontend, uno para escribir tests.” Claude configura la lista de tareas, genera los miembros y coordina el trabajo.

Puedes ver el equipo en un mismo proceso (un terminal, navega con Shift+Up/Down) o dividido en paneles (cada miembro en una ventana tmux o iTerm2 separada). Usa Shift+Tab para activar el modo delegado, que restringe al lead a solo coordinación.

Advertencia sobre consumo de tokens. Los equipos de agentes queman tokens rápidamente. Cada miembro tiene su propia ventana de contexto, y cada mensaje entre agentes suma. Empieza con tareas de investigación y revisión antes de pasar a implementación. Tres miembros explorando en paralelo cuesta aproximadamente 3x. Asegúrate de que el paralelismo se paga a sí mismo.

Los miembros cargan automáticamente el contexto del proyecto (CLAUDE.md, servidores MCP, skills) pero no heredan el historial de conversación del lead. Al crear un miembro, sé específico sobre qué archivos revisar y qué restricciones aplican. Un prompt de creación vago produce trabajo vago.

Primero planificar, después ejecutar

Describes el problema. El agente explora el código, mapea dependencias y propone un enfoque antes de cambiar nada. Lo apruebas, modificas o rechazas. Pensar primero, programar después.

Con equipos de agentes, la aprobación de plan permite exigir que los miembros diseñen su enfoque antes de implementar. El agente trabaja en modo solo lectura hasta que el lead aprueba. Puedes moldear el criterio del lead: “solo aprueba planes que incluyan cobertura de tests” o “rechaza planes que modifiquen el esquema de base de datos.”

El modo delegado restringe al lead a solo coordinación. Sin él, el lead a veces empieza a implementar en lugar de esperar a los miembros. El modo delegado lo mantiene centrado en la orquestación, no en la ejecución.

Hipótesis competitivas

Cuando la causa raíz no está clara, un solo agente tiende a encontrar una explicación plausible y dejar de buscar. Los equipos de agentes combaten esto haciendo que los miembros sean adversarios. Cada uno investiga su propia teoría mientras intenta refutar las de los demás.

La investigación secuencial sufre de anclaje: una vez que se explora una teoría, todo lo posterior está sesgado hacia ella. Con múltiples investigadores cuestionándose mutuamente, la teoría que sobrevive tiene más probabilidades de ser la causa raíz real.

Dimensiona las tareas para trabajo en paralelo

No todo el trabajo se beneficia del paralelismo. La pregunta clave: ¿pueden los miembros trabajar de forma independiente?

Demasiado pequeñas: el overhead de coordinación supera el beneficio
Demasiado grandes: los miembros trabajan demasiado tiempo sin revisión, aumentando el esfuerzo desperdiciado
El punto justo: unidades autocontenidas que producen un entregable claro. Una función, un archivo de tests, una revisión

Tener 5-6 tareas por miembro mantiene a todos productivos. Que cada miembro sea dueño de archivos diferentes. Sin aislamiento, dos editando el mismo archivo lleva a sobreescrituras. Los worktrees cambian esto.

Imagina una funcionalidad que toca backend y frontend. Después de planificar:

Un agente de backend genera la capa de dominio: entidades, value objects, interfaces de repositorio, handlers. Todo hexagonal, todo test-first.
Un agente de frontend construye la página React, componentes, hooks y factories. Cada uno sigue sus propias reglas y opera de forma independiente.

No se pisan porque el plan ya definió los límites. Propiedad clara. Sin conflictos de merge. Sin esperas.

Aislamiento con worktrees

La mayor fricción con agentes en paralelo eran los conflictos de archivos. Dos agentes editando el mismo archivo significaba sobreescrituras y trabajo perdido. Los git worktrees eliminan esto dándole a cada agente su propia copia de trabajo del repositorio.

Inicia Claude Code con --worktree para ejecutarlo en un worktree aislado. Múltiples sesiones, mismo repositorio, sin pisarse. Añade --tmux para lanzarlo en su propia sesión tmux.

claude --worktree --tmux

Los subagentes también soportan worktrees. Pídele a Claude que use worktrees para sus agentes, o añade isolation: worktree en el frontmatter de tu agente personalizado para que sea el comportamiento por defecto.

---
isolation: worktree
---

La app de escritorio tiene la misma funcionalidad: activa el modo worktree en la pestaña Code.

Para control de versiones no-git (Mercurial, Perforce, SVN), puedes definir worktree hooks para obtener los mismos beneficios de aislamiento sin necesidad de usar git.

Los worktrees convierten “propiedad clara de archivos” de una restricción de planificación en una garantía de infraestructura. Los agentes pueden solaparse en los mismos archivos sin pisarse.

Revisión tras la ejecución

Tras la implementación, los agentes de revisión toman el relevo. En lugar de un revisor que lo pille todo, tienes especialistas: violaciones SOLID, patrones de componentes, calidad de tests, límites de módulos.

Un solo agente es un asistente. Múltiples agentes trabajando desde un plan compartido es un equipo.

Tú sigues siendo el lead

Por muy bien configurados que estén, los agentes trabajan para ti. Tú estableces los estándares, escribes las reglas, revisas los planes y apruebas el resultado antes de que salga. Puedes enviar un mensaje a cualquier miembro mientras trabaja para redirigir su enfoque o añadir restricciones. Si alguien va por mal camino, intervienes directamente.

Como escribí en La IA te da velocidad, no calidad, el código que produce el agente es tu responsabilidad. Más paralelismo sin supervisión es solo más caos, más rápido.

Puertas de calidad

Los hooks y git hooks actúan como la última red de seguridad. En mi setup, nada se commitea a menos que los linters pasen, el análisis estático esté limpio, los tests sean verdes y la cobertura supere el 90%. El agente no puede saltarse esto. Nadie puede.

Los equipos de agentes añaden sus propios hooks: TeammateIdle mantiene activos a los miembros inactivos, TaskCompleted impide completar tareas prematuramente. Políticas automatizadas que nadie puede saltarse.

Los git hooks ejecutan linters, análisis estático y tests antes de cada commit. Claude Code añade sus propios hooks (.claude/hooks/): comandos shell que se disparan ante eventos del agente como llamadas a herramientas o escritura de archivos.

.claude/settings.json controla lo que los agentes pueden ejecutar. Autoriza herramientas y comandos específicos, deniega operaciones destructivas. Controlas no solo lo que los agentes saben (reglas, skills) sino lo que pueden hacer (permisos). Las reglas definen la cultura. Los permisos definen los límites.

La base importa

Los agentes te ayudan a llegar más rápido, pero ese “allí” tiene que estar bien definido. Si no sabes cómo es la arquitectura hexagonal, los agentes no la van a descubrir por ti.

No construyes todo esto el primer día. Empiezas con un CLAUDE.md. Luego notas que repites instrucciones, y escribes un comando. Un agente rompe una convención, y añades una regla. El setup crece orgánicamente a partir de fricción real. Cada adición resuelve un problema que realmente tuviste. Lo mismo con los equipos de agentes: empieza con tareas que no requieran escribir código. Revisa un PR, investiga una librería, analiza un bug. Aprende el modelo de coordinación antes de implementar en paralelo.

Si quieres un punto de partida, preparé laravel-claude-toolkit: un starter kit de Laravel con reglas, comandos, skills, agentes, hooks y permisos ya configurados.

No solo estás usando IA. Estás construyendo un equipo. Y como cualquier equipo, la calidad de su resultado refleja la calidad de su liderazgo.

Recursos

Claude Code | claude.com
Claude Code: Agent Teams | claude.com
Claude Code Tips: Workflow Boosters | rfrolov.me

Memorias del subsuelo

2026-02-04T00:00:00+00:00

El hombre del subsuelo no es alguien con quien querrías tomarte una cerveza. Amargado, contradictorio, dolorosamente consciente de sí mismo. Conoce sus defectos y se niega a cambiar. Ese es el punto.

El libro tiene dos partes. La primera es una diatriba filosófica contra la razón, el progreso y la idea de que la gente siempre actúa en su propio beneficio. La segunda cuenta una historia del pasado del narrador que revela hasta dónde llega su autosabotaje.

Libre albedrío y rencor

El narrador sostiene que la gente no solo quiere lo que le conviene. A veces quiere caos. A veces quiere sufrir. No porque tenga sentido, sino porque demuestra que es libre.

“Lo que el hombre quiere es simplemente una elección independiente, cueste lo que cueste esa independencia y a donde quiera que conduzca.”

Rechaza la utopía de una sociedad perfecta construida sobre el interés propio racional. Los humanos no son máquinas. Destruyen su propia felicidad solo para demostrar que pueden.

El muro y la inacción

El hombre del subsuelo está paralizado de tanto pensar. Ve cada ángulo, cada consecuencia, cada interpretación posible. Y no hace nada. Se cree más consciente que los “hombres de acción” que actúan sin cuestionarlo todo.

“Les juro, señores, que ser demasiado consciente es una enfermedad, una verdadera y completa enfermedad.”

Algo incómodamente reconocible. La trampa de la parálisis por análisis. Saber demasiado puede volverse excusa para no hacer nada.

El episodio de Liza

La segunda parte muestra al narrador conociendo a Liza, una joven prostituta. Le da un discurso apasionado sobre su futuro, sobre dignidad y redención. Por un momento parece casi noble. Luego ella aparece en su puerta y él se derrumba. Su crueldad vuelve. No puede aceptar una conexión genuina porque amenaza la imagen que ha construido de sí mismo.

Dostoyevski en su momento más incómodo. La brecha entre lo que decimos y lo que hacemos. Cómo el orgullo herido puede envenenarlo todo.

Lo esencial

La racionalidad no explica del todo el comportamiento humano. La gente actúa contra sus propios intereses por rencor, aburrimiento o necesidad de sentirse libre.
La autoconciencia excesiva puede volverse prisión. En algún momento hay que actuar a pesar de la incertidumbre.
El deseo de control y el miedo a ser vulnerable destruyen relaciones.
El sufrimiento no siempre debe eliminarse. A veces la gente se aferra a él como prueba de que existe.

No es un libro fácil ni agradable. Pero se te mete bajo la piel. Anticipa el existencialismo por décadas y desafía la cómoda idea de que el progreso y la razón nos salvarán.

Dinero roto

2026-01-17T00:00:00+00:00

Lyn Alden cuenta la historia del dinero desde una mirada tecnológica. Analiza desde sistemas basados en materias primas hasta monedas fiat modernas y alternativas como Bitcoin.

¿Qué hace que el dinero funcione?

Alden empieza por lo básico: ¿qué convierte algo en dinero? Lo descompone en propiedades clave: durabilidad, divisibilidad, portabilidad, escasez. Y muestra cómo distintas formas de dinero han destacado o fallado en cada una.

La idea central: el dinero es tecnología. Y como toda tecnología, evoluciona. Lo que funcionó en civilizaciones antiguas no necesariamente sirve en un mundo digital y conectado.

El experimento fiat

Una de las secciones más reveladoras explica cómo llegamos al sistema fiat actual. Alden documenta la transición del oro al dinero emitido por gobiernos. Un experimento de apenas 50 años que ha traído inflación persistente e inestabilidad monetaria.

“Muchas monedas se diluyen rápidamente, lo que devalúa los ahorros y salarios de miles de millones de personas.”

Lo ilustra con ejemplos reales: Nigeria, Egipto, Brasil y otras naciones en crisis monetaria. Para quienes viven en economías desarrolladas, estas historias son una advertencia de a dónde puede llevar la expansión monetaria sin control.

Los efectos de red del dinero

Alden trae una perspectiva única: es ingeniera convertida en analista financiera. Usa la teoría de redes para explicar por qué ciertas formas de dinero ganan sobre otras. El dinero, como internet, se beneficia de los efectos de red. Cuanta más gente lo usa, más útil se vuelve.

Esto explica por qué el dólar domina el comercio global y también por qué Bitcoin ha crecido tan rápido partiendo de cero.

Bitcoin como solución

El libro construye lógicamente hacia Bitcoin como posible solución a los sistemas monetarios rotos. Pero Alden no hace promoción ciega. Evalúa Bitcoin frente al oro y otras criptomonedas, reconociendo sus limitaciones.

Su análisis tiene base ingenieril: ¿Cuáles son las propiedades reales de Bitcoin? ¿Cómo se compara con formas históricas de dinero sólido? ¿Qué problemas resuelve y cuáles quedan pendientes?

Para cerrar

“Dinero roto” destaca porque no asume que ya compartes su premisa. Alden construye el caso paso a paso: algo falla en cómo funciona el dinero hoy. Traza las raíces históricas del problema y evalúa posibles soluciones.

Aunque no termines convencido, saldrás entendiendo mucho mejor los sistemas monetarios y por qué importan.

MCP: Dándole a tu Agente IA el Contexto Adecuado

2026-01-11T00:00:00+00:00

Los asistentes de código con IA modernos son muy buenos entendiendo contexto. Modelos como Claude Opus con ventanas de contexto amplias (unos 200k tokens) pueden tener porciones sustanciales de tu código en mente, razonar sobre arquitectura y mantener coherencia en conversaciones largas. No el proyecto entero en codebases grandes, pero sí lo suficiente para trabajar bien.

Pero entender no es lo mismo que acceder.

La IA puede razonar sobre el esquema de tu base de datos si lo pegas. Puede sugerir cambios a archivos que compartes. Conoce patrones del código que le muestras. La limitación no es la inteligencia, sino el alcance.

Ahí entra MCP.

Lo que MCP habilita

La IA moderna puede entender tu código cuando lo compartes. Pero entender y actuar son cosas distintas.

Muchos asistentes integrados en IDEs como VS Code Copilot o Cursor ya acceden a los archivos de tu proyecto mediante su propio indexado. El acceso a archivos no es nuevo. Lo que MCP aporta es estandarización. En lugar de que cada herramienta construya su propia integración, MCP ofrece un protocolo común. Configuras un servidor una vez, y cualquier cliente compatible con MCP puede usarlo. Es portable, configurable, y va más allá de archivos: bases de datos, APIs y herramientas personalizadas.

MCP transforma a la IA de interlocutor a participante activo en tu entorno de desarrollo.

Con MCP le das a la IA acceso directo a herramientas y recursos. Puede leer archivos, ejecutar comandos, consultar bases de datos, obtener documentación. La inteligencia siempre estuvo ahí. MCP le da manos.

Qué es realmente MCP

MCP es un protocolo, no un producto. Un estándar abierto que define cómo los agentes de IA pueden conectarse a fuentes de datos y herramientas externas. Piensa en ello como un puente entre el modelo de IA y tu entorno de desarrollo.

La arquitectura es simple: los servidores MCP exponen capacidades y los clientes de IA las consumen. Claude Desktop y Claude Code soportan MCP oficialmente, y cada vez más herramientas adoptan el protocolo.

Por ejemplo, en Claude Code puedes añadir servidores a un archivo .mcp.json en la raíz de tu proyecto. Claude Code lee este archivo al abrir el proyecto e inicia los servidores configurados automáticamente:

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"]
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": { "GITHUB_TOKEN": "tu-token" }
 },
 "postgres": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-postgres"],
 "env": { "DATABASE_URL": "postgresql://localhost/mydb" }
 }
 }
}

Cada servidor le da a la IA diferentes capacidades:

filesystem: Leer y navegar los archivos de tu proyecto. La IA puede explorar tu código, verificar patrones existentes y entender la estructura de directorios antes de sugerir cambios.
github: Acceder a issues, pull requests y metadatos del repositorio. Pídele a la IA que resuma los issues abiertos, revise comentarios de PRs o entienda en qué trabaja tu equipo.
postgres: Consultar tu base de datos directamente. La IA puede inspeccionar tu esquema, ejecutar consultas de lectura y entender tu modelo de datos sin que copies definiciones de tablas.

Distintas herramientas, mismo protocolo. Configuras una vez, y cualquier cliente compatible con MCP puede usar estos servidores.

Dónde destaca MCP

Trabajando con tu código

El beneficio más inmediato es el acceso al sistema de archivos. La IA puede navegar tu proyecto, leer archivos fuente, entender tu estructura de directorios. Cuando sugiere código, puede verificar patrones existentes primero.

La integración con Git va más allá. La IA puede ver tu historial de commits, entender qué cambió recientemente y sugerir modificaciones alineadas con la evolución de tu código.

El acceso al esquema de base de datos significa que la IA entiende tu modelo de datos. No hace falta explicar relaciones entre tablas o tipos de columnas. Ve la estructura y genera consultas que funcionan de verdad.

Documentación y conocimiento

Conecta tu documentación interna y la IA conocerá las decisiones de tu equipo. Especificaciones de API, documentos de arquitectura, guías de código. Todo disponible como contexto.

Aquí es donde MCP empieza a notarse. La IA ya no genera código genérico. Genera código que encaja en tu proyecto.

La mejor asistencia de IA viene de entender no solo qué construyes, sino cómo lo construye tu equipo.

Integraciones externas

La integración con GitHub permite que la IA lea issues, entienda discusiones de PRs y vea el contexto más amplio de en qué trabaja tu equipo. Slack u otras herramientas de comunicación pueden aportar aún más contexto sobre decisiones en curso.

Las integraciones personalizadas te permiten conectar herramientas internas específicas de tu flujo de trabajo. El protocolo es extensible por diseño.

Usando MCP efectivamente

MCP amplifica lo que conectes. Si tu documentación está desactualizada, la IA usará información desactualizada. Si tu código es desordenado, la IA aprenderá patrones desordenados.

Es el efecto espejo que mencioné en La IA te da velocidad, no calidad. La IA refleja el contexto que le das. Buen contexto da resultados útiles. Mal contexto produce basura que suena convincente.

Darle a la IA acceso a tu código no reemplaza tu responsabilidad de mantenerlo. Hace que la buena higiene sea más valiosa.

Algunas prácticas que ayudan:

Conecta solo lo que la IA necesita. Más contexto no siempre es mejor. Contexto enfocado sí.
Mantén tu documentación actualizada. Si la IA lee tus docs, esos docs importan más que antes.
Revisa tu configuración MCP de vez en cuando. A medida que tu proyecto evoluciona, también debería hacerlo tu configuración de contexto.
Empieza pequeño. Uno o dos servidores. Ve qué funciona. Expande desde ahí.

La seguridad también importa. Sé intencional sobre lo que expones. Los servidores MCP pueden acceder a información sensible. Trátalos como cualquier otra decisión de control de acceso.

Lo que viene

MCP es la base. Pero el ecosistema construye encima.

Flujos de trabajo agénticos. Herramientas como Claude Code y Cursor funcionan en “modo agente” donde la IA planifica y ejecuta tareas de múltiples pasos de forma autónoma. Lee archivos, hace cambios, ejecuta tests, corrige errores. Los servidores MCP son las manos. El bucle del agente es el cerebro que decide qué hacer.

Skills y comandos personalizados. Claude Code introdujo skills: comandos slash personalizados que encadenan herramientas MCP en flujos reutilizables. /deploy, /test, /review. Los defines una vez y se convierten en parte de tu toolkit de desarrollo.

Protocolo A2A. El protocolo Agent-to-Agent de Google. Mientras MCP conecta IA con herramientas, A2A conecta agentes de IA entre sí. Múltiples agentes especializados colaborando en tareas complejas. Un agente escribe código, otro lo revisa, un tercero ejecuta tests.

El patrón es claro: la IA está pasando de asistente a colaborador. De responder preguntas a ejecutar flujos de trabajo. MCP le dio a la IA acceso a tu entorno. Lo que viene es IA que sabe usar ese acceso de forma autónoma.

La pregunta está cambiando de “¿a qué puede acceder la IA?” a “¿qué debería decidir la IA por su cuenta?”

El juicio humano no desaparece. Se mueve hacia arriba. En lugar de revisar cada línea que escribe la IA, diseñamos el contexto y los límites que moldean lo que produce.

Ese sigue siendo nuestro trabajo. Y vale la pena hacerlo bien.

Cómo Funciona Bitcoin

2025-12-22T00:00:00+00:00

Este post explica cómo funciona Bitcoin por dentro. Si buscas entender por qué importa, empieza con Fundamentos de Bitcoin.

Para los técnicamente curiosos.

La Blockchain

El problema del doble gasto

El dinero digital tiene un problema fundamental: ¿cómo evitas que alguien copie sus monedas y las gaste dos veces? Los sistemas tradicionales lo resuelven con una autoridad central (bancos, PayPal) que rastrea quién posee qué. El avance de Bitcoin fue resolver esto sin ningún intermediario.

La solución: un libro mayor compartido que todos pueden verificar pero nadie controla.

Cómo funciona

Bitcoin usa una blockchain: una cadena de bloques donde cada bloque contiene transacciones y enlaza al bloque anterior a través de hashes criptográficos.

Una función hash toma cualquier entrada y produce una huella digital de tamaño fijo. Cambia un bit de la entrada y la salida cambia por completo. Esto hace evidente cualquier manipulación. Bitcoin usa SHA-256, que produce una salida de 256 bits.

Cada bloque contiene:

Una lista de transacciones
Un hash del encabezado del bloque anterior
Una solución proof-of-work (más abajo)

Antes de entrar en un bloque, las transacciones esperan en el mempool. Los mineros seleccionan de este pool, priorizando las que pagan más comisiones. Puedes verlo en tiempo real en mempool.space.

Cada nodo guarda una copia completa de la blockchain. No hay un solo servidor que hackear ni una base de datos central que corromper. Para cambiar el historial, tendrías que reescribir bloques en la mayoría de nodos del mundo.

Un bloque tiene dos partes: el encabezado (80 bytes) y el cuerpo (transacciones).

El encabezado contiene:

Versión: Versión del protocolo
Hash del bloque anterior: Enlaza a la cadena
Raíz Merkle: Hash de todas las transacciones en el bloque
Marca de tiempo: Cuándo se creó el bloque
Objetivo de dificultad: Qué tan difícil era el puzzle
Nonce: La solución que encontraron los mineros

Los árboles Merkle organizan las transacciones de forma eficiente. Cada transacción se hashea, luego los pares de hashes se combinan y hashean de nuevo, hasta llegar a un único hash raíz. Esto permite probar que una transacción existe en un bloque sin descargar todas las demás. Muy útil para wallets ligeras.

El peso del bloque se mide en bytes virtuales (vB). El límite es 4 millones de unidades de peso, aproximadamente 1-1.5 MB de datos por bloque.

Transacciones y criptografía

El modelo UTXO

Bitcoin no usa cuentas con saldos. En su lugar, rastrea Salidas de Transacciones No Gastadas (UTXOs). Piensa en ellas como monedas digitales de varios tamaños.

Cuando recibes bitcoin, obtienes un UTXO. Cuando gastas, consumes UTXOs completos como entradas y creas nuevos como salidas. Si tienes un UTXO de 1 BTC y quieres enviar 0.3 BTC, gastas el UTXO entero y creas dos salidas: 0.3 BTC para el destinatario y unos 0.7 BTC de vuelta para ti (menos las comisiones).

Tu “balance” es la suma de todos los UTXOs que puedes gastar.

Criptografía de clave pública

Las transacciones de Bitcoin usan criptografía de clave pública:

Clave privada: Un número secreto de 256 bits. Demuestra la propiedad.
Clave pública: Se deriva matemáticamente de la clave privada. Se comparte públicamente.

Cuando envías bitcoin, firmas la transacción con tu clave privada. Esta firma demuestra que posees los UTXOs sin revelar la clave privada. Cualquiera puede verificar la firma usando tu clave pública.

Dinero programable

Bitcoin no es solo efectivo digital. Tiene su propio lenguaje de programación llamado Script. Cada transacción incluye un pequeño programa que define las condiciones para gastarla.

La mayoría de transacciones usan scripts simples: “quien pueda demostrar que posee esta clave pública puede gastar estas monedas.” Pero Script permite mucho más: wallets multifirma que requieren varias claves, transacciones con bloqueo temporal que no pueden gastarse hasta cierta fecha, y condiciones complejas combinando múltiples requisitos.

Esto convierte a Bitcoin en dinero programable. Para profundizar en Script y tipos de direcciones, mira Dinero Programable.

Bitcoin usa ECDSA (Algoritmo de Firma Digital de Curva Elíptica) con la curva secp256k1. Se eligió esta curva por su eficiencia y porque no la diseñó ninguna agencia gubernamental (a diferencia de las curvas NIST), lo que reduce preocupaciones sobre puertas traseras.

Una clave privada es un entero aleatorio de 256 bits. La clave pública se deriva multiplicando ese número por un punto generador en la curva. Fácil de calcular en un sentido, prácticamente imposible de revertir.

La firma de transacciones implica:

Hashear los datos de la transacción
Crear una firma usando la clave privada
Incluir la firma y clave pública en la transacción

Las banderas SIGHASH controlan qué partes de una transacción cubre la firma:

SIGHASH_ALL: Firma todas las entradas y salidas (más común)
SIGHASH_NONE: Firma solo las entradas
SIGHASH_SINGLE: Firma una salida específica
Estas pueden combinarse con ANYONECANPAY para casos de uso avanzados

Minería y consenso

¿Cómo se pone de acuerdo una red descentralizada sobre qué transacciones son válidas? Mediante minería proof-of-work.

El puzzle

Los mineros compiten por encontrar un número (el nonce) que, combinado con el encabezado del bloque y hasheado, produce un resultado por debajo de un valor objetivo. Es como tirar dados hasta sacar un número menor que 100, pero con 2^256 resultados posibles.

El trabajo es:

Difícil de encontrar: Requiere billones de intentos
Fácil de verificar: Una comprobación de hash prueba la solución

Esta asimetría es clave. Cualquiera puede verificar un bloque al instante, pero crearlo requiere trabajo computacional real.

Por qué importa

La minería sirve para tres propósitos:

Asegura la red: Reescribir la historia significa rehacer todo el trabajo de hash
Emite nuevas monedas: Siguiendo un calendario predecible (halving cada 210.000 bloques)
Procesa transacciones: Incluyéndolas en el registro permanente

Cada 2016 bloques (unas 2 semanas), la red ajusta la dificultad para mantener tiempos de bloque de unos 10 minutos. ¿Se suma más hashpower? Los puzzles se vuelven más difíciles. ¿El hashpower baja? Los puzzles se vuelven más fáciles.

Explora los pools de minería y hashrate en mempool.space/mining.

Cálculo de dificultad: El objetivo es un número de 256 bits. Un hash de bloque válido debe estar por debajo de este objetivo. Objetivo más bajo = puzzle más difícil. La red ajusta cada 2016 bloques según cuánto tardaron realmente esos bloques frente a los 20.160 minutos esperados.

Hashrate y seguridad: La seguridad de Bitcoin viene del coste de reescribir el historial. Con unos 500 EH/s (exahashes por segundo) de hashrate, atacar la red requeriría controlar la mayoría del hashpower. Eso supone miles de millones en hardware y electricidad, y además el ataque haría colapsar el valor del activo.

Incentivos económicos: Los mineros gastan recursos reales (electricidad, hardware). Solo obtienen beneficio si juegan según las reglas. Un minero que crea bloques inválidos desperdicia su trabajo porque los nodos los rechazan. Esto alinea el beneficio individual con la seguridad de la red.

Ataques del 51%: Si un atacante controlara la mayoría del hashpower, en teoría podría hacer doble gasto minando una cadena alternativa. Pero la economía hace esto irracional para grandes valores: el ataque destruye el valor de lo que intentas robar.

Direcciones y wallets

Las direcciones de Bitcoin se derivan de las claves públicas. Han evolucionado diferentes formatos:

P2PKH: Direcciones legacy que empiezan con “1”
P2SH: Direcciones script que empiezan con “3”
P2WPKH: Direcciones SegWit nativas que empiezan con “bc1q”
P2TR: Direcciones Taproot que empiezan con “bc1p”

Para detalles técnicos de cada tipo, ve Dinero Programable.

Wallets

Una wallet gestiona tus claves y construye transacciones. No contiene tus monedas: las monedas existen en la blockchain. La wallet contiene las claves que demuestran que puedes gastarlas.

Wallets calientes se conectan a internet. Convenientes para uso diario, más vulnerables. Ejemplos: apps de móvil, extensiones de navegador.

Wallets frías permanecen offline. Más seguras para ahorros. Ejemplos: hardware wallets (Ledger, Trezor), paper wallets.

Wallets HD y frases semilla

Las wallets modernas son Deterministas Jerárquicas (HD). Una semilla maestra genera claves ilimitadas en una estructura de árbol. Haces backup de la semilla una vez y puedes recuperar todo.

BIP-39 define la frase semilla de 12 o 24 palabras que usa la mayoría de wallets. Estas palabras codifican entropía que deriva todas tus claves. Pierdes la frase, pierdes el acceso. Cualquiera con la frase controla los fondos.

Nunca almacenes frases semilla digitalmente. Escríbelas. Guárdalas de forma segura offline.

¿Cómo de grande es el espacio de claves de BIP-39 en realidad? He construido seed-hunter, una herramienta educativa de código abierto en Go que intenta hacer fuerza bruta sobre una semilla de 12 palabras contra la red real de Bitcoin. Registra cada intento y muestra el progreso en vivo con ETAs que abarcan de 10²⁹ a 10³⁹ años. Un ladrón comprobando un billón de frases semilla por segundo desde el Big Bang habría completado el 0.000_000_008% de la búsqueda hasta ahora. La idea no es romper Bitcoin, sino hacer las matemáticas viscerales y obvias: la termodinámica, no solo la computación, prohíbe el ataque.

La red

Bitcoin es una red peer-to-peer, sin servidores centrales. Los nodos se conectan entre sí, comparten transacciones y bloques, y hacen cumplir las reglas de forma independiente.

Tipos de nodos

Nodos completos descargan y validan cada bloque y transacción. Hacen cumplir todas las reglas de consenso y no confían en nadie. Ejecutar un nodo completo significa verificar todo por ti mismo.

Clientes SPV (ligeros) solo descargan encabezados de bloque. Confían en que los mineros ya validaron las transacciones. Menos seguridad, pero funcionan en móviles y dispositivos de baja potencia.

Nodos de minería son nodos completos que también compiten por crear nuevos bloques.

Cómo se propagan las transacciones

Cuando transmites una transacción:

Tu wallet la envía a los nodos conectados
Cada nodo valida y reenvía a sus pares
En segundos, la transacción alcanza la mayor parte de la red
Los mineros la incluyen en sus bloques candidatos

Los bloques se propagan de forma similar. Cuando un minero encuentra un bloque válido, se extiende por la red en segundos.

Descubrimiento de pares: Los nodos se encuentran mediante semillas DNS (direcciones hardcodeadas que devuelven IPs de nodos activos) y compartiendo direcciones de pares con otros nodos conectados.

Protocolo gossip: La información se propaga mediante mensajes “inv” (inventario). Un nodo anuncia que tiene algo nuevo, y los pares lo solicitan si les interesa. Esto evita desperdiciar ancho de banda con datos duplicados.

Bloques compactos (BIP-152) aceleran la propagación de bloques. Como los nodos ya tienen la mayoría de transacciones en su mempool, los bloques pueden transmitirse solo como el encabezado más IDs cortos de transacciones.

Seguridad y confirmaciones

Por qué importan las confirmaciones

Cuando una transacción se incluye en un bloque, tiene 1 confirmación. Cada bloque posterior añade otra confirmación.

Más confirmaciones = más difícil de revertir. Para deshacer una transacción confirmada, un atacante tendría que minar una cadena alternativa más rápido que la red honesta. Cada bloque hace esto exponencialmente más difícil.

Guías generales:

0 confirmaciones: Transacción transmitida pero aún no en un bloque. Puede ser doble gastada.
1 confirmación: En un bloque. La reversión requiere hashpower significativo.
6 confirmaciones: Estándar para grandes cantidades. Reversión prácticamente imposible.

El whitepaper de Satoshi incluye el cálculo de probabilidad. Con un atacante que controla una fracción q del hashpower:

Si q < 0.5: La probabilidad de alcanzar disminuye exponencialmente con cada confirmación
A 6 confirmaciones con q = 0.1 (10% hashpower): Probabilidad de éxito < 0.1%

La regla de “6 confirmaciones” asume un atacante bien financiado con hashpower sustancial pero minoritario. Para transacciones más pequeñas, muchas veces bastan menos confirmaciones.

La finalidad en Bitcoin es probabilística, no absoluta. Pero tras suficientes confirmaciones, la probabilidad de reversión se acerca a cero para cualquier atacante realista.

Alineación de incentivos

Bitcoin no es solo tecnología ingeniosa. Es un sistema donde el interés propio de cada participante fortalece la red.

Mineros invierten en hardware y electricidad. Solo obtienen beneficio produciendo bloques válidos. Hacer trampas desperdicia su inversión porque los nodos rechazan bloques inválidos al instante.
Nodos hacen cumplir las reglas para proteger sus propios fondos. Un operador de nodo que acepta transacciones inválidas devalúa su propio bitcoin. El interés propio los convierte en validadores honestos.
Usuarios pagan comisiones para que sus transacciones se procesen. Comisiones más altas significan confirmación más rápida. Esto crea demanda de espacio de bloque y financia la seguridad de la red.
Desarrolladores contribuyen a software que ellos mismos usan. Los bugs perjudican sus propias tenencias. Las mejoras benefician a todos, incluyéndoles.
Holders se benefician de la seguridad y adopción de la red. Cuanto más seguro y útil se vuelve Bitcoin, más valiosos son sus fondos. Tienen incentivos para apoyar el ecosistema.

Sin coordinador central. Sin necesidad de confianza. Todos actúan en su propio interés, y el sistema beneficia a todos.

“No confíes, verifica.” Cualquiera puede ejecutar un nodo y verificar cada transacción, cada bloque, cada regla. No hace falta confiar en bancos, gobiernos, ni siquiera en otros usuarios de Bitcoin. Las matemáticas se demuestran solas.

Escalabilidad: Lightning Network

La capa base de Bitcoin procesa unas 7 transacciones por segundo. Es así por diseño: mantener la descentralización requiere bloques lo suficientemente pequeños para que cualquiera pueda verificar. Pero esto limita cuántas transacciones puede manejar.

Lightning Network resuelve esto con una segunda capa construida sobre Bitcoin. Permite:

Pagos instantáneos: Sin esperar confirmaciones de bloque
Comisiones casi nulas: Fracciones de céntimo
Alta capacidad: Millones de transacciones por segundo

Lightning funciona abriendo “canales de pago” entre partes. Las transacciones dentro de un canal ocurren off-chain, al instante. Solo la apertura y cierre de canales requieren transacciones on-chain. Puedes visualizar la topología de la red y estadísticas en mempool.space/lightning.

La capa base de Bitcoin proporciona seguridad y liquidación final. Lightning proporciona velocidad y escala. Diferentes herramientas para diferentes trabajos.

Si quieres ejecutar tu propio nodo Lightning y tomar control total de tus pagos, escribí una guía sobre cómo Ejecutar tu nodo LN en una Raspberry Pi.

Los canales de pago usan direcciones multifirma 2-de-2. Ambas partes deben firmar para mover fondos. Esto crea una cuenta compartida de la que ninguna puede robar.

HTLCs (Contratos Hash Time-Locked) permiten pagos multi-salto. El mecanismo:

Alice quiere pagar a Carol a través de Bob
Carol genera un secreto y da a Alice el hash
Alice crea un HTLC: “Bob recibe el pago si revela el secreto en 24 horas”
Bob crea un HTLC similar con Carol
Carol revela el secreto a Bob, reclamando el pago
Bob usa el mismo secreto para reclamar de Alice

Si alguien no coopera, el timelock expira y los fondos vuelven. El secreto viaja hacia atrás, los pagos viajan hacia adelante.

Watchtowers monitorean la blockchain buscando intentos de trampa. Si tu contraparte intenta transmitir un estado antiguo del canal, el watchtower puede penalizarla, incluso mientras estás offline.

El panorama general

Lo que hace notable a Bitcoin no es ningún componente individual, sino cómo encajan todos en un sistema que se refuerza a sí mismo.

La criptografía demuestra la propiedad sin autoridades de confianza. El proof-of-work hace costoso reescribir el historial. Los incentivos económicos convierten la codicia individual en seguridad colectiva. La descentralización elimina puntos únicos de fallo. Y la oferta fija crea escasez digital por primera vez en la historia.

Cada pieza sostiene a las demás. Quita una, y el sistema se debilita. Juntas, crean algo que nunca había existido: dinero que no puede inflarse, transacciones que no pueden censurarse, y propiedad que no puede confiscarse.

Sin bancos. Sin gobiernos. Sin terceros de confianza. Solo matemáticas, código, y una red global de nodos que hacen cumplir las mismas reglas.

Si eso te importa o no depende de dónde vivas y cuánto confíes en tus instituciones. Pero la opción ya existe. Y nadie puede quitártela.

La profundidad técnica de Bitcoin va mucho más allá de lo que cabe en un post. Aquí hay temas que vale la pena explorar si quieres profundizar:

SegWit (Testigo Segregado) fue la actualización de Bitcoin de 2017 que movió los datos de firma fuera de la estructura principal de la transacción. Arregló la maleabilidad de transacciones (un bug que impedía Lightning), introdujo el peso de bloque para un uso más eficiente del espacio, y lo hizo todo manteniendo compatibilidad con nodos antiguos.

Taproot y Schnorr llegaron en 2021, actualizando la criptografía de Bitcoin. Las firmas Schnorr son más pequeñas y permiten agregación (varias firmas se convierten en una). Taproot hace que las condiciones de gasto complejas se vean idénticas a los pagos simples on-chain, mejorando tanto la privacidad como la eficiencia.

Soft forks vs hard forks: ¿Cómo se actualiza Bitcoin sin una autoridad central? Los soft forks añaden nuevas reglas que los nodos antiguos aún aceptan. Los hard forks cambian las reglas de formas que los nodos antiguos rechazan. Entender esta distinción explica por qué Bitcoin evoluciona lentamente y por qué los cambios controvertidos son raros.

Mecánica de comisiones: El mercado de comisiones tiene más matices que “paga más, confirma más rápido”. Replace-By-Fee (RBF) te permite aumentar la comisión de una transacción atascada. Child-Pays-For-Parent (CPFP) permite a los destinatarios acelerar pagos entrantes gastándolos con comisiones altas.

Timelocks: Bitcoin puede bloquear fondos hasta que se cumplan ciertas condiciones. CLTV (CheckLockTimeVerify) bloquea hasta una altura de bloque o marca de tiempo específica. CSV (CheckSequenceVerify) bloquea por un tiempo relativo tras la confirmación. Estas primitivas permiten canales Lightning, esquemas de herencia e intercambios atómicos.

Transacciones coinbase: La única forma en que bitcoin nuevo entra en circulación. Cada bloque comienza con una transacción especial que paga al minero la recompensa del bloque más todas las comisiones. Estas monedas recién acuñadas no pueden gastarse durante 100 bloques, una regla que protege contra reorganizaciones de la cadena.

Cuanto más profundo vas, más encuentras.

Capítulo 30: Diciembre, 2025

2025-12-09T00:00:00+00:00

Nueve Ramas

Once años después

Diciembre de 2025. Afuera hace frío. De ese que te limpia la cara y te obliga a despertar.

Once años después, sigo pensando en aquel chaval de veintiuno que cogió un vuelo a Lübeck sin entender lo que iba a costar. No hablo del idioma —un inglés para sobrevivir y nada de alemán—. Hablo de todo lo demás: la soledad, el miedo, la libertad, las personas que te salvan sin saberlo.

No era valentía. Era urgencia.

Me fui de mi ciudad porque quedarme ya no era una opción. No había futuro allí. Solo un pasado que necesitaba olvidar. Y Alemania, entonces, era una puerta que no podía dejar pasar.

En Lübeck estuve seis meses trabajando por trescientos euros al mes. Tiraba de los ahorros de mi trabajo en Murcia.

Pobre, pero feliz.

Conociendo gente estupenda, buscando cada rincón para aprender, expandir horizontes, practicar idiomas.

Tras esos primeros meses decidí que tenía que moverme. La empresa donde empecé era la típica que te pagaba lo mínimo para explotarte al máximo, con tecnologías obsoletas. Sentía que si no me movía, acabaría volviéndome obsoleto yo también.

Así que, tras tres meses de búsqueda intensa, encontré trabajo en Berlín y me mudé con lo que tenía. Los primeros días dormí en el sofá de Alberto y Maricarmen, unos amigos del pueblo del coro donde estuve un verano años antes.

De ahí en adelante, todo fue aventura. A una velocidad que nunca hubiera imaginado si no hubiera salido de mi ciudad.

En 2015 empecé a escribir como forma de comunicarme con mis hermanos en la distancia. Lo que comenzó como pensamientos sueltos terminó convirtiéndose en un diario de dos años.

Escribí en abril: «Echo de menos a mi familia. Aunque los veré en menos de treinta días, estoy empezando a hacerme a la idea de verlos dos veces al año. Y, la verdad, se hace complicado. Ser el mayor de toda una tropa hace que, sin pretenderlo, uno sea responsable. Necesitamos ser ejemplos».

Once años después, esas palabras siguen siendo ciertas. Nos vemos una o dos veces al año: en Navidad y en las fiestas de mayo. He aprendido a saborear cada minuto cuando estamos juntos. No siempre es fácil. Pero el tiempo es el último igualador; da igual el color de las prendas ideológicas o políticas. Lo que más valoro es el esfuerzo, el ahorro, el trabajo duro. Eso nos enseña a apreciar lo que conseguimos.

Nueve empresas diferentes. Siete de ellas en Alemania. He tropezado y me he levantado, siempre desde la cordura sin llegar a disparates.

He conseguido crecer tanto en lo personal como en lo profesional, abriendo todo tipo de horizontes. Estoy orgulloso de la persona en la que me he convertido.

Pero nada de esto tendría sentido sin vosotros.

Y para entender el presente, a veces hay que mirar al pasado. Aunque duela.

De donde venimos

No voy a mentir: tuvimos una juventud complicada. Una juventud que dejó marcas en todos nosotros. Cada uno las lleva a su manera, algunas más visibles que otras.

Pero aquí seguimos. De pie.

Mamá se fue demasiado pronto.

Cincuenta y ocho años tendría hoy. Cuarenta y nueve cuando escribí «Números», aquel 25 de mayo de 2016. Treinta y siete cuando se fue.

Yo tenía once años.

No recuerdo cuándo fue la última vez que dije «mamá». Solo recuerdo su pelo rizado y su amable sonrisa tras el marco de la puerta a altas horas de la noche. Sin tiempo para despedirse. Sin tiempo para nada.

Papá se quedó solo con ocho críos. La hermana mayor tenía trece años. Y la menor, dos semanas.

La vida le obligó a tirar para adelante como pudo. Y lo hizo. No siempre bien, pero lo hizo.

Años después llegó el castillo. Aquel dúplex donde los siete acabamos relegados al garaje, cual patio trasero. Con cerrojo en la puerta. Prohibido subir a las habitaciones principales salvo para comer o dormir.

Las disputas. Los enfrentamientos. Las tempestades.

Maricarmen fue enviada a estudiar lejos. Yo era el siguiente objetivo. Papá desbordado sin saber qué hacer.

Aquello fue un infierno del que apenas quiero acordarme.

Hasta que un día volvimos al piso donde nos habíamos criado con mamá. Nuestra casa. ¿Sabéis qué es despertarte un fin de semana, ver que es de día y que está lloviendo, y poder quedarte en la cama? Un recuerdo de alegría que jamás olvidaré.

Pero eso ya lo sabéis. Lo vivisteis conmigo. Apenas guardo recuerdos claros de aquellos años de adolescencia. Mi mente hizo bien su trabajo: borró cuanto pudo para ayudarme a sanar. Quizá algún día vuelvan. Quizá sea mejor que no.

Papá, nuestra relación fue difícil.

La época y el contexto en los que nos tocó vivir y enfrentarnos no nos ayudaron. Hubo años de silencio, de rencor acumulado, de palabras que no se dijeron y otras que se dijeron de más.

Pero a día de hoy la situación parece haberse tranquilizado. Llegamos a perdonarnos. Volvemos a hablarnos de vez en cuando. Y eso, después de todo lo vivido, es más de lo que muchos consiguen.

No es perfecto, pero es real. Y lo real tiene más valor que cualquier ideal imposible.

De un pasado tan turbio, me siento afortunado de no haber acabado en ningún otro camino que no sea este: el mío. Y cuando digo «el mío», me refiero al nuestro. Porque todos venimos del mismo sitio, de las mismas paredes, del mismo cielo de Caravaca.

Nueve ramas

Ocho hermanos del mismo padre y de la misma madre. Ocho ramas que crecieron juntas. Y una novena que vino después. Nueve en total. Del mismo árbol, cada una buscando su propio sol.

Maricarmen, la hermana mayor, que tuvo que aprender a ser mamá bien temprano. Cuando pudo, se enganchó a tierras belgas y allí está ahora, con dos hijos y un futuro por hacer.

Nunca le agradecí lo suficiente por aquellos años en los que cargó con responsabilidades que no le correspondían. Era una niña que cuidaba a niños. Y lo hizo lo mejor que pudo.

Ahora le toca construir su vida. La que eligió. La que se merece.

Juan, quizá el que más ha sufrido. El pasado le jugó mala suerte y ha tenido que aprender a base de muchos palos. La vida ha sido especialmente injusta con él en muchos aspectos.

Y yo también lo fui. De pequeños era abusón con él. Le hice daño y eso es algo que llevo conmigo.

Ojalá sepa perdonarme. Ojalá no se le olvide que estoy aquí para lo que necesite.

Por suerte, desde hace bien poco, encontró su lugar. Lo tiene aún todo por delante. Pocos tienen la capacidad de levantarse después de caer tantas veces.

Jesús, el que parece de temperamento más tranquilo. Aprendió a sobrepasar las tempestades del castillo sin llamar demasiada atención. Me llena de orgullo ver quién es y en lo que se ha convertido: ponente en conferencias internacionales y una ayuda fundamental en los proyectos de código abierto que tenemos juntos.

Vivimos cerca en Berlín y verle de vez en cuando me recuerda lo que significa tener familia. Disfruto mucho cuando quedamos para dar paseos por parques inmensos, andando durante horas hasta que se va la luz.

Gracias por esos momentos. Hablar contigo en persona y saber que estás ahí es un regalo.

Ángel, el profesor de matemáticas. De los más inteligentes de la familia, sin lugar a dudas. De pequeño, sufrió una operación en la que perdió casi por completo un oído. Pero se superó, como siempre ha hecho.

Tranquilo, humilde, nunca le gustó llamar la atención. Y siempre está ahí cuando un hermano le necesita.

Y eso vale más que cualquier título.

Un claro ejemplo de compromiso y pasión por su trabajo. Supo aprovechar las oportunidades conforme le vinieron. La prueba de que el esfuerzo da estupendos frutos.

Lola, luchadora y sensible a partes iguales. Es imposible negar lo vivido, lo mal que lo pasó de niña. Ella es quizá una de quienes más difícil lo han tenido.

Pero hay que verla hoy.

Aunque tengamos pensamientos diferentes en algunos aspectos, podemos entendernos a la perfección cuando se trata de humanidad, de ayuda, de familia. Y eso es lo que vale.

De la niña que sufrió ha nacido una mujer que ayuda a otros a sufrir menos.

Eso es convertir el dolor en propósito.

Cosme, el pequeño que ahora programa como los grandes. También tuvo una infancia difícil sin comprender lo que ocurría ni lo que le rodeaba. Todos fuimos desapareciendo cuando aún era un niño. Esa falta de afecto dejó huella.

La empatía cuesta cuando, de pequeño, no la recibes. Pero está aprendiendo. Y eso es lo que cuenta.

Por suerte encontró la pasión donde yo también la encontré: en el software. Pude guiarle como hermano mayor, ayudarle con todo mi ser, así como lo hice con Jesús y luego haría con Juan.

Verle crecer profesionalmente ha sido una de mis mayores satisfacciones.

Anica, la más pequeña, la más lista. Ha sabido convertir la rabia en fuerza. Pilla y espabilada como pocas. Y pensar que no hace tanto odiaba el deporte…

Quizá fue mi pasión por el boxeo lo que conseguí transmitirle. Hoy es entrenadora de gimnasio, compite en halterofilia y corre diez kilómetros de vez en cuando.

Me emociona verla competir y ayudar a los demás. Disfruto mucho ir con ella a dar un paseo de hermanos o a hacer compras en Lidl.

Esos momentos sencillos valen mucho.

Transmitir pasión es una de las mejores herencias que uno puede legar. Y ella la ha hecho suya.

Y por último está Antonio. Otra rama, pero del mismo padre. Del mismo árbol al fin y al cabo.

Apenas nos hemos visto un par de veces en la vida. Tuvo la suerte de llegar cuando las aguas ya estaban más calmadas. Tiene toda la vida por delante para estudiar, crecer como profesional, y ser quien quiera ser.

Y si algún día le pica la curiosidad por aquellos pensamientos pasados, tiene un libro que publiqué en 2017 esperándole.

Nueve ramas buscando su propio sol. Nueve formas de sobrevivir al mismo pasado. Nueve maneras de seguir adelante.

Los chachos

Pero la familia no es solo los hermanos.

También están los que han estado ahí siempre, en lo bueno y en lo malo: los chachos de Caravaca. Mi tío Cosme y mi tía Angustias.

Siempre habéis estado ahí. Para mí y para todos mis hermanos. Para hablar. Para escuchar. Para decir lo que necesitábamos oír.

También estuvisteis en aquella época del castillo. No voy a entrar ahí. Solo quiero deciros que vuestro cariño en aquellos años me ayudó muchísimo.

Pero esta vez, prefiero quedarme con otro recuerdo.

Recuerdo cuando me echaron de mi primera empresa en Berlín, tras poco más de un año. De un día para otro. Algo me olía, pero no quería creerlo. Mirando atrás, yo también metí la pata más de una vez.

«Te adocenaste», me dijo el chacho Cosme por teléfono al llegar a mi piso.

Esa palabra se me quedó grabada. Tenía razón. Me había acomodado.

Con mis ahorros podría haber aguantado unos meses. ¿Pero y después? ¿Y si no encontraba trabajo? La incertidumbre me obligó a mirarme de frente y reconocer mis errores.

Tocaba enfocarse y surfear las olas. A las dos semanas de buscar —levantándome a las ocho y sin soltar el portátil hasta las cinco—, encontré trabajo.

No podía darme por rendido. Y no lo hice.

Y ese es solo un recuerdo de tantos. Las llamadas largas. Los consejos sin pedir. La sensación de tener a alguien que siempre escucha.

Gracias, chachos. Por estar ahí. Por ser ese ancla que siempre ha estado en Caravaca esperando.

Os quiero.

Anna-Lena

Y luego está ella. La que apareció cuando menos lo esperaba.

Nos conocimos en un bar de cervezas, entre desconocidos, una noche cualquiera.

Desde que te vi entrar, estuvimos hablando durante horas hasta que te tuviste que ir.

Luego empezamos a ir juntos al cine, a otros bares, a pasear. Y al final nos empezamos a ver casi a diario. Un año después decidimos vivir juntos.

En febrero de 2026 haremos ocho años. Ocho años construyendo algo juntos, día a día, sin prisas pero sin pausas.

Gracias por estar ahí. Por aguantarme. Por quererme como soy. Por ser mi hogar en Berlín.

Porque al final, eso es lo que importa: tener a alguien con quien compartir el camino.

Fundamentos de Bitcoin

2025-11-21T00:00:00+00:00

¿Qué harías si tu cuenta bancaria fuera congelada mañana? Sin aviso, sin explicación, sin acceso a tu propio dinero.

Esto no es hipotético. En 2022, Canadá congeló cuentas bancarias de personas que donaron a una protesta. En 2015, los griegos solo podían retirar 60€ por día de los cajeros. En Argentina, Turquía y Líbano, la gente vio sus ahorros perder la mitad de su valor en meses.

Bitcoin existe porque estas cosas pasan. Para entenderlo hay que volver a lo básico: qué es el dinero, por qué importa, y cómo encaja Bitcoin en todo esto.

No se requiere conocimiento técnico. Solo curiosidad.

Una breve historia del dinero

El dinero es un acuerdo social. Un trozo de papel, una moneda de oro o un número en una pantalla tiene valor porque todos aceptamos que lo tiene. Ese acuerdo es lo que hace posible el comercio.

A lo largo de la historia, el dinero ha evolucionado:

Intercambio directo: Intercambiar bienes por bienes. “Te doy mi pescado por tu pan.”
Cosas usadas como dinero: Conchas, sal, ganado. Valiosas porque eran útiles o difíciles de encontrar.
Metales preciosos: Oro y plata. Difíciles de encontrar, duraderos, fáciles de dividir y transportar.
Papel moneda respaldado por oro: Recibos representando oro almacenado en bóvedas.
Dinero del gobierno: Papel respaldado solo por una promesa del gobierno. ¿Por qué funciona? Porque los gobiernos te exigen pagar impuestos en su moneda, y eso obliga a todos a usarlo.

El dinero es una forma de almacenar y transferir valor. Cuanto mejor realice estas funciones, mejor sirve como dinero.

¿Qué hace buen dinero? Estas propiedades:

Difícil de crear: No puede ser fácilmente fabricado o falsificado
Duradero: No se deteriora con el tiempo
Divisible: Puede dividirse en piezas más pequeñas
Fácil de mover: Simple de transportar y enviar
Fácil de verificar: Simple de comprobar si es real

El oro cumple bien con la mayoría. El papel moneda es fácil de mover y dividir, pero falla en ser difícil de crear: los gobiernos pueden imprimir tanto como quieran. Bitcoin, como veremos, cumple con todas.

¿Qué es Bitcoin?

Bitcoin es dinero digital que funciona sin bancos, gobiernos ni ninguna autoridad central. Lo creó en 2009 alguien (o algún grupo) bajo el seudónimo Satoshi Nakamoto. Nadie sabe quién es realmente.

El primer bloque de Bitcoin (el Bloque Génesis) contiene un mensaje oculto: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” Este titular del periódico The Times hacía referencia a la crisis financiera de 2008. No fue aleatorio: era una marca de tiempo y una declaración de propósito. Bitcoin nació como respuesta a los rescates bancarios y la manipulación monetaria.

Bitcoin se construye sobre décadas de trabajo de criptógrafos y activistas de la privacidad. Si te interesa conocer a las personas e ideas que lo hicieron posible, escribí sobre Los Cypherpunks y su visión de la privacidad digital.

En su núcleo, Bitcoin es:

Un protocolo: Un conjunto de reglas que las computadoras siguen para acordar quién posee qué
Una red: Miles de computadoras en todo el mundo ejecutando el software de Bitcoin
Una moneda: Unidades de cuenta llamadas bitcoins (BTC), divisibles hasta 8 decimales

No hay ninguna empresa detrás de Bitcoin. Sin CEO, sin oficinas centrales, sin soporte al cliente. Es software de código abierto que cualquiera puede ejecutar, inspeccionar o mejorar.

Dinero sólido

Escasez

Solo habrá 21 millones de bitcoins. Lo garantiza el código del protocolo, verificado por cada nodo en la red. Ningún gobierno, ningún comité, ninguna reunión de emergencia puede cambiar esto.

Compáralo con el dinero del gobierno. Los bancos centrales pueden (y lo hacen) crear dinero cuando quieren. El dólar estadounidense ha perdido más del 95% de su poder adquisitivo desde 1913. El Euro, la Libra, el Yen: todos siguen el mismo patrón de perder valor poco a poco.

En un mundo de impresión de dinero infinita, un límite máximo matemáticamente aplicado es revolucionario.

A Bitcoin le llaman “oro digital” porque comparte la escasez del oro, pero es más fácil de almacenar, dividir y transferir. Puedes enviar mil millones de dólares en Bitcoin a cualquier parte del mundo en minutos, por unos pocos dólares en comisiones. Intenta hacer eso con lingotes de oro.

Protección contra la inflación

Cuando los gobiernos imprimen dinero, el valor del dinero existente disminuye. Eso es la inflación. Tus ahorros compran menos con el tiempo, aunque sigan intactos en tu cuenta bancaria.

A la inflación le llaman “impuesto oculto” porque transfiere riqueza de los ahorradores a quienes reciben el dinero nuevo primero (normalmente gobiernos y bancos). Escribí más sobre esto en Entendiendo los Impuestos.

El calendario de emisión de Bitcoin es fijo y predecible. Los nuevos bitcoins se crean mediante minería, a un ritmo que se reduce a la mitad cada cuatro años aproximadamente. Alrededor del 2140 se habrán creado los 21 millones. Sin sorpresas, sin decisiones políticas de imprimir más.

Libertad y soberanía

Auto-custodia

Con Bitcoin puedes guardar tu propio dinero. No una promesa de un banco, no un saldo en los libros de otro. Propiedad real, asegurada por claves criptográficas que solo tú controlas.

“No tus llaves, no tus monedas.”

Esta frase captura una verdad fundamental. Cuando depositas dinero en un banco, ya no lo posees. Tienes un derecho contra el banco. Si el banco congela tu cuenta, quiebra o decide que violaste sus términos de servicio, tu acceso desaparece.

Con Bitcoin, no hay botón de congelar. No hay cuenta que cerrar. No hay términos de servicio que violar. Te conviertes en tu propio banco.

Sin permisos y sin fronteras

A Bitcoin no le importan las fronteras, los horarios bancarios ni tu historial crediticio. Puedes enviar dinero a cualquiera con conexión a internet, en cualquier parte del mundo, a cualquier hora.

Banca tradicional:

Horario: Lunes-Viernes, 9-5 (quizás)
Transferencias internacionales: 3-5 días hábiles
Comisiones: Porcentaje de la transferencia + comisiones fijas
Requisitos: DNI, prueba de domicilio, cuenta en buen estado

Bitcoin:

Horario: 24/7/365
Transferencias globales: ~10 minutos a una hora
Comisiones: Basadas en tamaño de datos, no cantidad enviada
Requisitos: Una dirección Bitcoin (gratis, instantánea, sin DNI)

Resistencia a la censura

Ninguna autoridad central controla Bitcoin. Ninguna entidad puede detener una transacción ni revertir un pago. Una vez confirmada, es definitiva.

Esto importa para quienes viven bajo gobiernos opresivos, enfrentan presión política o simplemente quieren privacidad financiera. Importa para donaciones a causas controversiales, para periodistas que protegen sus fuentes, para cualquiera que valore la libertad financiera.

La libertad financiera no es solo ser rico. Es tener control sobre tu propio dinero, sin importar quién seas o dónde vivas.

Historias reales

Estos no son casos extremos:

En diciembre de 2010, WikiLeaks publicó cables diplomáticos clasificados de EE.UU. En días, Visa, Mastercard, PayPal y Bank of America cortaron todo procesamiento de pagos.

WikiLeaks perdió el 95% de sus ingresos de la noche a la mañana. En 2011, empezaron a aceptar Bitcoin. Fue uno de los primeros casos de uso importantes para la criptomoneda. El bloqueo financiero destinado a silenciarlos en cambio demostró el valor de Bitcoin como dinero resistente a la censura.

Leer artículo completo →

En marzo de 2013, los bancos de Chipre tomaron el 47.5% de todos los depósitos superiores a 100.000€ para rescatarse a sí mismos. Sin consentimiento, sin aviso. El dinero en el banco fue simplemente confiscado para salvar el sistema bancario.

El precio de Bitcoin se duplicó en las semanas siguientes. El rescate de Chipre fue una llamada de atención: tu balance bancario es un pagaré, y cuando los bancos fallan, tú eres quien paga.

Leer artículo completo →

En junio de 2015, Grecia cerró sus bancos durante tres semanas. Los retiros de cajeros se limitaron a 60€ por día. Los ciudadanos no podían acceder a su propio dinero. La crisis de deuda mostró a los europeos que los depósitos bancarios no son tan seguros como asumían.

El interés en Bitcoin se disparó en Grecia durante la crisis. Fue una advertencia temprana: incluso en países "estables", tu acceso al dinero puede cortarse de la noche a la mañana.

Leer artículo completo →

Entre 2016 y 2019, la inflación alcanzó el 53.000.000%. Los salarios se volvían inútiles en días. La gente no podía comprar comida, medicina o bienes básicos. Quienes convirtieron sus ahorros a Bitcoin antes del colapso preservaron su riqueza.

Quienes confiaron en el sistema bancario perdieron todo. Bitcoin se convirtió en una línea de vida. No para especular, sino para sobrevivir.

Leer artículo completo →

En 2019, los bancos libaneses empezaron a congelar depósitos. Para 2020, la gente no podía acceder a sus propios ahorros. La lira perdió el 90% de su valor. Los retiros de cajeros se limitaron a cantidades ínfimas. No fue una medida temporal. Los bancos simplemente no tenían el dinero.

Quienes habían convertido a Bitcoin antes del colapso aún podían acceder a su riqueza. Quienes confiaron en los bancos descubrieron que "tu dinero" no era realmente tuyo.

Leer artículo completo →

Durante las protestas pro-democracia de 2019-2020, los activistas de Hong Kong enfrentaron vigilancia financiera. Los bancos podían congelar cuentas de manifestantes conocidos. Las donaciones a través de canales tradicionales podían ser rastreadas.

Bitcoin ofreció una forma de financiar el movimiento sin dejar rastro para las autoridades. Los manifestantes usaron crypto para recibir apoyo internacional mientras protegían sus identidades. La privacidad financiera se convirtió en una herramienta de resistencia.

Leer artículo completo →

Después de las disputadas elecciones de 2020, Bielorrusia estalló en protestas. El régimen de Lukashenko respondió con violencia y represión financiera. Las cuentas bancarias de activistas, periodistas y ONGs fueron congeladas.

El KGB monitoreaba todas las transferencias. Un fondo de solidaridad llamado BYSOL recaudó más de $2 millones en Bitcoin y los distribuyó directamente a manifestantes que perdieron sus trabajos o enfrentaron persecución. El único método de pago que las autoridades no podían controlar.

Leer artículo completo →

El Banco Central prohibió los exchanges de crypto en febrero de 2021 y ordenó a los bancos cerrar cuentas de cualquiera que tratara con criptomonedas. El objetivo era detener la adopción de Bitcoin. Salió mal.

El trading peer-to-peer aumentó un 27% en los meses siguientes a la prohibición. Los nigerianos simplemente se movieron a plataformas descentralizadas. La naira continuó perdiendo valor mientras Bitcoin seguía funcionando. No puedes prohibir las matemáticas.

Leer artículo completo →

La lira turca ha perdido más del 80% de su valor frente al dólar desde 2018. Cada crisis monetaria dispara un pico en el trading de Bitcoin. En 2021, Turquía prohibió los pagos con crypto, pero los volúmenes de trading solo aumentaron.

El gobierno no puede impedir que la gente proteja sus ahorros. Cuando la lira se desploma, las búsquedas de Bitcoin se disparan. Los turcos no están especulando. Están sobreviviendo.

Leer artículo completo →

En septiembre de 2021, El Salvador se convirtió en el primer país en hacer Bitcoin moneda de curso legal. El gobierno del presidente Bukele instaló cajeros Bitcoin en todo el país, e incluso empezó a minar BTC usando energía geotérmica de volcanes. Los críticos predijeron un desastre.

En cambio, el turismo aumentó, los costos de remesas cayeron, y el país ganó atención global. Una pequeña nación se convirtió en un laboratorio de Bitcoin.

Leer artículo completo →

Cuando los Talibán tomaron el control en agosto de 2021, los bancos se congelaron. Las transferencias internacionales se detuvieron. Las mujeres, prohibidas de trabajar, perdieron acceso a ingresos. Pero algunas mujeres afganas habían aprendido sobre Bitcoin antes del colapso.

Podían recibir pagos del extranjero, almacenar valor que el régimen no podía confiscar, y mantener independencia financiera. En un país donde las mujeres no pueden abrir cuentas bancarias, Bitcoin se convirtió en una herramienta de resistencia silenciosa.

Leer artículo completo →

Cuando Rusia invadió, la ayuda tradicional era demasiado lenta. Los bancos estaban saturados, las transferencias bancarias tardaban días. Pero en horas después de publicar direcciones Bitcoin en Twitter, las donaciones llegaron de todo el mundo. Para marzo de 2022, Ucrania recibió más de $100 millones en crypto.

Los fondos fueron directamente a chalecos antibalas, suministros médicos y equipos de comunicación. Sin burocracia, sin intermediarios, sin retrasos.

Leer artículo completo →

En febrero de 2022, el gobierno invocó la Ley de Emergencias para congelar cuentas bancarias de personas que donaron a las protestas de camioneros. Sin orden judicial necesaria. Más de 200 cuentas fueron congeladas de la noche a la mañana. Pero las donaciones en Bitcoin siguieron llegando.

Los organizadores distribuyeron 14+ BTC directamente a los manifestantes. El gobierno no pudo tocar esos fondos. En 2024, un tribunal dictaminó que los congelamientos fueron inconstitucionales. La lección: el dinero custodiado puede ser usado como arma.

Leer artículo completo →

Después de que Rusia invadió Ucrania en 2022, las sanciones occidentales cortaron a los bancos rusos de SWIFT. De repente, los rusos en el extranjero no podían acceder a su dinero. Muchos recurrieron a crypto, no para evadir sanciones, sino para sobrevivir.

Mientras tanto, los ucranianos usaron Bitcoin para recibir donaciones y preservar ahorros. La misma tecnología sirvió a personas en ambos lados de un conflicto, basándose en sus necesidades individuales. Bitcoin no elige bandos.

Leer artículo completo →

Argentina sufrió 211% de inflación en 2023 bajo décadas de políticas de gobierno grande. Luego Javier Milei asumió el cargo. Redujo a la mitad los ministerios, despidió 40.000 empleados públicos, y terminó con la financiación monetaria. Resultado: la inflación cayó a 117% en 2024, luego a 31% a finales de 2025, la más baja en siete años. El PIB creció 7.6% en Q2 2025, el más fuerte en dos décadas.

La pobreza cayó del 57% al 32%. Gobierno más pequeño, principios de dinero sólido. La adopción de Bitcoin sigue alta, los argentinos aprendieron a no confiar en ninguna moneda que no puedan verificar ellos mismos.

Leer artículo completo →

Los trabajadores migrantes envían $700 mil millones a casa cada año. Los servicios tradicionales como Western Union toman 6-10% en comisiones. Para un trabajador enviando $200, eso son $20 que desaparecen. Dinero que su familia necesita desesperadamente.

Bitcoin y Lightning Network transfieren valor a través de fronteras por centavos, liquidando en minutos en lugar de días. Empresas como Bitso procesaron $8 mil millones en remesas crypto en 2023. Transferencias más baratas significan más comida en la mesa.

Leer artículo completo →

En enero de 2024, la SEC aprobó ETFs de Bitcoin por primera vez. En meses, la inversión institucional se disparó un 400%. A finales de 2024, los inversores profesionales tenían $27.4 mil millones en ETFs de Bitcoin, más del 26% del AUM total. Solo el IBIT de BlackRock alcanzó $50 mil millones.

Bitcoin ya no era solo para early adopters. Wall Street lo llamó "año cero de la adopción institucional". El activo que los bancos una vez desestimaron ahora está en fondos de pensiones.

Leer artículo completo →

Cuando las importaciones de efectivo a Gaza fueron bloqueadas en 2024, la infraestructura bancaria colapsó. Las transferencias tradicionales cobraban más del 30%, si funcionaban. Bitcoin se convirtió en una línea de vida. Un voluntario envió $123.000 en BTC que compraron comida, agua y construyeron refugios para familias desplazadas.

Un taxista llamado Yusef recibió $48k en donaciones Bitcoin y construyó 100 tiendas. Cuando los bancos fallan, Bitcoin sigue funcionando. Sin permiso necesario.

Leer artículo completo →

El 6 de marzo de 2025, el presidente Trump firmó una orden ejecutiva estableciendo una Reserva Estratégica de Bitcoin, un "Fort Knox digital". La reserva tiene ~200.000 BTC de activos incautados, con política de nunca vender.

EE.UU. había perdido $17 mil millones vendiendo bitcoin incautado demasiado temprano. Ahora lo mantienen. Pakistán anunció su propia reserva semanas después. Naciones que una vez desestimaron Bitcoin ahora compiten por acumularlo.

Leer artículo completo →

María Corina Machado ganó el Premio Nobel de la Paz 2025 por luchar contra la dictadura venezolana. Su campaña funciona con Bitcoin porque "las transferencias bancarias se bloquean, pero las donaciones de bitcoin no pueden ser incautadas". Con el bolívar caído un 98% en una década e inflación del 8.000%+, Bitcoin se convirtió en "un medio vital de resistencia".

Prometió que una Venezuela democrática abrazaría Bitcoin en sus reservas nacionales. Dinero de libertad para una luchadora por la libertad.

Leer artículo completo →

Objeciones comunes

“Se usa para el crimen.” También el efectivo. La diferencia: Bitcoin deja un registro permanente y rastreable. La blockchain es una herramienta forense. La mayoría de los criminales prefieren dólares.
“Es demasiado volátil.” Cierto a corto plazo. Pero si amplías el zoom, Bitcoin ha sido el activo con mejor rendimiento de la última década. La volatilidad baja conforme crece la adopción. No inviertas dinero que necesites el mes que viene.
“Desperdicia energía.” La minería de Bitcoin usa electricidad para asegurar una red de un billón de dólares. Mucha viene de energía varada (quema de gas, exceso hidro) que de otra forma se desperdiciaría. La pregunta real: ¿vale la pena ese coste energético a cambio de soberanía financiera? El aire acondicionado usa más.
“Es demasiado tarde para comprar.” La gente decía esto a $100, $1.000, $10.000 y $100.000. Si Bitcoin alcanza aunque sea una fracción de la capitalización de mercado del oro, aún hay margen de crecimiento.

Advertencias honestas

Bitcoin no es perfecto. Ten en cuenta:

La auto-custodia requiere responsabilidad. Pierde tu frase semilla, pierde tus fondos. Sin soporte al cliente.
Irreversibilidad. Sin contracargos. ¿Enviaste a la dirección equivocada? Perdido.
Curva de aprendizaje. Wallets, claves, comisiones, trading P2P. Cuanto más aprendes, más soberanía ganas. Los exchanges con KYC son más fáciles, pero vienen con condiciones regulatorias.
La privacidad requiere esfuerzo. La blockchain es transparente, no anónima. La verdadera privacidad requiere aprender a usar Bitcoin correctamente.
Compensaciones de escalabilidad. La capa base es lenta por diseño. Lightning añade velocidad pero también complejidad.

Ninguno de estos son obstáculos insuperables. Son compensaciones. Cuanto más aprendes, menos limitaciones enfrentas.

Bitcoin hoy

Ya no es solo teoría.

Adopción institucional

ETFs de Bitcoin de EE.UU. aprobados en 2024, trayendo miles de millones en dinero institucional (fuente)
Strategy tiene más de 660.000 BTC como tesorería corporativa, inspirando a otros (fuente)
Grandes bancos ahora ofrecen custodia y trading de Bitcoin a clientes
Fondos de pensiones y gestores de activos están añadiendo Bitcoin a sus carteras

Adopción global

República Centroafricana adoptó Bitcoin como moneda de curso legal en 2022 (fuente)
Suiza permite pagos de impuestos en Bitcoin en el Cantón de Zug desde 2021 (fuente)
Mercados emergentes lideran en adopción de base: Vietnam, Filipinas, Nigeria

Uso en el mundo real

Square acepta pagos Bitcoin desde nov. 2025 para más de 4M comerciantes (fuente)
Lightning Network (LN) procesa millones de pagos instantáneos mensualmente (fuente)
Comerciantes en todo el mundo aceptan Bitcoin, desde pequeñas tiendas hasta grandes minoristas (fuente)

Puedes descartarlo, o puedes entenderlo.

Empezando

Bitcoin es dinero que nadie controla y todos pueden verificar. Escaso en un mundo de impresión monetaria infinita. Sin permisos en un mundo de guardianes financieros. Programable de formas que apenas empezamos a explorar.

Entender Bitcoin no requiere creer que cambiará el mundo. Requiere entender qué es el dinero, cómo evolucionó y por qué importan estas propiedades. A partir de ahí, puedes sacar tus propias conclusiones.

¿Quieres probarlo?

La mejor forma de entender Bitcoin es usarlo:

Empieza pequeño: Compra una pequeña cantidad en una plataforma confiable solo de Bitcoin como:
- 21bitcoin o Relai: Apps simples para ahorro automático en Bitcoin
- HodlHodl: Trading peer-to-peer, sin custodia
Muévelo a tu propia wallet: Descarga una wallet móvil y transfiere tu Bitcoin ahí. Siente lo que significa la auto-custodia. Algunas wallets como BlueWallet, Nunchuk.
Envía una transacción: Envía algunos sats a un amigo. Míralo confirmar en ~10 minutos. Ponte curioso mirando tu transacción en el mempool.
Prueba Lightning: Envía un pago instantáneo, casi gratis. Este es el futuro de las transacciones cotidianas. Algunas wallets LN como Alby Go, Muun.

No tienes que ir all in. Empieza pequeño y sigue aprendiendo, un paso a la vez.

Lectura adicional

Bitcoin 101 por Cosme - Otra introducción amigable para principiantes
How to Buy Bitcoin Securely por Cosme - Guía paso a paso

La IA te Da Velocidad, No Calidad

2025-10-10T00:00:00+00:00

He estado usando asistentes de codificación IA extensivamente: ChatGPT, Codex, Claude con Sonnet y Opus. Son increíblemente útiles. Te dan velocidad como nada más.

Pero la velocidad no es calidad.

La trampa del vibe-coding

Los modelos de IA son excelentes imitando su entorno. Dales contexto, y harán lo que sea necesario para completar la tarea. Esto se ha conocido como “vibe-coding”: describes lo que quieres, y la IA produce algo que funciona. Rápido.

¿El problema? La IA felizmente generará código desordenado si eso es lo que hace el trabajo. No le importa la mantenibilidad. No piensa en qué pasa cuando los requisitos cambien el próximo mes. Solo produce output.

La IA es un espejo que refleja el contexto que le das. Si tu codebase está desordenado, generará más desorden. Si tus prompts son vagos, hará suposiciones.

Sin guía cuidadosa, terminas con parches sobre parches. Código legacy recién creado. Una codebase donde cada cambio se siente arriesgado y el equipo pasa más tiempo luchando contra el código que construyendo features.

El arte de preguntar

¿Recuerdas Stack Overflow? ¿Las búsquedas en Google que te llevaban a hilos de foros de 2011 donde alguien tenía exactamente el mismo problema?

Hace diez años, ser desarrollador significaba aprender a hacer buenas preguntas. Elaborabas tu post de Stack Overflow cuidadosamente: describe el problema, muestra lo que intentaste, explica lo que esperabas versus lo que pasó. Si tu pregunta era vaga o perezosa, la comunidad te lo hacía saber. A veces duramente.

Pero esa fricción nos enseñó algo valioso: la calidad de tu respuesta depende de la calidad de tu pregunta.

El mismo principio aplica a la IA. Un prompt vago obtiene una respuesta vaga. Un prompt bien estructurado con contexto claro, restricciones y ejemplos obtiene algo útil. La habilidad de formular buenas preguntas no se volvió obsoleta. Se volvió más importante.

Aprender a hacer prompts a la IA efectivamente es el equivalente moderno de aprender a buscar en Google y preguntar en Stack Overflow. Los desarrolladores que dominen esto obtendrán mejores resultados.

Incluso cuando la IA te da una respuesta rápida e impresionante, nunca aceptes código que no entiendas completamente. Es tentador. La respuesta aparece en segundos, se ve profesional, incluso podría funcionar. Pero si no puedes explicar qué hace y por qué, estás plantando una bomba de tiempo en tu codebase. Y cuando explote a las 2am, estarás debuggeando código que no escribiste sin modelo mental de por qué existe.

Cuestiona el resultado. Pregunta: “¿Puedes simplificar esto?” o “¿Hay código repetitivo aquí que podamos eliminar?” La IA por defecto añade, no mejora. Generará abstracciones, funciones auxiliares y patrones que no pediste. No refactorizará a menos que se lo digas. Cuestiónala.

Esto es especialmente crítico con los tests. Pide a la IA que genere tests y a menudo obtendrás tests que reflejan detalles de implementación en lugar de comportamiento. Se romperán en el momento que refactorices, incluso si la lógica permanece igual. Si quieres tests que verifiquen comportamiento, necesitas decirlo explícitamente. La IA no hará esa elección por ti.

No te dejes seducir por la velocidad. A veces, una respuesta rápida que no entiendes es peor que una respuesta lenta que sí entiendes.

El factor humano

La IA puede escribir código rápido, pero no puede entender la arquitectura general. No sabe por qué ciertas decisiones se tomaron hace meses. No puede ver el panorama general de hacia dónde va el producto. Solo ve lo que le muestras, tomando decisiones locales sin entender las implicaciones globales. Ese es nuestro trabajo.

Como exploré en diferentes creencias sobre la calidad del software, los equipos a menudo tienen estándares variables sobre qué significa “suficientemente bueno”. Cuando añades IA a la mezcla, mantener ese entendimiento compartido se vuelve aún más crítico. La IA no comparte los valores de tu equipo. Solo genera código.

La disciplina para mantener arquitectura limpia, para decir “no” a hacks rápidos, para refactorizar antes de que las cosas empeoren. Eso es únicamente humano.

Libros como Clean Code y Clean Architecture no son menos relevantes en la era de la IA. Son más relevantes. Te ayudan a detectar cuando la IA va en la dirección equivocada.

Colaboración sobre automatización

Hay algo más que la IA no puede reemplazar: el equipo.

Una conversación con un colega sobre “¿deberíamos extraer esto en un servicio?” a menudo lleva a insights que ningún prompt de IA sacaría a la luz. Ese ida y vuelta, el cuestionar, el “¿qué si intentamos esto en su lugar?”. Ahí es donde ocurre el entendimiento real.

Extreme Programming Explained enfatiza prácticas como pair programming y propiedad colectiva del código por buenas razones. Estas no son ineficiencias para automatizar. Son cómo los equipos construyen calidad en su proceso.

Cuando saltas la discusión humana y solo dejas que la IA genere soluciones, pierdes la oportunidad de aprender, de desafiar suposiciones y de crecer como equipo.

Tú eres dueño del código

Cuando la IA escribe código y tú lo commiteas, lo revisas, lo apruebas, lo mergeas y lo deployeas, es tu código. No puedes culpar a la IA cuando algo se rompe en producción. No puedes señalar a Claude o Copilot cuando la arquitectura se vuelve imposible de mantener.

Como escribí sobre el arte del testing, la calidad es una elección que hacemos en cada paso. Cada commit es una decisión. Cada revisión es una oportunidad de detectar problemas. Cada merge es un respaldo de la calidad del código.

Somos la última parte responsable del código que la IA escribe. El commit, la revisión, la aprobación, el merge, el deploy. Todo eso somos nosotros.

Moverse rápido en la dirección equivocada solo te lleva a perderte más rápido. Las líneas de código apareciendo en pantalla no es progreso. El valor que aportamos como desarrolladores no es la velocidad tecleando. Nuestro valor está en entender hacia dónde vamos, mantener disciplina sobre el caos, y asegurar que el código que entregamos hoy no se convierta en la pesadilla de mañana.

Usa la IA. Abraza la velocidad. Pero nunca olvides: tú eres quien conduce. Si sueltas el volante, terminarás en una pila de código imposible de mantener más rápido de lo que esperabas.

Y cuando eso pase, no hay nadie más a quien culpar.

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

Ship, Show, Ask

2025-04-12T00:00:00+00:00

En equipos que se mueven rápido, una de las mayores tensiones que enfrentamos es esta: ¿Cómo seguimos entregando sin comprometer la calidad o la colaboración?

El enfoque tradicional de pull requests a menudo ralentiza las cosas. Esperamos horas, o días, por aprobaciones, incluso para cambios triviales. Pero la alternativa, simplemente mergear directamente, puede sentirse imprudente o invisible para el resto del equipo.

Ahí es donde entra la estrategia Ship-Show-Ask. Originalmente descrita por Rouan Wilsenach, este modelo ofrece una forma más flexible y reflexiva de manejar cambios de código. No es solo una estrategia de branching, es un cambio en cómo los equipos colaboran, confían y toman propiedad.

¿Qué es Ship, Show, Ask?

Es un modelo que clasifica los cambios basándose en cuánta revisión requieren:

Ship – Mergear directamente a main (sin PR)
Show – Abrir un pull request, pero mergearlo inmediatamente
Ask – Abrir un pull request y esperar revisión

La idea clave es usar Ask como el default para la mayoría del trabajo, recurrir a Show cuando el contexto lo hace seguro, y evitar Ship (o reservarlo para casos extremadamente triviales, si se usa).

Por qué prefiero Ask y Show

En mi experiencia, ayuda tratar cada cambio, incluso los pequeños, como algo que vale la pena compartir. Siempre creo una rama y abro un PR. Proporciona visibilidad, construye un historial compartido, y crea un espacio para opiniones opcionales o asíncronas.

Pero no todos los PRs necesitan seguir el mismo proceso de revisión.

Por defecto uso Ask

Prefiero esperar una revisión de un compañero cuando:

El cambio involucra lógica arriesgada o compleja
Podría impactar a otros desarrolladores o equipos
Introduce decisiones arquitectónicas o estructurales que no se han acordado aún
Se beneficia de input compartido o un segundo par de ojos

Dicho esto, Ask no significa sobre-ingeniar el proceso. A menudo, un revisor reflexivo es suficiente, especialmente si está familiarizado con el dominio. Si el cambio toca un área específica, pediré la opinión de la persona que posee (o mejor entiende) esa parte del código. No necesita involucrar a todos.

En equipos pequeños, requerir dos aprobaciones en cada PR puede convertirse rápidamente en un cuello de botella y ralentizar la entrega de valor. El objetivo es alineamiento y calidad, no ceremonia por sí misma.

Uso Show para cambios seguros y de bajo impacto

Podría mergear inmediatamente cuando:

Practico pair programming (la revisión ya ocurrió en vivo)
Corrijo erratas o enlaces rotos
Actualizo documentación o changelogs
Refactorizo dentro de un módulo que poseo
Añado tests para comportamiento existente
Hago ajustes no funcionales (formato, logs, comentarios)
Aplico ajustes de UI o estilo sin cambio de lógica

El principio clave: Show es opcional, nunca obligatorio. Elijo Show solo si el cambio es de bajo riesgo y encaja con las expectativas del equipo. Cuando uso Show, me hago responsable del resultado. La responsabilidad es mía.

Por qué este enfoque funciona para mí

Este modelo me ayuda a:

Entregar más rápido sin comprometer la calidad
Trabajar con mayor autonomía y propiedad
Evitar cuellos de botella, especialmente en equipos pequeños o async
Fomentar una mentalidad de confianza, responsabilidad y toma de decisiones reflexiva

Cambia el objetivo de simplemente obtener aprobación a compartir intención y ser dueño del resultado.

¿Qué hace un buen “Show”?

Un PR Show podría ser la elección correcta cuando:

El cambio es trivial y dentro de mi área de responsabilidad
Nadie está disponible para revisar, y esperar bloquearía el progreso
El PR incluye contexto y razonamiento claro
Estoy abierto a comentarios post-merge
Estoy listo para hacer ajustes de seguimiento si es necesario

Consejos para que funcione

Algunos consejos prácticos de la experiencia:

Clarifica las expectativas del equipo sobre cuándo usar Show vs Ask
Siempre proporciona contexto en tu PR, incluso si mergeas inmediatamente
Escribe tests para cualquier lógica o comportamiento nuevo
Da la bienvenida a los comentarios post-merge, la revisión no termina en el merge
Reflexiona regularmente como equipo y ajusta el enfoque según sea necesario

Ship, Show, Ask es más que higiene de branching.

Para mí, se trata de construir una cultura de claridad, responsabilidad y confianza, donde los desarrolladores están empoderados para moverse rápido mientras permanecen reflexivos.

Si estás cansado de colas lentas de PR y aprobaciones sobre-ingeniadas, esto podría valer la pena intentarlo.

¿Curioso por profundizar? Mira el post de Rouan Wilsenach.

Camino de servidumbre

2025-03-31T00:00:00+00:00

Publicado en 1944, Camino de servidumbre sigue vigente. Friedrich Hayek, economista austriaco, lo escribió durante la Segunda Guerra Mundial para advertir sobre algo que veía como peligroso: la planificación económica central.

Su mensaje es claro: incluso el control gubernamental con buenas intenciones puede quitarnos la libertad poco a poco. Y en el peor caso, llevarnos hacia la dictadura.

1. El peligro de la planificación central

El argumento de Hayek es directo: cuando el gobierno controla la economía, acaba controlando la vida de las personas. Si el estado decide quién obtiene qué, también decide quién puede hacer qué.

Puede empezar con buenas intenciones, pero termina en coerción. La gente tiene objetivos distintos y los planificadores no pueden satisfacer a todos.

“Controlar la economía significa controlar todo lo que las personas quieren hacer. (Capítulo 7)”

2. La ilusión del socialismo “bueno”

Hay quienes creen en el socialismo democrático: mezclar libertad con planificación compartida. Hayek no se lo tragaba.

Sostiene que no se puede separar el socialismo del autoritarismo. Planificar “en nombre del grupo” implica ignorar las elecciones individuales. Tarde o temprano, quienes dirigen el sistema necesitan silenciar a los disidentes. Y eso abre la puerta a los peores líderes.

“Los peores llegan a la cima. (Capítulo 10)”

3. Estado de derecho vs. gobierno discrecional

En una sociedad libre, las reglas se aplican a todos, se conocen de antemano y son consistentes. Como las normas de tráfico.

La planificación necesita reglas flexibles. Los burócratas toman decisiones sobre la marcha, lo que les da mucho poder. Para Hayek, eso es un problema. Cuanta más discreción tienen los funcionarios, menos protección tiene el individuo.

“Nada distingue más claramente las condiciones en un país libre de las de un país bajo gobierno arbitrario que la observancia en el primero de los grandes principios conocidos como el Estado de Derecho. (Capítulo 6)”

4. Los mercados funcionan porque nadie los dirige

Hayek creía que ningún planificador, por listo que sea, puede reemplazar lo que el mercado hace solo.

¿Por qué? Los mercados usan señales de precios para compartir información. Millones de personas tomando decisiones envían señales sobre lo que se necesita y lo que no. Gestionar eso desde arriba es ineficiente y casi siempre falla.

“Cuanto más ‘planifica’ el estado, más difícil se vuelve la planificación para el individuo. (Capítulo 5)”

5. Pérdida gradual de libertad

Hayek no advertía sobre dictaduras de un día para otro. Le preocupaba la pérdida lenta de libertad: controles de precios aquí, industrias nacionalizadas allá.

Cada paso parece inofensivo, pero se acumulan. Cuando la gente depende demasiado del estado, cuesta decir no a la siguiente “solución” desde arriba.

“El peligro de tiranía surge inevitablemente de los métodos del colectivismo. (Capítulo 10)”

¿Sigue vigente Hayek?

Sin duda. El mundo ha cambiado, pero la tensión entre libertad y control sigue ahí. Hayek nos recuerda que la libertad no desaparece de golpe. Se desvanece cuando dejamos de prestarle atención.

Claro, algo de gobierno hace falta. Pero su advertencia permanece: demasiado control, aunque venga con buenas intenciones, puede llevarnos donde no queremos estar.

Ejecuta tu Nodo LN en una Raspberry Pi

2025-02-17T00:00:00+00:00

En esta guía te muestro cómo configurar un nodo de Lightning Network (LN) con Alby Hub en una Raspberry Pi. Tendrás control total sobre tu nodo. Alby Hub ofrece una versión DIY gratuita para una wallet Lightning auto-custodiada: tus fondos son tuyos, y el código es 100% open-source.

Soporta direcciones Lightning y Nostr, conectando ambos ecosistemas sin problemas. Se integra con docenas de aplicaciones Bitcoin. Con los servicios LSP (Lightning Service Provider) integrados y la app Alby Go, gestionar tu nodo desde el móvil es muy fácil.

Importante: Esto NO es un minero de Bitcoin ni un nodo completo. Es simplemente una Raspberry Pi ejecutándose en una tarjeta SD eficiente en energía y de bajo coste.

⚠️ Aviso ⚠️

Asumo que entiendes los conceptos fundamentales de Bitcoin.
Asumo que sabes cómo funciona la Lightning Network (LN).

De todos modos, he incluido un breve repaso de los fundamentos de Lightning Network abajo.

¿Qué es la Lightning Network?

La LN es una capa construida sobre Bitcoin que permite transacciones rápidas, baratas y escalables.

¿Por qué? La capa base de Bitcoin es segura pero lenta y cara para pagos pequeños, por los límites de bloque y las comisiones.
¿Cómo? LN usa canales de pago fuera de la cadena. Puedes enviar pagos al instante sin esperar confirmaciones en la blockchain.

Conceptos clave

Canales de pago: Abres un canal con una transacción on-chain. Después puedes enviar pagos instantáneos e ilimitados dentro de ese canal.
Enrutamiento: No necesitas canal directo con todos. Los pagos se enrutan a través de múltiples nodos conectados.
Comisiones bajas: Solo abrir y cerrar canales requiere comisiones on-chain. El resto cuesta fracciones de céntimo.

Objetivo

LN hace Bitcoin usable para el día a día. Puedes comprar un café sin esperar 10 minutos por confirmaciones.

En resumen: Lightning Network = Pagos Bitcoin instantáneos + baratos, asegurados por la blockchain de Bitcoin.

Configurando Alby Hub

Alby Hub es un nodo de Lightning Network gratuito, open-source (idealmente privado).

Requisitos

Antes de empezar, vas a necesitar las siguientes cosas:

Un ordenador con windows, mac o linux
Raspberry Pi 4 o 5 (Para Zero 2W mira este tutorial!)
- En este tutorial, estoy usando una raspi-4b (~60€)
El cargador para tu raspi (~10€)
Tarjeta de memoria SD (32/64gb) (~10€)
Adaptador de tarjeta SD a USB (para flashear el SO en la raspi) (~10€)

Pasos de instalación

1. Flashear un kernel Linux en la tarjeta SD

Sugerencia: Puedes usar RPI imager en tu ordenador. Úsalo para flashear el SO raspi recomendado para ti

En Storage verás tu tarjeta SD después de insertarla en tu portátil.

Una vez hagas clic en “Next”, verás diferentes ajustes. Haz clic en Edit Settings

En Settings > General: establece tu hostname, el nombre de usuario y contraseña para tu usuario admin. Asegúrate de habilitar tu WIFI, de lo contrario tendrás que conectarla al router con un RJ-45.

Para este tutorial, estoy usando testhub como hostname, puedes usar albyhub o lo que prefieras.

En Settings > Services: asegúrate de que el acceso vía SSH está habilitado. Lo vamos a necesitar para instalar Alby Hub.

Haz clic en “Save” y haz clic en “Yes” para iniciar la instalación.

Verás una confirmación. Haz clic en “Yes”. Tardará ~10 mins…

¡Ahora tenemos la SD con un kernel linux fresco listo para usar!

2. Insertar la SD en la raspi

Extrae la SD del portátil e insértala en la raspi primero.

Una vez insertada la SD, conecta el cable de alimentación. Se encenderá automáticamente en cuanto la conectes.

3. Instalación de Alby Hub

Tardará ~5mins desde que la encendiste para poder acceder a ella. ¿Cómo puedes asegurarte de que está viva? Abre la terminal y haz ping al hostname que definiste mientras flasheabas la SD en Settings > General, recuerda que terminaba con .local:

ping testhub.local

Es normal si no obtienes respuesta al principio… hasta que la obtienes.

Ahora puedes instalar Alby Hub en tu raspi usando la conexión SSH que habilitaste antes:

# Código fuente: https://github.com/getAlby/hub/tree/master/scripts/pi-aarch64
ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-install.sh)"'

Se te pedirá que escribas la palabra “yes”; escríbela.

Luego, se te pedirá que introduzcas tu contraseña. Introduce la contraseña que elegiste en Settings > General para el nombre de usuario.

4. Configuración de Alby Hub

Espera otros 2-3 mins y visita tu host: http://testhub.local/

Tu Alby hub ya está funcionando. ¡Vamos a conectarlo a tu cuenta GetAlby!

Crear una cuenta GetAlby

🔗 getalby.com

Conectando GetAlby con Alby Hub

Creé una cuenta llamada testhub.

Izquierda: la cuenta GetAlby. Derecha: el nodo en la raspi.

Haz clic en “Connect Now”.

Haz clic en “Request Authorization Code”.

Obtienes el código de autorización (izquierda) que necesitas insertar en tu configuración (derecha).

Crea una Contraseña para tu Alby Hub instalado en tu raspi. Puede ser diferente de la contraseña que configuraste para tu usuario root en la raspi misma.

Ahora es momento de Vincular tu Cuenta Alby

A menos que especifiques lo contrario, establece el “Budget renewal: Monthly 1M sats” por defecto.

Abriendo canales Lightning

Recomiendo seguir los Pasos Iniciales para configurar tu Alby Hub.

Abramos el primer canal.

Necesitas pagar ~$20 en sats para abrir un canal de liquidez entrante de 1M sats.

Después del pago, verás el canal abierto. Puede tardar un par de minutos hasta que la transacción de financiación sea minada en el siguiente bloque.

Recibiendo Sats

Puedes recibir sats usando tu Dirección LN.

Izquierda: Página pública vinculada a tu nodo. Derecha: Página privada de tu Alby Hub.

Opcional: Puedes añadir fondos ln a tu wallet usando los servicios de terceros de GetAlby: getalby.com/topup - ten en cuenta el KYC…

Usando tus Sats

Después de eso, podrás usarlos a través de la Extensión Alby o AlbyGo.

Tu nodo es la fuente de verdad. Conecta estas apps y podrás usar tus sats en cualquier plataforma sin problemas.

Aviso: la dirección LN testhub fue creada solo para propósitos de testing y tutorial. Mi dirección real es chemaclass ;)

Mantenimiento y solución de problemas

Actualizando tu nodo

Como en la instalación, hay un script para actualizar tu nodo. Lo encuentras en el repositorio: GitHub - Script de actualización Alby Hub

ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-update.sh)"'

Manejando cortes de energía

Si se va la luz, la Raspberry Pi se apaga. Cuando vuelva, se reinicia sola. Alby Hub te pedirá la contraseña que configuraste antes.

Enlaces relacionados

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

Criptoria

2025-02-09T00:00:00+00:00

¿Cómo llegamos de la Grecia antigua a Bitcoin? Criptoria cuenta esa historia: el nacimiento de las computadoras, las redes y el dinero digital.

El libro recorre los hitos antes y después de Alan Turing. Personas, organizaciones e inventos que revelan el vínculo profundo entre matemáticas, criptografía y la búsqueda de soberanía individual.

Un libro para quienes creen que hay formas de organización social y económica más allá de las heredadas o impuestas.

Contenido

Parte I: Antes de Turing

1. El Principio del Fin

Los Chicos Que Amaban los Puzzles
- Alan Turing
- Irving John Good
Los Hombres Que Amaban Sus Genes
- La Quimera de Galton
- La Mutación de Lugénesis
El Poder de la Ciencia Ficción
- Hugo Gernsback
- Amazing Stories
El Descenso de San Judas

2. En Busca de la Verdad

Como Lo Conocemos
Organon
El Efecto Mosaico de la Ciencia

3. Los Números Te Harán Libre

Matemáticas Soberanas
- Lenguaje Formal
- Teoría de Conjuntos
- Aritmética Modular
- Congruencia
- Gauss
- Gauss, Fermat y Euler
- Álgebra Booleana
- Tablas de Verdad
Axiomatizar o Morir
Problemas No Resueltos
- Principia Mathematica
- Bolonia 1928
- La Revelación de Gödel
La Máquina de Turing
- Números Computables
- Máquina de Computación
- Conclusiones 1936

4. Las Matemáticas del Secreto

Una Breve Historia de los Números
Herramienta de Guerra
Enlazados por Señales
La Fábrica de Persuasión
Bletchley Park
Ratio Club
Inteligencia Metálica
Alan Eterno

Parte II: Después de Turing

5. Computación Moderna

Bell Labs
Claude Shannon
- Me Alegro de Que Hayas Venido
- Teoría de la Información
La Era UNIX
- Nuevos Lenguajes
- Nuevo Reloj
El Primer Microprocesador
Horst Feistel
- Lucifer
- DES
ARPANET
Primeras Empresas
Complejidad Computacional

6. El Amanecer de la Criptografía Fuerte

Criptografía Prohibida
- Una Ley Para Prohibirlas a Todas
Criptografía de Clave Pública
Diffie-Hellman-Merkle
- Martin Hellman
- Whitfield Diffie
- Whit conoce a Martin
- Diffie investiga con Hellman
- Técnicas criptográficas multiusuario
- Ralph Merkle
- Merkle 1974
- Puzzles de Merkle
- Ralph conoce a Whit y Martin
- Nuevas direcciones en criptografía
El Equipo RSA
- Ron, Adi y Len
- El Sistema RSA
Centros de Distribución de Claves (KDC)
Redes Distribuidas
Árbol de Merkle

7. Haciendo Legión

Universo Internet
USENET
CPSR
David Chaum
- Conferencias Cripto
- CRYPTO ’82
Prueba de Conocimiento Cero
Software Libre
- Proyecto GNU
- Free Software Foundation

8. Camino al Libertario

Firmas Digitales
- Taher Elgamal
- Claus Schnorr
Curvas Elípticas
David vs. Gran Hermano
Criptoanarquía
Extropianos

9. Soldados de la Privacidad

EFF
- John Perry Barlow
- John Gilmore
- Mitch Kapor
- Frontera Electrónica
- Independencia del Ciberespacio
EPIC
PGP
- Phil Zimmermann
- Hal Finney
- Danzando con Lobos
- OpenPGP
Cypherpunks
- Cyphernomicon
- Manifiesto Cypherpunk
Clipper Chip

10. Dinero Digital

Tatsuakki Okamoto
Prueba de Trabajo
Digicash
Hal 1993
Magic Money Digicash
Contratos Inteligentes
La Casa de la Moneda del Palacio
Hashcash
B-money
Bit Gold
RPOW

11. La Era de Satoshi

Satoshi Nakamoto
Whitepaper
Binarios
Primera TX
Bitcoin

🇪🇸 Videos relacionados

Enlaces relacionados

Sitio web del libro: www.prometeabtc.com/criptoria

Bitcoin con Rigor

2025-01-18T00:00:00+00:00

Un análisis detallado de cómo funciona Bitcoin, desglosando sus componentes de forma clara para entender tanto las partes como el sistema completo. Explora su potencial y riesgos como experimento monetario que, aunque no ha superado la prueba del tiempo como el oro, tiene un diseño prometedor.

Bitcoin es difícil de entender del todo. Requiere conocimientos de computación, economía y finanzas, y además es un activo digital sin precedente histórico que sirva de guía. Pero igual que Internet (también joven pero innegablemente transformador), Bitcoin tiene el potencial de redefinir sistemas y dejar un impacto duradero.

Este libro busca darte las herramientas para entender cómo funciona Bitcoin. Así podrás formar tu propia opinión informada sobre su papel en la sociedad o, si lo decides, empezar una carrera profesional en este sector. Está escrito con rigor pero sin tecnicismos excesivos: conciso, accesible y pensado para que comprendas Bitcoin de verdad.

Contenido

1. Conceptos Básicos de Computación

Información y Comunicación
Cómo Funcionan las Computadoras
Lenguajes y Protocolos
El Modelo OSI: La Cebolla de la Computación
Puertas Lógicas: Funciones Fundamentales de Computación
Redes Cliente-Servidor y P2P

2. Conceptos Básicos de Criptografía

Complejidad Asimétrica
Cifrados, Claves y Criptografía Simétrica
Criptografía Asimétrica
El Movimiento Cypherpunk
Funciones Hash Criptográficas

3. Los Fundamentos de Bitcoin y las Criptomonedas

Generadores de Claves y Aleatoriedad
Firmas Criptográficas
El Problema del Logaritmo Discreto
Criptografía de Curva Elíptica
Árbol de Merkle
Dinero Digital Tradicional
Algoritmos de Consenso Distribuido
Prueba de Trabajo (PoW)

4. Bitcoin Pieza por Pieza

¿Blockchain o Hashchain?
Sincronización de Bloques
La Headerchain
Claves y Firmas en Bitcoin
Transacciones y el Modelo UTXO
Bitcoin Script y Opcodes
P2PKH (Pay to Public Key Hash) y P2PK
Multifirmas y P2SH (Pay to Script Hash)

5. Nodos y Blockchain en Detalle

Tamaño y Frecuencia de Transacciones
Inicialización de un Nodo de Red Completo
Bases de Datos y Pruning
Cómo Funciona una Wallet
Wallets, Nodos SPV y Otros
Del Mempool a la Blockchain
Forks y Criticidad del Consenso
Hard Fork vs. Soft Fork

6. Actualizaciones y Aplicaciones de Bitcoin

Mucho Trabajo por Delante
Maleabilidad de Transacciones
Segregated Witness (SegWit)
P2WPKH y P2WSH
Canales de Pago Unilaterales
Canales Lightning
Pagos Multicanal y HTLCs
Lightning Network
Discreet Log Contracts (DLCs)
MAST, P2SMR y P2CH
Taproot y Grafroot

Presentación del libro

Enlaces relacionados

Sitio web del libro: www.bitcoinconrigor.com

Entendiendo los Impuestos

2025-01-02T00:00:00+00:00

Los impuestos son inevitables. Tu sueldo, el café de la mañana, la casa que acabas de comprar: todos llevan impuestos. Si alguna vez te has preguntado a dónde va tu dinero o por qué comprar una propiedad incluye tasas extra, este post es para ti. Voy a mantenerlo simple, sin complicaciones legales.

Impuestos 101
Tipos de impuestos
¿Cómo funcionan?
¿Por qué pagamos impuestos?
Una nueva perspectiva

Impuestos 101

Cuando ganas:
- Impuesto sobre la Renta: Deducido de tu salario.
- Cotizaciones a la Seguridad Social: Para sanidad, pensiones y desempleo.
- Impuesto de Autónomos: Cubre impuestos y seguridad social para freelancers.
Cuando gastas:
- Impuesto sobre el Valor Añadido (IVA): Añade del 10%-25% a la mayoría de bienes y servicios.
- Impuestos Especiales: Cargos extra sobre combustible, alcohol, tabaco y artículos de lujo.
Cuando posees:
- Impuesto sobre Bienes Inmuebles (IBI): Pagado anualmente sobre propiedades.
- Impuesto sobre el Patrimonio: Cobrado sobre activos sustanciales en algunos países.
- Impuesto de Circulación: Tasa anual por poseer u operar un vehículo.
Cuando transfieres o heredas:
- Impuesto de Transmisiones: Aplicado a compras como propiedades de segunda mano.
- Impuesto de Sucesiones/Donaciones: Pagadero sobre activos heredados o grandes regalos.
Cuando vendes:
- Impuesto sobre Ganancias de Capital: Sobre el beneficio al vender propiedades, acciones o inversiones.
- Impuesto sobre el Incremento del Valor de los Terrenos: Sobre el aumento del valor del terreno durante la propiedad.
Cuando usas servicios:
- Tasas Locales: Por recogida de basuras, matriculación de vehículos o licencias de obras.
- Tasa Turística: Por alojamiento o ciertos servicios relacionados con el turismo.
Cuando ganas la lotería:
- Impuesto sobre la Lotería: Una porción sustancial de tus ganancias va al gobierno.

Tipos de impuestos

Considera los impuestos como un menú de tres platos: directos, indirectos y especiales.

Impuestos directos: Lo que ganas y posees

Estos impuestos se basan en tus ingresos, activos o ganancias:

Impuesto sobre la Renta: El más importante. Es progresivo: cuanto más ganas, mayor porcentaje pagas. El IRPF se aplica a salarios, ingresos de freelance, alquileres y ganancias de inversiones.
Impuesto de Sociedades: Se paga sobre los beneficios de las empresas. Las tasas varían por país, pero el 20-30% es lo habitual.
Impuesto sobre el Patrimonio: Algunos países gravan a personas con alto patrimonio sobre sus activos totales (propiedades, ahorros). Las tasas y exenciones dependen de dónde vivas.
Impuesto de Sucesiones y Donaciones: Cuando heredas activos o recibes un regalo significativo, debes pagar impuestos. La tasa a menudo depende de tu relación con el donante.

Impuestos indirectos: Lo que gastas

Estos impuestos están incorporados en el precio de bienes y servicios:

Impuesto sobre el Valor Añadido (IVA): Va incluido en casi todo lo que compras. Las tasas estándar van del 10-25%, aunque productos esenciales como alimentos y medicinas suelen tener tasas reducidas.
Impuestos especiales: Gravan productos como alcohol, tabaco y combustible. Recaudan dinero y, de paso, desincentivan el consumo.

Impuestos sobre propiedades y locales: Poseer cosas cuesta dinero

Si posees, alquilas o vendes propiedades, estos impuestos entran en juego:

IBI: Pagado anualmente basado en el valor de tu casa o terreno.
Impuesto de Transmisiones: Al comprar una propiedad de segunda mano, puedes pagar un % de su precio.
Impuesto sobre Ganancias de Capital: Al vender una propiedad u otros activos con beneficio.

Otros impuestos y tasas: Los pequeños extras

Aquí entran tasas de matriculación, recogida de basuras, permisos de obra. Parecen poca cosa, pero se acumulan.

¿Cómo funcionan?

Los impuestos suelen ser una mezcla de responsabilidades nacionales, regionales y locales:

Los impuestos nacionales tienen tasas estandarizadas, como el IRPF o el IVA.
Los impuestos regionales varían dependiendo de dónde vivas, como el patrimonio o sucesiones.
Los impuestos locales son específicos de tu ciudad o pueblo, como el IBI o tasas de basuras.

A los empleados les descuentan los impuestos directamente de la nómina. Los freelancers y dueños de negocios tienen que calcularlos y pagarlos ellos mismos.

¿Por qué pagamos impuestos?

Los impuestos financian servicios públicos: carreteras, sanidad, escuelas, pensiones. Deberían mejorar la vida de todos. Pero la complejidad del sistema y cómo se gasta el dinero hacen que muchos lo sientan injusto.

¿Son justos los impuestos?

Esto depende de dos grandes preguntas: ¿Quién debería pagar? ¿Cuánto es justo?

El caso a favor de los impuestos

Los impuestos financian servicios esenciales que todos usamos, como hospitales y escuelas.
Los impuestos progresivos, donde los que más ganan pagan más, ayudan a reducir la desigualdad y crear comunidades más fuertes.

El caso en contra de los impuestos

Algunos impuestos, como patrimonio o sucesiones, se sienten injustos. Gravan dinero que ya ganaste.
Peor aún, cuando los gobiernos desperdician el dinero de los impuestos en corrupción o malas decisiones, la gente siente que está pagando por nada.

Resulta injusto cuando los gobiernos desperdician el dinero. Si los servicios no mejoran o se gestionan mal, frustra ver tu dinero desaparecer sin beneficio.

Los impuestos parecerían más justos si la gente confiara en que se gastan bien. Sin esa confianza, pagar impuestos se siente como tirar dinero a un agujero negro.

Una nueva perspectiva

Se supone que los impuestos financian servicios públicos esenciales. Pero el gran problema con los impuestos (y los gobiernos grandes) es que suelen traer ineficiencia y corrupción. Cuanto más poder tiene un gobierno, más probable es que lo use mal. Por eso creo que los gobiernos deberían ser pequeños, enfocados y eficientes: dar servicios esenciales sin complicar las cosas ni meterse en la vida de la gente.

Aquí es donde Bitcoin ofrece una alternativa interesante. Es descentralizado: nadie lo controla. Ni gobiernos, ni bancos, ni nadie. Eso elimina el riesgo de corrupción o mala gestión por parte de instituciones poderosas. Cada transacción se registra en un libro mayor público que cualquiera puede verificar. Es transparente y resistente a la manipulación.

Aunque la mayoría de países quieren gravar las transacciones de Bitcoin, usarlo da más control sobre tu dinero. Las monedas tradicionales se pueden imprimir sin límite (causando inflación y reduciendo el valor de tus ahorros). Bitcoin tiene una oferta limitada, así que su valor no se puede diluir igual. Además, no tiene fronteras: puedes enviar y recibir dinero sin depender de bancos ni intermediarios que se queden una parte o añadan retrasos.

Por qué funciona el dinero del gobierno

¿Por qué el papel moneda tiene valor si no está respaldado por oro? La respuesta son los impuestos. Los gobiernos te exigen que pagues impuestos en su moneda. Eso crea demanda forzada: todos necesitan euros, dólares o yenes para pagar al gobierno. Es un sistema circular. El gobierno crea el dinero, te exige que lo ganes, y luego toma una parte a través de impuestos. Por eso el dinero del gobierno se llama “fiat” (del latín “hágase”). Funciona porque el gobierno lo dice, respaldándolo con el sistema tributario.

Inflación: El impuesto oculto

La inflación se llama a menudo “impuesto oculto”, y con razón. Cuando los gobiernos imprimen dinero sin parar para financiar sus gastos, el valor del dinero existente cae. Tus ahorros compran menos con el tiempo.

Los políticos se benefician a corto plazo: tienen más dinero sin subir impuestos directamente. Pero la gente común paga el precio con costos de vida más altos. La inflación es un robo silencioso: quita valor al dinero de todos para cubrir las malas decisiones financieras del gobierno.

Bitcoin tiene una oferta fija de 21 millones de monedas. No se puede inflar. Su escasez garantiza que nadie, ni siquiera los políticos, manipule su valor. Para quienes están hartos de precios que suben y ahorros que se devalúan, Bitcoin ofrece una forma de proteger su riqueza. Es un sistema diseñado para recompensar a los ahorradores, no castigarlos.

Reflexiones finales

Bitcoin no elimina los impuestos ni los servicios públicos, pero cuestiona cómo pensamos sobre el dinero y el poder. Da a la gente más control sobre su riqueza y demuestra que los sistemas financieros pueden funcionar sin grandes instituciones (a menudo corruptas). Es un paso hacia un mundo con más libertad individual y gobiernos pequeños, eficientes y justos.

Los Cypherpunks

2024-12-11T00:00:00+00:00

A principios de los 90, con el auge de internet, surgió un grupo llamado los Cypherpunks para defender la privacidad digital. Impulsaron el cifrado y la privacidad, moldeando nuestro mundo digital con su visión.

¿Quiénes eran los Cypherpunks?

El término “Cypherpunk” combina “cipher” (una referencia al cifrado) con “punk”, reflejando el espíritu rebelde y anti-establishment del grupo.

No eran una organización formal, sino una mezcla de visionarios, tecnólogos y activistas unidos por ideales comunes. El movimiento arrancó en 1992, cuando Eric Hughes, Timothy May y John Gilmore crearon la lista de correo cypherpunks. Algunas figuras clave:

Eric Hughes quien escribió “A Cypherpunk’s Manifesto”, estableciendo la base filosófica del movimiento.
Timothy C. May escribió “The Crypto Anarchist Manifesto”, que imaginaba una sociedad donde la criptografía podría fomentar un nuevo orden anárquico.
John Gilmore, cofundador de la Electronic Frontier Foundation (EFF), fue fundamental en la defensa temprana de la privacidad en internet.
Julian Assange, más tarde conocido por WikiLeaks, participó en estas discusiones.
Phil Zimmermann revolucionó la privacidad del email con su creación de PGP.
Jude Milhon (St. Jude), hacker y escritora, acuñó el término “cypherpunk” junto con Eric Hughes.
Nick Szabo trabajó en contratos y monedas digitales, y conceptualizó “bit gold” antes de Bitcoin.
Hal Finney, uno de los primeros desarrolladores de Bitcoin, trabajó en software criptográfico como PGP.
Adam Back creó Hashcash, que luego inspiró la prueba de trabajo de Bitcoin.
Wei Dai propuso “b-money”, una idea temprana para sistemas de dinero digital anónimo, que influyó en el desarrollo de Bitcoin.
Zooko Wilcox-O’Hearn trajo privacidad avanzada a las criptomonedas con su trabajo en Zcash.
David Chaum, conocido como el “padrino de los cypherpunks”, fue pionero del dinero digital con DigiCash (1989). Su trabajo sobre privacidad electrónica precedió e inspiró al movimiento.
Bram Cohen desarrolló BitTorrent, mostrando el ethos cypherpunk de descentralización en el intercambio de archivos.

Su trabajo se basó en la investigación criptográfica fundamental de Whitfield Diffie y Martin Hellman, quienes inventaron la criptografía de clave pública en 1976, haciendo posible la comunicación segura entre desconocidos.

Se reunían online en la lista de correo cypherpunks. En su mejor momento, tenía unos 2000 suscriptores que intercambiaban más de 30 mensajes al día. Su lema: “Cypherpunks write code.” No solo hablaban de privacidad. La construían.

Filosofía y objetivos

La filosofía central de los Cypherpunks se centraba en la privacidad, la libertad de expresión y el potencial de la criptografía para proteger estos derechos. Sus principios principales incluían:

La privacidad como derecho fundamental: Creían que la privacidad era esencial para la libertad personal y que la comunicación digital debería ser privada.
Descentralización: Desconfiaban del control centralizado sobre la información, así que impulsaron sistemas descentralizados donde cada persona pudiera controlar sus propios datos.
La criptografía como herramienta: Veían el cifrado no solo como un medio para asegurar datos sino como una herramienta política contra la vigilancia y los regímenes opresivos.

Sus objetivos eran

Crear y promover herramientas para cifrado, anonimato y dinero digital.
Educar al público sobre la importancia de la criptografía.
Resistir los esfuerzos gubernamentales y corporativos para controlar o monitorear las comunicaciones digitales.

Impacto actualmente

Desarrollo de tecnologías clave

Los Cypherpunks construyeron herramientas, no solo teorías:

PGP (1991): Cifrado de email para todos
Tor (2002): Navegación anónima a través de enrutamiento cebolla
BitTorrent (2001): Intercambio de archivos descentralizado
Bitcoin (2009): Dinero digital sin bancos
Protocolo Signal: El cifrado detrás de Signal, WhatsApp y otros mensajeros

Cuando envías un mensaje cifrado hoy, estás usando tecnología cypherpunk.

Cambio cultural

Cambiaron cómo la sociedad ve la privacidad. Antes de ellos, el cifrado era principalmente para gobiernos o expertos. Hoy, es una parte estándar de herramientas como aplicaciones de mensajería y navegadores web. Al promover el cifrado y el anonimato, hicieron de la privacidad una prioridad y animaron a las personas a tomar control de sus datos.

Influencia legal y política: Las Crypto Wars

Los años 90 vieron una batalla real entre los cypherpunks y los gobiernos, conocida como las “Crypto Wars”. EE.UU. clasificó el cifrado fuerte como arma y prohibió su exportación. Cuando Phil Zimmermann lanzó PGP, fue investigado por “exportar municiones” porque el software se extendió globalmente a través de internet.

Los cypherpunks contraatacaron creativamente. Imprimieron el código fuente de PGP en libros, ya que los libros eran discurso protegido. Usaron camisetas con código de cifrado. Finalmente, ganaron. Las restricciones de exportación se relajaron en 2000. La mensajería cifrada de hoy existe gracias a esa lucha.

Desafíos y críticas

Los Cypherpunks enfrentan estas críticas principales:

Accesibilidad: Sus herramientas son demasiado complejas para mucha gente. Solo quienes tienen conocimientos técnicos pueden usarlas, dejando al resto fuera.
Riesgo de mal uso: Su tecnología de cifrado puede caer en malas manos. Los Cypherpunks creen que la privacidad es un derecho para todos, pero las autoridades temen que estas herramientas oculten actividades ilegales.

Es la eterna tensión entre privacidad y seguridad en el mundo digital.

Precursores de Bitcoin

Bitcoin es el resultado más conocido de la filosofía cypherpunk. Encarna sus valores: descentralización, privacidad e independencia del control gubernamental sobre el dinero. El misterioso Satoshi Nakamoto lo compartió por primera vez en la lista de correo cypherpunks en 2008.

Pero Bitcoin no surgió de la nada. Es el resultado de muchos intentos previos dentro de este grupo. Usa ideas de Hashcash (prueba de trabajo), b-money y bit gold, todas reflejando el sueño cypherpunk de una moneda que nadie controle.

DigiCash (eCash)

David Chaum lo desarrolló a finales de los 80 y lo lanzó en 1990. Fue uno de los primeros intentos de pago electrónico. Usaba criptografía para garantizar privacidad, pero fracasó por problemas de adopción, centralización y el famoso problema del doble gasto.

B-Money

Wei Dai lo propuso en 1998 como un marco conceptual para dinero electrónico anónimo y distribuido. Quería resolver el doble gasto sin autoridad central, pero nunca se implementó. Sus ideas influyeron en el diseño de Bitcoin.

Bit Gold

Nick Szabo lo conceptualizó en 1998. Proponía una moneda con propiedades similares al oro usando prueba de trabajo criptográfica. Nunca se terminó, pero contribuyó al desarrollo de Bitcoin, especialmente su sistema de prueba de trabajo.

Hashcash

Adam Back lo introdujo en 1997. No era una moneda, sino un sistema para combatir el spam de email usando prueba de trabajo. Bitcoin adoptaría este concepto para la minería.

Ninguno de estos proyectos logró crear una moneda digital funcional. Pero sentaron las bases teóricas de Bitcoin al abordar problemas clave: el doble gasto, la privacidad y la descentralización.

Legado cypherpunk

Bitcoin ha cambiado cómo entendemos el dinero, la privacidad y la seguridad:

Control descentralizado: Bitcoin no es administrado por ningún banco o gobierno, lo que encaja perfectamente con el escepticismo cypherpunk hacia el poder centralizado.
Privacidad: Aunque no es completamente anónimo, las transacciones de Bitcoin usan pseudónimos, ofreciendo cierta protección contra la supervisión financiera.
Transacciones inmutables: Una vez que una transacción está en la blockchain, es casi inalterable, fomentando la confianza en las transacciones digitales.

Bitcoin dio vida a los ideales cypherpunk. Ha provocado debates globales sobre privacidad financiera, la naturaleza del dinero y el poder de la criptografía. Y sigue evolucionando con desarrollos como Lightning Network para transacciones más rápidas y privadas, y Taproot para mayor privacidad.

Conclusión

Los cypherpunks demostraron que un pequeño grupo de personas que escriben código pueden cambiar el mundo. Cada mensaje cifrado que envías, cada transacción de Bitcoin, cada navegación anónima: su legado.

La privacidad no está muerta. Ellos se aseguraron de eso.

Enlaces relacionados

Aprende más: ¿Qué es el cifrado PGP? Un tutorial de 3 minutos para principiantes
Artículo de Wikipedia: wikipedia.org/Cypherpunk

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

Commits de Git Verificados

2024-11-17T00:00:00+00:00

En desarrollo de software, la confianza y la seguridad son clave. Una forma fácil de mejorar ambas: usar commits verificados.

Ya trabajes en open-source o en una empresa privada, los commits verificados aseguran que tus contribuciones son legítimas. Veamos qué son, por qué importan y cómo empezar a usarlos.

¿Qué son los commits verificados?

Un commit verificado es un commit de Git firmado digitalmente por su autor. La firma demuestra que el commit viene de quien dice haberlo hecho. Herramientas como GPG (GNU Privacy Guard) permiten adjuntar esta firma.

En plataformas como GitHub verás una insignia “Verified” junto a los commits firmados. Es una forma rápida de mostrar que el commit es auténtico.

¿Por qué son importantes?

Los commits firmados mantienen tus contribuciones auténticas y confiables. La firma criptográfica demuestra que los cambios vinieron de ti. En entornos colaborativos, donde la confianza y la responsabilidad importan mucho, esto es clave.

Sin firmar, cualquiera puede falsificar un commit usando tu email. GitHub lo vincularía a tu perfil, pareciendo que hiciste los cambios aunque no fuera así. Nada bueno.

Al firmar tus commits, demuestras que el trabajo es tuyo. Evitas la suplantación, generas confianza y mantienes todo transparente.

Nota: Para esta demo, usé un email público de Linus Torvalds. Al hacer push, GitHub reconoció el email y lo vinculó a su perfil. Suplantación solo con fines de demo para mostrar los riesgos. Usa siempre tu propio email para commits.

Cómo empezar con commits verificados

Configura una clave GPG

Primero necesitas una clave GPG. Así se hace:

Genera una clave GPG:

gpg --full-generate-key

Encuentra tu ID de clave:

gpg --list-secret-keys --keyid-format=long

Dile a Git que use tu clave:

git config --global user.signingkey <tu-id-de-clave>

Haz que firmar commits sea el valor por defecto:

git config --global commit.gpgsign true

Añade tu clave a GitHub/GitLab

Exporta tu clave pública:

gpg --armor --export <tu-id-de-clave>

Navega a “Settings > SSH and GPG keys,” y pega tu clave.

Empieza a firmar commits

A partir de ahora, Git firmará tus commits automáticamente.

Si quieres firmar un commit a mano, usa la bandera -S:

git commit -S -m "Tu mensaje de commit"

Puedes verificar la firma del commit con:

git log --show-signature

También puedes hacer clic en la insignia “Verified” en GitHub.

Los commits verificados parecen un paso pequeño, pero hacen tu código más confiable. Una capa extra de protección fácil de añadir. Pruébalo.

Extra: Configuración completa en español

Enlaces relacionados

Aprende más: ¿Qué es el cifrado PGP? Un tutorial de 3 minutos para principiantes

bashunit

2024-10-30T00:00:00+00:00

bashunit es un framework de testing ligero y fácil de usar para Bash. Características como testing paralelo y de snapshots, dobles de test, data providers y toneladas de assertions incorporadas.

Respaldado por documentación clara y una comunidad activa, se ha convertido en un favorito para testing confiable en Bash. Lo que comenzó como una simple frustración de desarrollo ha crecido hasta convertirse en una herramienta open-source que hace que el testing en Bash sea mucho más fácil y divertido.

La historia detrás de bashunit
¿Por qué crear otra librería de testing?
¿Cómo está hoy en día?
Características principales
Lightning tech talk

La historia detrás de bashunit

El viaje para crear bashunit comenzó con una simple frustración: trabajaba con un equipo donde cada commit tenía que empezar con el nombre del ticket. Como me gusta trabajar en pequeños pasos con commits rápidos e iterativos, añadir la clave y número del ticket a cada commit se convirtió en un gran obstáculo, ralentizando mi flujo de desarrollo con fricción innecesaria.

Después de unos días así, decidí automatizarlo. Git tiene un hook útil, prepare-commit-msg, que te permite alterar los mensajes de commit antes de que se finalicen. Creé un (script) en Bash que automáticamente obtiene la clave y número del ticket del nombre de la rama y lo inserta en el mensaje del commit, haciendo mi proceso más fluido y eficiente.

Como alguien que valora la mejora continua, comencé a añadir más características a este script. Sin embargo, se hizo evidente que mantener y probar estos cambios manualmente llevaba demasiado tiempo y era propenso a errores. Para hacer el desarrollo más seguro y eficiente, creé una función assert(enlace), permitiendo tests automatizados que verificaban el comportamiento esperado basado en la salida del script.

La función assert me permitió definir múltiples assertions en un archivo separado, facilitando la validación de que cualquier refactorización del hook original mantuviera el comportamiento esperado. Si un cambio rompía inadvertidamente la funcionalidad existente, lo señalaría instantáneamente, haciéndome saber de inmediato que algo necesitaba arreglarse. Esta configuración proporcionaba retroalimentación inmediata y ayudaba a asegurar que cualquier actualización al script no interrumpiera su lógica prevista. Por ejemplo:

En el ejemplo anterior, notarás que ejecuto el “SCRIPT” real como el segundo argumento en la función assert, comparando su salida con el valor esperado proporcionado como primer argumento. Aquí, tenemos dos casos de test, cada uno exportando TEST_BRANCH para simular cómo el mensaje del commit variaría según el nombre de la rama. Esta configuración emula el comportamiento real, permitiéndonos probar cómo diferentes nombres de rama afectan el formato del mensaje del commit. Más ejemplos aquí.

Decidí separar la función assert de los casos de test, como se muestra aquí, para mantener las cosas modulares y reutilizables. Luego, creé un runner para ejecutar cada caso de test independientemente, reduciendo la interferencia entre tests y mejorando la confiabilidad. Puedes ver esa configuración aquí. Esta estructura hizo el testing automatizado más fácil y la refactorización más segura.

Esta fue una gran mejora porque facilitó separar los casos de test de la lógica del runner de tests en sí. Esta estructura clara ha simplificado tanto la creación como la gestión de tests.

Ahora los tests estaban organizados y tuve una idea:

## Idea de seguimiento
Separar la lógica de testing en otro repositorio,
para que pueda ser reutilizada en cualquier lugar.

Y así comenzó. En ese momento, no sabía mucho sobre Bash o las mejores formas de usar un proyecto Bash como dependencia. Pero sabía que podía empezar usando un submódulo de Git, aunque no soy muy fan de ellos.

El 4 de septiembre de 2023, lancé la versión 0.1, que presentaba un runner funcional y una única función de assertion: assertEquals. Más tarde, se lanzó la versión 0.2, permitiendo que ./bashunit fuera un ejecutable independiente, ejecutable desde cualquier carpeta. Así es como se veía entonces:

Compartí el proyecto con algunos amigos que rápidamente se unieron para ayudar con la documentación, el sitio web, assertions adicionales, testing de snapshots y decisiones clave. Para enfatizar su espíritu open-source y propiedad comunitaria, lo moví a una organización que creamos específicamente para compartir proyectos OSS, convirtiéndolo en un proyecto verdaderamente colaborativo en lugar de uno individual.

¿Por qué crear otra librería de testing?

Ahora sé que existen otras librerías de testing para Bash. Pero cuando empecé con bashunit, no las conocía, y francamente, todavía no soy un experto en Bash. Para cuando me enteré de estas alternativas, ya era demasiado tarde, bashunit había ganado suficiente impulso y entusiasmo para seguir adelante.

Mientras que esas otras librerías pueden servir casos de uso específicos, usar Bash moderno, o ser desarrolladas por desarrolladores de Bash más experimentados, bashunit aspira a diferenciarse ofreciendo una gran experiencia de desarrollador, moldeada por años de trabajo con varios frameworks de testing.

Me preguntaron sobre las diferencias el 7 de septiembre de 2023, y aquí está mi respuesta: Pregunta: Diferencia con pgrange/bash_unit.

¿Cómo está hoy en día?

Hoy, puedes instalar bashunit via curl, Homebrew, MacPorts, descargando el último release de GitHub, o incluso compilándolo tú mismo desde el código fuente. Completamente open-source.

El proyecto está escrito en Bash 3.2 (de 2007) ya que esa es la versión por defecto en macOS, incluso ahora, en 2024. Esta compatibilidad significa que bashunit funciona sin problemas en esa versión, y planeo mantener el soporte para ella.

Para asegurar la calidad, probamos cada característica con tests unitarios, funcionales y de aceptación, haciendo que bashunit sea su propio “primer usuario” de cada nueva característica. También tenemos varios workflows de CI usando GitHub actions que ejecutan tests en diferentes plataformas para verificar compatibilidad y confirmar que todo funciona como se promete.

En junio de 2024, bashunit fue integrado en PHPStan para sus tests end-to-end, permitiendo el uso de las assertions de bashunit independientemente de su runner. Esta flexibilidad resultó ser muy útil.

El verano pasado, fui invitado a hablar sobre bashunit en la International PHP Conference en Berlín, junto con Manu, otro contribuidor. Este proyecto ha abierto puertas y ha llevado a mucha gratitud de usuarios que aprecian el trabajo que hemos puesto en él.

Características principales

bashunit incluye funciones clásicas del ciclo de vida como set_up, tear_down, set_up_before_script y tear_down_after_script.

También soporta una amplia gama de parámetros de línea de comandos y valores de configuración. Algunos de mis favoritos incluyen:

--parallel
--filter
--stop-on-failure
--verbose

También proporcionamos data providers para ejecutar los mismos casos de test con diferentes inputs.

Para dobles de test, bashunit ofrece mocks y spies. Estos funcionan dentro del mismo proceso que el test, pero actualmente no funcionan entre procesos, un área para mejorar.

Incluye potente testing de snapshots, facilitando la verificación de salidas de comandos o scripts a lo largo del tiempo.

bashunit ofrece un amplio conjunto de assertions nativas para casos de test, incluyendo:

assert_same
assert_equals
assert_contains
assert_matches
assert_string_starts_with
assert_array_contains
assert_successful_code
assert_general_error
assert_file_exists
assert_file_contains
assert_match_snapshot

Incluso puedes crear tus propias assertions personalizadas para extender las capacidades de bashunit.

Con más de 25 contribuidores y más de 325 estrellas en GitHub en solo un año de desarrollo en tiempo libre, estoy genuinamente orgulloso de lo que este proyecto se ha convertido.

Lightning tech talk

Recientemente, presenté una lightning tech talk en un meetup de hackers, haciendo una demo de bashunit a una audiencia de más de 100 personas. ¡Fue una experiencia increíble compartir esta herramienta con una audiencia tan comprometida!

Logo original de bashunit diseñado por Antonio.

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.

Bitcoin: A Work in Progress

2024-08-02T00:00:00+00:00

Con miles de proyectos cripto por ahí, dicen que Bitcoin es viejo y aburrido. Nada más lejos de la realidad. Este libro te guía por los últimos desarrollos de Bitcoin desde la perspectiva de uno de sus desarrolladores.

Aprenderás sobre Taproot (el último soft fork), los retos de mantener software open source libre de bugs y malware, nuevas formas de proteger nodos contra atacantes, cómo gestionar una blockchain que no para de crecer, y mucho más.

El libro enlaza a más de doscientos artículos, videos, podcasts e incluso código fuente. Y gracias a los códigos QR junto a cada enlace, nunca tendrás que escribir URLs largas.

Contenidos

Lo básico

1. Direcciones Bitcoin
2. DNS Bootstrap y Tor V3
3. SegWit
4. libsecp256k1

Uso de recursos

5. Tiempo de Sincronización y AssumeUTXO
6. Utreexo

Atacando Bitcoin

7. Ataques Eclipse
8. Nodos Falsos
9. Guix

Mejores Wallets

10. Script, P2SH, y Miniscript

Taproot

11. Taproot y Schnorr
12. Opciones de Activación

Apéndice

A. Más Episodios
B. Un crimen en Testnet
C. White Paper de Bitcoin

Enlaces relacionados

Código fuente del libro: GitHub/Sjors
Sitio web del libro: www.btcwip.com

¿Qué Es Waterfall?

2024-08-01T00:00:00+00:00

Waterfall es como seguir un camino recto donde te mueves de un paso al siguiente en un orden definido, como el agua fluyendo por una cascada a través de diferentes etapas.

El problema es que cada paso puede llevar mucho tiempo y recursos para completarse. Además, no recibes retroalimentación hasta que toda la etapa está terminada, lo que puede llevar a mucho tiempo desperdiciado. Esto es especialmente complicado en el desarrollo de software, donde las cosas siempre están cambiando y evolucionando.

Usualmente sigue una secuencia directa como esta:

La realidad de Waterfall

Waterfall puede ser como el comunismo en teoría, parece perfecto en papel pero no funciona en el mundo real.

Los clientes a menudo no saben exactamente lo que quieren.
Los requisitos están constantemente cambiando.
Los negocios necesitan adaptarse rápidamente a los cambios del mercado y las necesidades de los clientes.
El software necesita ser flexible para mantenerse al día con estos cambios.

Entonces, en un mundo en constante cambio, Waterfall puede realmente perjudicar a un negocio. Tiende a frustrar a los desarrolladores y equipos, y también puede molestar a los clientes y a los negocios que pagan por el software. Esto usualmente lleva a retrasos y costos adicionales.

Por qué las empresas aún usan Waterfall

Incluso con sus problemas, muchas empresas aún usan Waterfall porque parece directo y lógico. Esto les hace reacios a tomarse el tiempo de aprender Agile. Además, conseguir que la dirección acepte cambiar a Agile puede ser difícil de vender, especialmente ya que requiere una inversión en tiempo y aprendizaje.

El gran problema es cuando los superiores dictan exactamente cómo deben trabajar los equipos, llevando a la microgestión. Esto arruina la flexibilidad que Agile aporta. Por lo que he visto, esto es un problema común.

Mirando hacia atrás, cambiar a Agile podría haber solucionado muchos problemas.

Por qué se creó Agile

Agile fue creado para superar las limitaciones del método Waterfall. Se enfoca en la interacción constante con clientes y equipos.

Agile construye equipos autónomos y responsables que manejan tareas de principio a fin, reduciendo tiempo y recursos desperdiciados. Enfatiza la flexibilidad, la colaboración y la retroalimentación del cliente.

A diferencia de Waterfall, Agile usa desarrollo iterativo, dividiendo proyectos en pequeños sprints o iteraciones manejables que duran de 1 a 4 semanas. Cada ciclo incluye planificación, desarrollo, pruebas y revisión, con el objetivo de entregar valor rápidamente y recopilar retroalimentación para mejorar.

Aspectos clave de Agile

Desarrollo iterativo: Trabaja en pequeños fragmentos y ajusta sobre la marcha.
Colaboración con el cliente: Mantén la comunicación con los clientes para asegurar que están satisfechos.
Equipos multifuncionales: Equipos con diferentes habilidades trabajando juntos.
Planificación adaptativa: Mantente flexible y ajusta los planes basándote en la retroalimentación.
Mejora continua: Siempre busca formas de mejorar.

Lee el Manifiesto Agile original.

¿Por dónde puedes empezar?

Como desarrollador, puedes impulsar tu agilidad sumergiéndote en pair programming y TDD.

Con pair programming, dos desarrolladores trabajan lado a lado, lo que significa que obtienes retroalimentación instantánea y resolución de problemas compartida, llevando a mejor código.
TDD, por otro lado, implica escribir tests antes del código, lo que ayuda a especificar lo que quieres hacer, enfocándote en pequeños pasos.

Juntas, estas prácticas hacen tu proceso de desarrollo más flexible, colaborativo y de alta calidad, encajando perfectamente con el enfoque de Agile en ajustes rápidos y mejora continua. Ve más prácticas aquí.

La clave es colaboración, pequeños pasos y retroalimentación rápida en todo lo que trabajas.

Mi experiencia con Agile

He hablado sobre Agile en varios eventos tecnológicos y lo he explorado en profundidad porque me apasiona cómo puede potenciar a los equipos de software. Cuando se hace bien, Agile puede cambiar completamente cómo trabajan los equipos, haciéndolos más rápidos, más eficientes y mejores en entregar lo que los clientes y negocios realmente necesitan.

2022-06-26 | International PHP Conference [Berlín, Alemania] (EN)
2022-09-16 | Code Talks [Hamburgo, Alemania] (EN)
2022-10-26 | International PHP Conference [Múnich, Alemania] (EN)
2022-12-21 | IES Ginés Pérez Chirinos [Murcia, España] (ES)
2023-01-19 | devm.io [Remoto] (EN)
2023-07-28 | WeAreDeveloper World Congress [Berlín, Alemania] (EN)

WeAreDevelopers World Congress en Berlín

Pretty Good Privacy

2024-07-13T00:00:00+00:00

PGP (Pretty Good Privacy) es un programa de cifrado para proteger tu privacidad y autenticar comunicaciones. Sirve para firmar, cifrar y descifrar textos, correos, archivos, directorios y particiones de disco.

Historia

Phil Zimmermann creó PGP porque le preocupaba la falta de privacidad en las comunicaciones digitales. Quería dar a la gente herramientas de cifrado potentes. En 1991 lanzó PGP gratis, abriendo una nueva era en la seguridad digital.

Desafíos legales

A principios de los 90, el cifrado fuerte estaba clasificado como arma según la ley de exportación de EE.UU. Cuando PGP se extendió por internet, Zimmermann fue investigado por “exportar municiones”.

Su defensa fue ingeniosa: publicó el código fuente de PGP en un libro. Los libros son libertad de expresión protegida. El caso se archivó en 1996 y las restricciones de exportación se relajaron en 2000.

Características principales

Cifra y descifra datos para comunicación segura
Verifica la identidad de quien envía y recibe
Genera pares de claves pública/privada para intercambio seguro
Soporta varios algoritmos de cifrado y funciones hash

Hoy PGP sigue vivo como OpenPGP (el estándar) y GPG (GNU Privacy Guard, la implementación libre). Cuando verificas una descarga de software o firmas un commit de git, probablemente estás usando GPG.

Cómo funciona

PGP combina criptografía de clave pública y criptografía de clave simétrica. Genera un par de claves: una pública que compartes y una privada que guardas en secreto. Los datos se cifran con la clave pública y solo la privada puede descifrarlos.

Cifrado simétrico: PGP genera una clave de sesión única para cifrar el mensaje. Es rápido y eficiente, pero necesita que ambas partes compartan la clave de forma segura.
Cifrado asimétrico: Resuelve el problema del intercambio de claves. Cada usuario tiene su par de claves. La clave de sesión se cifra con la clave pública del destinatario, y solo su clave privada puede descifrarla.
Firmas digitales: El remitente firma el mensaje con su clave privada. El destinatario verifica la firma con la clave pública del remitente, confirmando quién lo envió y que el mensaje no se ha alterado.

Mi clave pública

Huella digital

56D5 D60B 0934 0999 199C 3750 E51B 5BF4 5F85 D160

Importar directamente

curl https://chemaclass.com/pgp.asc | gpg --import

Descargar el archivo .asc

Descargar clave PGP pública

Dinero Programable

2024-07-06T00:00:00+00:00

A Bitcoin se le llama “dinero programable” porque permite ejecutar transacciones con condiciones mediante su lenguaje de scripting.

Qué es el dinero programable

Dinero programable significa poder meter lógica y condiciones dentro de las transacciones financieras. Las transacciones se ejecutan solas siguiendo reglas predefinidas, sin intermediarios ni intervención manual. El dinero deja de ser algo estático y se convierte en una herramienta capaz de ejecutar acuerdos y automatizar operaciones.

El lenguaje Script

La programabilidad de Bitcoin viene de su lenguaje incorporado: Script. Es un lenguaje basado en pila, parecido a Forth, creado específicamente para transacciones de Bitcoin.

Soporta multi-firma, transferencias bloqueadas por tiempo y otras transferencias condicionales. Es intencionalmente limitado: no es Turing-completo y no tiene bucles.

Este video muestra ejemplos de los scripts de bloqueo/desbloqueo más comunes.

Características clave del Script de Bitcoin

Ejecución basada en pila

Script funciona con un modelo de pila: los comandos y datos se apilan y se procesan en orden Last-In-First-Out (LIFO).

Gasto condicional

Una transacción que solo se puede gastar si se cumplen ciertos criterios o se proporcionan datos específicos. Sirve para:

servicios de custodia
intercambios atómicos
otros arreglos financieros

Multifirma

Puedes configurar transacciones que requieran varias firmas de diferentes claves privadas. Útil para:

cuentas conjuntas
fondos corporativos
mayor seguridad (nadie puede gastar los fondos por su cuenta)

Bloqueo temporal

Las transacciones pueden tener condiciones de tiempo: no se pueden gastar hasta cierta fecha o altura de bloque. Útil para:

pagos diferidos
contratos inteligentes
evitar gastos prematuros (ej: Lightning Network)

Códigos de operación

El Script de Bitcoin usa OP_Codes para realizar operaciones específicas. Algunos ejemplos:

OP_DUP: Duplica el elemento superior de la pila.
OP_HASH160: Hashea el elemento superior de la pila dos veces (SHA-256 seguido de RIPEMD-160).
OP_EQUALVERIFY: Verifica que los dos elementos superiores son iguales y los elimina.
OP_CHECKSIG: Verifica una firma contra una clave pública.
OP_RETURN: Marca la salida de la transacción como inválida, a menudo usado para almacenar datos.

Tipos comunes de direcciones Bitcoin

Cada tipo de dirección corresponde a una forma distinta de hacer scripts. Veamos ejemplos para cada tipo principal.

P2PK: Las primeras transacciones legacy usando claves públicas completas directamente.
P2PKH: Comienza con 1. Transacciones Legacy usando hashes de claves públicas.
P2SH: Comienza con 3. Legacy, encapsula scripts complejos como multisig.
P2MS: Típicamente es un tipo de dirección P2SH o P2WSH.
P2WPKH: Comienza con bc1. SegWit nativo, transacciones más eficientes.
P2WSH: Comienza con bc1. SegWit para scripts complejos.
P2TR: Comienza con bc1p. Direcciones Taproot SegWit, mejorando privacidad y eficiencia para transacciones complejas.

Usar SegWit nativo (P2WPKH y P2WSH) es preferible cuando es posible, ya que maximiza los beneficios de la actualización SegWit, pero P2SH-SegWit puede ser útil para compatibilidad con sistemas más antiguos.

P2PK (Pay-to-PubKey) - Dirección Legacy antigua arriba

Comienza con "1" (ej., 1A1zP1eP5QGefi2DMPTf...v7DivfNa)

Antes de P2PKH y P2SH, las direcciones de Bitcoin eran más limitadas:

Empiezan con 1 pero sin hashear la clave pública.
Poco usadas hoy por falta de privacidad y eficiencia.
Formato obsoleto en favor de P2PKH como mínimo.

P2PKH (Pay-to-PubKey-Hash) - Dirección Legacy arriba

Comienza con "1" (ej., 1A1zP1eP5QGefi2DMPTf...v7DivfNa)

Un script P2PKH típico consiste en dos partes principales:

ScriptPubKey: El script de bloqueo (también conocido como script de salida) que especifica cómo pueden gastarse los fondos.
ScriptSig: El script de desbloqueo (también conocido como script de entrada) que proporciona los datos necesarios para desbloquear los fondos.

ScriptPubKey (Script de Bloqueo)

OP_DUP OP_HASH160 <PubKHash> OP_EQUALVERIFY OP_CHECKSIG

OP_DUP: Duplica el elemento superior de la pila (la clave pública).
OP_HASH160: Hashea la clave pública con SHA-256 seguido de RIPEMD-160.
<PubKHash>: La clave pública hasheada (un valor de 20 bytes).
OP_EQUALVERIFY: Verifica si la clave pública hasheada coincide con el hash en el script.
OP_CHECKSIG: Verifica la firma proporcionada contra la clave pública.

ScriptSig (Script de Desbloqueo)

<sig> <PubK>

<sig>: La firma digital generada por la clave privada.
<PubK>: La clave pública correspondiente a la dirección.

Flujo de Ejecución

El ScriptSig (script de desbloqueo) se empuja a la pila.
El ScriptPubKey (script de bloqueo) se ejecuta.

P2SH (Pay-to-Script-Hash) arriba

Comienza con "3" (ej., 3J2BtwzN2GEr6FCP.....81T2eiX8PVHh)

Los scripts P2SH se usan para scripts más complejos. La característica principal es que la dirección misma codifica un hash de un script, que se usará en la transacción.

ScriptPubKey (Script de Bloqueo)

OP_HASH160 <ScriptHash> OP_EQUAL

OP_HASH160: Hashea el script con SHA-256 seguido de RIPEMD-160.
<ScriptHash>: El script hasheado (un valor de 20 bytes).
OP_EQUAL: Verifica si el hash coincide con el hash del script proporcionado.

ScriptSig (Script de Desbloqueo)

<sig> <PubK> ... <ScriptSig>

<sig>: La firma digital.
<PubK>: La clave pública.
<ScriptSig>: El script real que coincide con el hash del script, que será ejecutado por la red Bitcoin.

P2MS (Pay-to-Multisig) arriba

Formato del Script

OP_M <M> <PubK1> <PubK2> ... <PubKN> OP_N OP_CHECKMULTISIG

OP_M: El número mínimo de firmas requeridas.
<PubK1>, <PubK2>, ..., <PubKN>: Las claves públicas involucradas en el esquema multifirma.
OP_N: El número total de claves públicas proporcionadas.
OP_CHECKMULTISIG: El opcode que verifica las firmas contra las claves públicas proporcionadas.

ScriptPubKey (Script de Bloqueo)

OP_2 <PubK1> <PubK2> <PubK3> OP_3 OP_CHECKMULTISIG

Este script significa que se requieren 2 de 3 claves públicas proporcionadas para firmar la transacción para que sea válida.

ScriptSig (Script de Desbloqueo)

<sig1> <sig2> ... <sigN> <SerializedScript>

<sig1>, <sig2>, ..., <sigN>: Las claves públicas.
<SerializedScript>: El script serializado (lo mismo que el script de bloqueo pero sin el OP_M y OP_N).

NOTA: Hay una rareza en la ejecución de CHECKMULTISIG. Ver nota al final.

P2WPKH (Pay-to-Witness-Public-Key-Hash) - Segwit arriba

Comienza con "bc1q" (ej., bc1qf0r2m0ck4psv6yrk9w.....kw8v5rj7ph3)

P2WPKH es una dirección Segregated Witness (SegWit) con un formato de scripting distinto. Simplifica las transacciones: menos datos y menos comisiones que los formatos legacy.

ScriptPubKey (Script de Bloqueo)

OP_0 OP_PUSHBYTES_20 <PubKHash>

OP_0: Un solo byte (0x00) indicando la versión del script.
OP_PUSHBYTES_20: Empuja 20 bytes (el hash de la clave pública) a la pila.
<PubKHash>: El hash de 20 bytes de la clave pública.

Datos del Testigo

En P2WPKH no hace falta un script de desbloqueo tradicional. La información de desbloqueo va como parte de los datos del testigo en el formato SegWit.

<sig> <PubK>

<sig>: Firma digital para la transacción.
<PubK>: Clave pública usada para generar el hash de la clave pública.

P2WSH (Pay-to-Witness-Script-Hash) - Segwit arriba

Comienza con bc1q (ej.: bc1q4a3h5sdg4cfkhftgd24tj9g2sg...yj57jmfckhkrw5gslr9g59)

ScriptPubKey (Script de Bloqueo)

OP_0 OP_PUSHBYTES_32 <ScriptHash>

OP_0: Indica una versión de testigo 0 (SegWit).
OP_PUSHBYTES_32: Empuja los siguientes 32 bytes (el hash del script) a la pila.
<ScriptHash>: Hash de 32 bytes del script de redención.

Datos del Testigo

<sig1> <sig2> ... <RedeemScript>

<sig1>, <sig2>: Firmas requeridas para desbloquear la transacción.
<RedeemScript>: El script real que coincide con el hash del script. Este script será ejecutado como parte de los datos del testigo.

P2TR (Pay-to-Taproot) - Taproot arriba

Comienza con bc1p (ej.: bc1pl9dfv7kvj4hj9s3a8l.....gjstmrpjl09g8ks3ukds70q4r2j5h)

Taproot combina firmas Schnorr con MAST. Permite condiciones de gasto privadas y eficientes. Las transacciones complejas parecen estandar a menos que se revelen las condiciones.

ScriptPubKey (Script de Bloqueo)

OP_1 <x-only PubK>

OP_1: Indica una versión de testigo 1 (Taproot).
<x-only PubK>: Una clave pública Schnorr de 32 bytes (sin la coordenada y).

Datos del Testigo

<sig>

<sig>: Una firma Schnorr probando posesión de la clave privada correspondiente a la pubkey x-only.

*Hay una rareza en la ejecución de CHECKMULTISIG arriba

OP_CHECKMULTISIG saca un elemento de más de la pila. Ese elemento extra se ignora al verificar firmas, así que no afecta directamente. Pero tiene que estar porque si intenta sacar de una pila vacía, el script falla.

OP_0 <sig2> <sig3> 2 <PubK1> <PubK2> <PubK3> 3 OP_CHECKMULTISIG

El script de entrada en este multisig no es <sig2> <sig3> sino OP_0 <sig2> <sig3>.

Al principio se usaba OP_0 por convención. Luego se convirtió en regla de relay y finalmente en regla de consenso (BIP147).

Puede que el desarrollador original lo pusiera pensando en añadir una función de mapa en un soft fork futuro (por rendimiento). Esa función nunca se implementó, y BIP147 en 2017 lo hace imposible ya.

Solo el creador de Bitcoin podría decir si fue un bug o un plan. Si ves un script multisig, espera encontrar un OP_0 extra al principio. Es un parche para esta rareza del consenso.

Para seguir aprendiendo

Documentación oficial de Script en el Bitcoin Wiki.
Bitcoin IDE: emulador visual de Script online, genial para aprender.
Script Editor: investigación sobre escalabilidad y usabilidad de Bitcoin.
Miniscript: lenguaje para escribir Scripts de Bitcoin de forma estructurada, con análisis, composición y firma genérica.

Dominando Bitcoin

2024-07-05T00:00:00+00:00

Este libro cubre desde los conceptos básicos hasta los aspectos técnicos más profundos de Bitcoin. Una guía excelente para entender este mundo y participar en el Internet del dinero.

La primera edición se publicó en diciembre de 2014. Diez años después, ya tenemos una tercera edición actualizada. Muy recomendable para cualquier persona interesada en este tema y la tecnología que hay detrás.

Introducción amplia a Bitcoin y su blockchain, ideal para usuarios no técnicos, inversores y ejecutivos.
Explicación técnica para desarrolladores, ingenieros y arquitectos de software.
Detalles sobre la red descentralizada, arquitectura P2P, ciclo de vida de transacciones y seguridad.
Novedades como Taproot, Tapscript, firmas Schnorr y Lightning Network.
Inmersión profunda en aplicaciones de Bitcoin: cómo combinar sus bloques de construcción en herramientas nuevas.
Historias, analogías, ejemplos y fragmentos de código que explican los conceptos clave.

Contenidos

Introducción
Cómo Funciona Bitcoin
Bitcoin Core: La Implementación de Referencia
Claves y Direcciones
Recuperación de Wallet
Transacciones
Autorización y Autenticación
Firmas Digitales
Comisiones de Transacción
La Red Bitcoin
La Blockchain
Minería y Consenso
Seguridad de Bitcoin
Aplicaciones de Segunda Capa

Libro completo también en GitHub.

Puntos clave

Tu wallet no almacena bitcoins, solo las claves para acceder a ellos. Las monedas están en la blockchain.
Entender los UTXOs es clave para entender las transacciones.
- Son outputs de transacciones anteriores que aún no se han gastado.
Una transacción necesita:
- inputs: UTXOs y un script de desbloqueo (scriptSig) que prueba la propiedad.
- outputs: dirección del destinatario y cantidad a enviar.
El script de desbloqueo usa un lenguaje llamado Script.
- La validación se hace ejecutando el script.
- Permite expresar una variedad casi infinita de condiciones.
- Script es un lenguaje basado en pila, procesado de izquierda a derecha.
Bitcoin se conoce como “dinero programable” porque permite multifirma, bloqueo temporal y gasto condicional.
- Va más allá de simples transferencias de valor.
Tipos de direcciones comunes:
- P2PKH: Empieza con 1. Transacciones estándar con hashes de clave pública.
- P2SH: Empieza con 3. Encapsula scripts complejos como multisig.
- P2WPKH: Empieza con bc1. SegWit nativo, más eficiente.
- P2WSH: Empieza con bc1. SegWit para scripts complejos.
- P2TR: Empieza con bc1p. Taproot, mejor privacidad y eficiencia.
- Bech32: Empieza con bc1. Legible por humanos, para SegWit y Taproot.
Las firmas digitales cumplen tres funciones en Bitcoin:
- Prueban que quien controla la clave privada ha autorizado el gasto.
- La prueba de autorización es innegable.
- La transacción autorizada no puede cambiarse por terceros no autenticados.
Las firmas de Schnorr no son exclusivas de la criptografía de curva elíptica (ECC) de Bitcoin, aunque hoy se asocian mucho con ella. Tienen propiedades interesantes:
- Seguridad demostrable: garantías fuertes basadas en el problema del logaritmo discreto, con pruebas formales de robustez.
- Linealidad: permite agregar múltiples firmas en una sola firma compacta, simplificando la verificación.
- Verificación por lotes: verificar múltiples firmas a la vez de forma más eficiente.
El algoritmo más conocido para compartir secretos de forma segura es Shamir’s Secret Sharing.
Ejecutar un nodo completo te da la experiencia pura de Bitcoin: verificas todas las transacciones de forma independiente, sin confiar en nadie.
Los árboles Merkle resumen todas las transacciones de un bloque, creando un compromiso con el conjunto completo y permitiendo verificar de forma muy eficiente si una transacción está incluida.
La minería es una de las invenciones que hacen especial a Bitcoin: un mecanismo de consenso descentralizado que es la base del efectivo digital P2P.
- Asegura el sistema y permite que emerja consenso a nivel de red sin autoridad central.
Un soft-fork es un cambio compatible hacia adelante en las reglas de consenso. Los clientes no actualizados pueden seguir operando con las nuevas reglas.

El Dilema del Prisionero

2024-06-27T00:00:00+00:00

El Dilema del Prisionero es un experimento mental que muestra por que a veces no colaboramos, aunque nos convenga hacerlo.

Dicho de otra forma: a nadie le gusta que se aprovechen de uno. Es teoría de juegos básica.

El dilema plantea una decisión difícil: cooperar o traicionar. Y revela mucho sobre cómo sopesamos el interés propio frente al beneficio colectivo.

Premisa

Fuente: Wikipedia

Dos miembros de una banda criminal son arrestados y encarcelados. Cada prisionero está en confinamiento solitario sin medios para hablar o intercambiar mensajes con el otro. La policía admite que no tiene suficiente evidencia para condenar a la pareja por el cargo principal.

Planean sentenciar a ambos a un año en prisión por un cargo menor. Simultáneamente, la policía ofrece a cada prisionero un trato. Si testifica contra su compañero, quedará libre mientras el compañero recibirá tres años en prisión por el cargo principal. Oh, sí, hay una trampa…

Si ambos prisioneros testifican uno contra el otro, ambos serán sentenciados a dos años en la cárcel. Se les da a los prisioneros un poco de tiempo para pensarlo, pero en ningún caso ninguno puede saber lo que el otro ha decidido hasta que haya tomado irrevocablemente su decisión.

Cada uno es informado de que al otro prisionero se le está ofreciendo exactamente el mismo trato. Cada prisionero solo se preocupa por su propio bienestar—por minimizar su propia sentencia de prisión.

Esto lleva a cuatro posibles resultados diferentes para los prisioneros A y B:

Si A y B ambos permanecen en silencio,
- cada uno cumplirá un año en prisión.
Si A testifica contra B pero B permanece en silencio,
- A quedará libre mientras B cumple tres años en prisión.
Si A permanece en silencio pero B testifica contra A,
- A cumplirá tres años en prisión y B quedará libre.
Si A y B testifican uno contra el otro,
- cada uno cumplirá dos años.

El Dilema del Prisionero Iterado

Es igual que el juego normal, pero lo juegas varias veces con el mismo oponente y sumas las puntuaciones. Puedes cambiar de estrategia entre rondas. Tiene aplicaciones reales porque se parece a cualquier relación continuada.

Todo esto tiene que ver con la confianza, cómo nos comportamos y las normas sociales que influyen en nuestras relaciones.

La mejor estrategia en el Dilema del Prisionero iterado es empezar cooperando y luego imitar lo que hizo el otro en la ronda anterior. Así recompensas la cooperación y castigas la traición.

No confíes, verifica.

The Genesis Book

2024-06-21T00:00:00+00:00

Bitcoin no surgió de la nada. Durante décadas antes de Satoshi Nakamoto, científicos informáticos, activistas de la privacidad y economistas heterodoxos intentaron crear dinero digital que funcionara sin control gubernamental. Este libro cuenta la historia de las personas y proyectos que inspiraron el primer sistema de efectivo electrónico P2P exitoso del mundo.

Contenidos

Parte I: Fundamentos

Orden Espontáneo
Libre y de Código Abierto
Dinero Neutral
Criptografía
Desnacionalización del Dinero
eCash (y Marcas de Tiempo Sin Confianza)
Los Extropianos

Parte II: Cypherpunks

El Movimiento Cypherpunk
Moneda Cypherpunk
Hashcash
Bit Gold
B-money (y BitTorrent)
RPOW

Parte III: Bitcoin

Dinero Fiat del Siglo XXI
El White Paper
El Lanzamiento

El banco central declaró a la aseguradora “demasiado grande para caer” y, junto con el Tesoro de EE.UU., la rescató con una inyección de 68 mil millones de dólares (más otros 112 mil millones en garantías).

Si el análisis de Hayek sobre economía monetaria era correcto, Bitcoin podría ayudar a arreglar la economía. Como moneda sin respaldo que operaba sin banco central, bitcoin era dinero completamente homogéneo. Cualquiera podía controlar sus propias monedas, sin preocuparse por ratios de reserva. Y como existía en internet, no tenía fronteras. Cualquiera con conexión podía descargar el software y enviar o recibir transacciones. Esta combinación (dinero homogéneo, sin fronteras y con suministro fijo) es lo que Hayek describió como dinero neutral.

Bitcoin facilitaría el comercio internacional de forma más directa: solo el comprador, el vendedor y los precios de sus productos se ven afectados, no los niveles de precios de sus países.

En Bitcoin, nadie está a cargo… y todos están a cargo.

El proyecto Fénix

2024-05-31T00:00:00+00:00

Una historia sobre un proyecto imposible donde todos juegan a la política, arreglan bugs críticos sin parar y desperdician esfuerzos en parches rápidos en vez de ayudar al negocio a prosperar.

Si IT falla, el negocio falla.

Principios DevOps: Flujo, Feedback, Aprendizaje Continuo y Experimentación. Estos conceptos impulsan mejoras en capacidad de respuesta, fiabilidad y trabajo en equipo.

Resumen

El libro empieza con la promoción de Bill a VP de IT y la responsabilidad de entregar un proyecto imposible (Phoenix). El CEO le advierte: si no se entrega a tiempo, externalizarán todo IT y despedirán a todos.

Bill intenta entender la situación y descubre que todos apagan fuegos sin parar, con demasiadas responsabilidades y poco personal. Todo es urgente, todo para ayer. La fecha límite viene de arriba, sin planificación ni conversaciones con otros departamentos. En resumen: caos corporativo, política y reuniones infernales.

Bill conoce a alguien en la empresa que le ayuda a mejorar las cosas. No le dice qué hacer, sino que le hace preguntas para que encuentre la solución por sí mismo.

Por ejemplo, la primera pregunta: “¿Cuáles son los cuatro tipos de trabajo en IT?” La respuesta no llega de golpe, sino a lo largo de la historia:

Proyectos de negocio: afectan directamente los objetivos del negocio. Generan ingresos y dan valor a los clientes.
Proyectos internos: tareas regulares que mantienen el sistema funcionando (actualizaciones, parches de seguridad…). Suelen ser invisibles y pueden convertirse en cuello de botella.
Cambios: resultado de los proyectos anteriores. Hay que saber qué cambiar y dentro de qué.
Trabajo no planificado: el verdadero asesino de la productividad. Son todos los problemas operacionales que surgen de los otros tres tipos de trabajo.

¿Qué Mata la Agilidad?

2024-05-30T00:00:00+00:00

Docenas de documentos y hojas de cálculo, reuniones tras reuniones, y sin embargo sin mucho impacto, resultan en desalineaciones del equipo, descubiertas demasiado tarde.

Cómo gestionamos una organización define su calidad. Una excelente gestión es crucial para evitar la trampa del Waterfall si buscamos construir un entorno Agile. Pero ¿por qué querríamos eso? ¿Qué hay de malo en la forma en que ya trabajamos?

Si ya estás feliz con cómo tú y tu equipo trabajan juntos, está bien. Sin embargo, ¿qué hay de reevaluar cómo trabajas para buscar mejoras potenciales?

Me refiero a evaluar tu sistema y cómo tú y las personas a tu alrededor actúan dentro de él. Lo que funcionó hace meses o años podría diferir de lo que podríamos descubrir hoy, como parte de la mejora continua.

No me gusta la política en el lugar de trabajo, donde cada equipo va a lo suyo en lugar de tener una dirección compartida más grande. Esto resulta en trabajo diario lleno de miedo desde arriba, pasado a las personas de abajo, manteniendo un ambiente de trabajo no saludable. Game of Thrones es genial como serie de ficción, pero no algo con lo que lidiar en el negocio diario.

Agile nació precisamente como respuesta al desperdicio excesivo generado por la política y la microgestión organizacional.

Controlar y el “rendimiento lento” necesitaba un enfoque más flexible. Cuando las personas adoptan una mentalidad fija, resisten el cambio, temen al fracaso y priorizan procesos rígidos y jerarquías. Esto entra en conflicto con las ideas centrales de Agile de abrazar el cambio, entrega continua con desarrollo iterativo, planificación flexible y fomentar la colaboración e innovación.

Una mentalidad fija lleva al miedo a la experimentación y una reticencia a desafiar el statu quo, reduciendo el progreso y el potencial de aprendizaje y crecimiento.

¿Qué mata la agilidad?

Mentalidad fija: Resistencia al cambio, miedo al fracaso y priorizar procesos rígidos sobre aprendizaje y adaptación estrangula la innovación y flexibilidad.
Burocracia excesiva: Procesos complejos y documentación excesiva ralentizan la toma de decisiones y la capacidad de respuesta.
Microgestión: Liderazgo demasiado controlador socava la autonomía del equipo.
Falta de colaboración: Mala comunicación y trabajo en equipo dificultan el progreso.
Bucles de retroalimentación inefectivos: Impiden ajustes y mejora continua.
Miedo a la experimentación: Una cultura que castiga el fracaso desalienta la experimentación y el aprendizaje de errores.
Procesos inflexibles: Adherencia estricta sin adaptarse a las necesidades del proyecto.
Objetivos desalineados: Prioridades conflictivas reducen la eficiencia.
Falta de apoyo del liderazgo: Sin respaldo de la alta dirección, las iniciativas Agile pueden tener dificultades para obtener los recursos y el compromiso necesarios.
Malas prácticas técnicas: Descuidar la excelencia técnica y el buen diseño puede llevar a una base de código frágil que es difícil de adaptar y extender.

¿Qué puedes hacer al respecto?

Aprende los básicos de Extreme Programming (XP) y Lean Software Development.

XP: Enfocado en prácticas de desarrollo de software y excelencia técnica, con prácticas específicas como pair programming y Test-Driven Development (TDD).
Lean: Toma un enfoque más amplio, enfocándose en eliminar desperdicio, optimizar flujo y mejorar procesos en toda la organización.

Radical Candor

2024-04-17T00:00:00+00:00

Kim Scott, ex líder de Google, desarrolló esta filosofía de gestión. Es un curso intensivo sobre cómo ser un gran manager: empático y orientado a resultados. La clave está en crear un entorno donde la gente se sienta segura para decir lo que piensa y hacer su trabajo con respeto.

Ideas clave

El estilo de mando y control frena la innovación y daña la eficiencia del equipo. La colaboración florece cuando las relaciones humanas sustituyen al acoso y la burocracia.
Radical Candor busca que managers y líderes logren juntos lo que no pueden lograr solos, preocupándose de verdad por su gente.
Se trata de ser radicalmente honesto y abierto, sin dejar de ser amable y respetuoso.

Las dos dimensiones

Preocuparse personalmente: Mostrar interés genuino en la vida, bienestar y metas de las personas. Ser humano y empático.
Desafiar directamente: Dar feedback específico, oportuno y útil, que sea amable y claro a la vez. Ser directo y orientado a resultados.

Los tres comportamientos a evitar

Agresión desagradable: Ser demasiado crítico o agresivo.
Empatía ruinosa: Ser demasiado comprensivo o permisivo.
Insinceridad manipuladora: Ser falso o manipulador en tu feedback.

Radical Candor en acción

Da elogios específicos y sinceros. Las críticas, amables pero claras.
Crea un entorno donde la gente se sienta segura para hablar con libertad.
Prioriza la colaboración y la innovación sobre el mando y control.
Preocúpate por tu equipo y desafíales a dar lo mejor de sí.

Al aplicar Radical Candor, managers y líderes construyen relaciones sólidas, motivan a sus equipos y logran mejores resultados.

Aprendiendo Concurrencia en Golang

2024-04-02T00:00:00+00:00

Quería aprender un nuevo lenguaje, así que después de probar algunos, terminé con Golang como uno de mis favoritos por su simplicidad y capacidades. Tiene características que no había usado en años, como multithreading y concurrencia.

Golang (o Go) soporta concurrencia mediante hilos ligeros llamados goroutines. Son diferentes del multithreading tradicional de Java, donde hay que manejar sincronización y coordinación para gestionar recursos compartidos de forma segura. Las goroutines son ligeras, las gestiona el runtime de Go, y son más baratas de crear y manejar.

El paralelismo es hacer varias cosas simultáneamente. La concurrencia es lidiar con varias cosas a la vez. En ambos casos, no conocemos el orden de ejecución: no sabemos qué pasará primero ni qué terminará antes.

Imagina que cocinas: preparas una sopa, una ensalada y una tortilla. Eres una sola persona, pero preparas varios platos. Podrías terminar primero la ensalada, la sopa o la tortilla… no hay garantía. Esto es concurrencia: lidias con varias cosas a la vez. Cuando tu pareja viene a ayudarte, eso ya es paralelismo.

Recuerdo haber construido un juego similar en Java cuando aprendía multithreading hace diez años. Aprovecho esta oportunidad para hacerlo de nuevo con Go moderno.

Construi un juego de terminal que simula una carrera de caballos. Cada caballo es una goroutine que corre en una matriz bidimensional compartida. Cuando un caballo llega al final, notifica al canal compartido con los demas caballos (que corren en diferentes procesos) y todos se detienen, mostrando al ganador.

Separé el código en cuatro áreas para ayudar a visualizarlo:

Punto de entrada
Generando el tablero
Renderizando el juego
Moviendo los caballos

Punto de entrada

La estructura Horse representa cada Caballo en la carrera. El juego consiste en una lista de líneas, en las cuales cada Caballo está corriendo.

type Horse struct {
 Name string // El nombre del caballo
 Line int // La línea de competición
}

func (h Horse) Letter() string {
 return fmt.Sprintf("%c", h.Name[0])
}

func (h Horse) Equals(other *Horse) bool {
 return other != nil &&
 h.Line == other.Line &&
 h.Name == other.Name
}

func (h Horse) String() string {
 return fmt.Sprintf("%s (line:%d)", h.Name, h.Line)
}

Puedes generar un nuevo proceso usando la palabra clave go al invocar cualquier función. En este juego, esto se usa 1) para renderizar el juego RenderGame() y 2) para el movimiento de cada caballo startRuningHorseInLine(). El objetivo es mantener la “renderización” y la “lógica de movimiento” trabajando en paralelo.

func main() {
 const lines, lineLength = 12, 30

 board := NewRaceBoard(lines, lineLength)
 go RenderGame(board)

 winnerChan := make(chan Horse)
 for line := range board {
 // cada caballo será movido en diferentes procesos
 go startRunningHorseInLine(board, line, winnerChan)
 }

 // esperar hasta que un caballo llegue al final
 winner := <-winnerChan
 // renderizar una última vez para asegurar el último estado del tablero
 RenderRaceBoard(board, &winner)

 fmt.Println("Race finished!")
 fmt.Printf("# Winner: %s\n", winner)
}

Generando el tablero

El tablero de carreras es una matriz bidimensional de punteros a Horses. Cada línea “contiene” un solo Caballo: solo un puntero apunta a un Caballo real, el resto son nil. Al generar el Tablero, creamos un Caballo en la primera posición de cada línea.

func NewRaceBoard(lines, lineLength int) [][]*Horse {
 board := make([][]*Horse, lines)
 for line := range board {
 board[line] = make([]*Horse, lineLength)
 board[line][0] = &Horse{
 Name: generateHorseName(),
 Line: line,
 }
 }
 return board
}

Los nombres se generan aleatoriamente usando HorseNames.

var HorseNames = [][2]string{
 {"Alloping", "Giggles"},
 {"A-lot", "Gallop"},
 {"BoJack", "Jack"},
 {"Baroness", "Belle"},
 // ...
}

func generateHorseName() string {
 name := HorseNames[rand.Intn(len(HorseNames))][0]
 surname := HorseNames[rand.Intn(len(HorseNames))][1]

 return name + " " + surname
}

Renderizando el juego

Los métodos RenderGame(), renderRaceBoard(), renderRaceLine() y renderRacePosition() están separados para que cada uno tenga una responsabilidad clara: renderizar su sujeto correspondiente.

RenderGame() se está ejecutando en otro proceso usando go.

func RenderGame(board [][]*Horse) {
 for {
 time.Sleep(renderDelay * time.Millisecond)
 RenderRaceBoard(board, nil)
 }
}

func RenderRaceBoard(board [][]*Horse, winner *Horse) {
 // usar un "buffer de string" para guardar todo el estado del tablero
 // para que luego podamos usar una sola llamada IO para renderizarlo
 var buffer bytes.Buffer
 buffer.WriteString("\n")
 for line := range board {
 renderRaceLine(board, line, &buffer, winner)
 }
 clearScreen()
 fmt.Println(buffer.String())
}

func clearScreen() {
 cmd := exec.Command("clear")
 cmd.Stdout = os.Stdout
 cmd.Run()
}

func renderRaceLine(
 board [][]*Horse,
 line int,
 buffer *bytes.Buffer,
 winner *Horse,
) {
 buffer.WriteString(fmt.Sprintf(" %.2d | ", line))
 var current Horse
 for col := range board[line] {
 h := renderRacePosition(board, line, col, buffer, winner)
 if h != nil {
 current = *h
 }
 }
 buffer.WriteString(fmt.Sprintf("| %s", current.Name))

 if current.Equals(winner) {
 buffer.WriteString(" [Won!]")
 }
 buffer.WriteString("\n")
}

func renderRacePosition(
 board [][]*Horse,
 line, col int,
 buffer *bytes.Buffer,
 winner *Horse,
) *Horse {
 if board[line][col] == nil {
 buffer.WriteString(" ")
 return nil
 }

 current := board[line][col]

 if current.Equals(winner) {
 removeChars(buffer, col+1)
 for range board[line] {
 buffer.WriteString("-")
 }
 }

 buffer.WriteString(current.Letter())

 return current
}

Moviendo los caballos

En main(...), el winnerChan es un canal compartido que usará el primer Caballo que llegue a la última posición de su línea.

Cada Caballo ejecuta un bucle hasta llegar al final de la línea o recibir (vía winnerChan) el mensaje de que otro Caballo ya ganó. Hasta entonces, cada caballo se mueve de forma independiente, durmiendo milisegundos aleatorios antes de avanzar a la siguiente posición.

startRuningHorseInLine() se ejecuta en otro proceso usando go.

func main() {
 //...
 winnerChan := make(chan Horse)
 for line := range board {
 // cada caballo será movido en diferentes procesos
 go startHorseRunning(board, line, winnerChan)
 }
 // esperar hasta que un caballo llegue al final
 winner := <-winnerChan
 //...
}

func startRunningHorseInLine(board [][]*Horse, line int, winnerChan chan Horse) {
 for {
 select {
 case <-winnerChan: // verificar si otro caballo terminó
 return // en tal caso, entonces detener el bucle for
 default:
 time.Sleep(time.Millisecond * time.Duration(rand.Intn(maxSleepDelay)))
 moveHorseOnePos(board, line, winnerChan)
 }
 }
}

func moveHorseOnePos(board [][]*Horse, line int, winnerChan chan Horse) {
 cols := len(board[line])
 for col := cols - 1; col > 0; col-- {
 if board[line][col-1] == nil {
 continue
 }
 // aquí identificamos que hay un caballo en
 // la siguiente columna, así que lo movemos a la
 // columna actual, y ponemos `nil` en la otra
 board[line][col] = board[line][col-1]
 board[line][col-1] = nil

 if col+1 == cols {
 winnerChan <- *board[line][col]
 }
 break
 }
}

Código fuente

El código de este post es una versión simplificada. Si quieres ver el código completo funcionando, está aquí: Chemaclass/go-horse-racing.

Gracias a mi antiguo Team Lead, Andrei Boar, que me ayudó a revisar mi solución original y proporcionó una solución alternativa (más simple y mejor) que apliqué a mi código. Lo principal que aprendí fue usar un chan Horse para pasar el Caballo ganador desde main(), en vez de usar un chan bool y un sync.WaitGroup entre todos los hilos.

Pair Programming Efectivo

2024-03-28T00:00:00+00:00

¿Qué es el pair programming? Dos personas trabajando juntas en el mismo problema, al mismo tiempo.

No se trata de que una persona muestre sus habilidades frente a otra, ni de que una persona tenga miedo de cometer errores debido al síndrome del impostor.

Cada persona tendrá un rol:

Navegador: prestará atención al panorama general; ej: arquitectura, relación entre colaboradores, diseño de objetos, etc.
Conductor: prestará atención a los pequeños detalles; ej: naming, convenciones de código, sintaxis de escritura, diseño de objetos, etc.

La pareja podría, y debería, intercambiar roles ocasionalmente; ej: cada X commits pusheados, cada 10 min,… depende de ellos.

El pair programming no debería considerarse una práctica solo para “seniors” hacia juniors, sino independientemente del nivel de experiencia de los miembros del equipo.

Se trata del flujo de colaboración, la comunicación de calidad, la ausencia de sentirse juzgado y la idea de dar la bienvenida a la vulnerabilidad con tus compañeros, sabiendo que te apoyarán y ayudarán.

Se trata de desafiarse constantemente mutuamente, buscando la solución más pragmática mientras se mantiene simple. Siempre buscando retroalimentación rápida al hablar entre ustedes, pero también sobre la solución que acordaron implementar y su dirección.

Se trata del bucle de retroalimentación corto, rápido e inmediato mientras hablas con tu compañero, quien revisa tu código sobre la marcha. Puedes guiar como navegador o ayudar al conductor a validar sus ideas en un panorama más amplio.

Se trata de la atmósfera constante de compartir conocimiento por defecto, reduciendo bus-factors y áreas de conocimiento aislado al máximo. Aumentando el enfoque al tener dos mentes trabajando en la misma tarea simultáneamente.

Se trata de cohesión de equipo y afilar el sentimiento de que pertenecemos. Cuando entendemos las fortalezas y debilidades de cada uno, nos daremos cuenta de cuánto podemos ayudarnos a crecer mutuamente.

¿Cómo puedes practicar pair programming?

El pair programming puede hacerse de diferentes maneras:

Puedes empezar y terminar una tarea con pairing. Puedes limitarlo a 30, 60, 90 minutos. De cualquier manera, se recomienda tener pausas en el medio - Pomodoro.
Puedes empezar la tarea juntos y parar cuando uno de tus compañeros se sienta lo suficientemente confiado para continuar solo.

Depende del equipo, y de la tarea en contexto, decidir cuándo y cómo aplicar pairing para sacar lo mejor de ello.

Esto no significa que debas trabajar constantemente “sin importar qué” en pareja. No se trata de crear reglas; por el contrario, se trata de abrazar esta práctica hasta el punto de que te sientas confiado para elegir cuándo y cómo usarla para sacar lo mejor de ella.

El pair programming podría convertirse en una de las mejores herramientas en la caja de herramientas de tu equipo para las interacciones diarias. No porque lo hayas leído en algún lugar, sino por los beneficios que tú y tu equipo encontrarán.

Patrones Comunes

Diferentes estrategias para pairing efectivo

Driver-Navigator: Una persona está conduciendo el código (con el teclado), enfocándose en el aspecto de detalle de la tarea en sí. La otra es navegadora (sin teclado), teniendo una imagen más abstracta de la tarea en mente.
Ping-Pong: Cambio frecuente de roles driver-navigator en pequeñas interacciones, ej: cada N minutos, cada N commits, etc.
Backseat driver: El navegador se involucra activamente con el conductor.
Tourist guide: El navegador aprende pasivamente con el conductor.

Anti-patrones mientras haces pairing

The silent partner: El navegador no participa, está en silencio.
The solo act: El conductor ignora todas las aportaciones del navegador.
Distracted pair: La pareja no se enfoca en el problema a resolver.
The Dictator: Una persona está diciendo qué hacer, ignorando las aportaciones del otro.
Philosophical pair: La pareja está haciendo bikeshedding en temas irrelevantes.
The code war: La pareja no llega a un acuerdo y comienza una guerra innecesaria, que desperdicia tiempo y esfuerzo.

¿Quieres más? Mira esto: Learning Through KATAS

La conclusión

El pairing no es una regla que imponer, es una herramienta a la que recurrir. Úsalo cuando la tarea es compleja, el conocimiento está aislado o lo que está en juego es importante. Sáltalo cuando el trabajo es trivial. El objetivo nunca es “hacer siempre pairing”, es mejor software y un equipo más fuerte. Elige una tarea real esta semana, hazla en pareja e intercambia roles a menudo. Los beneficios aparecen más rápido de lo que esperas.

Gracias a mi amigo Manu, quien me ayudó con este post. Incluso compartimos un taller sobre este tema.

Despliegues los Viernes

2024-02-25T00:00:00+00:00

He escuchado múltiples veces, de varias personas, la idea de pánico hacia desplegar los viernes. ¿Qué tan buena es esa idea de prohibir el día antes del fin de semana entregar nuevo valor a nuestros clientes?

El argumento principal a favor de NO desplegar el viernes se basa en la idea de que “deberíamos ser paranoicos” con nuestro software y que podría fallar cuando lo tocamos. Entonces, “deberíamos asumir” lo peor cada vez que desplegamos una nueva versión de nuestro sistema.

Sin embargo, el factor crítico aquí es ¿Por qué? ¿Por qué no deberíamos desplegar los viernes? ¿Está bien tener miedo de nuestro propio sistema de software, que vivimos en un pánico constante de romperlo el día después de haber hecho un despliegue? ¿Cuánto impacto deberían tener nuestras releases? ¿Cómo podemos asegurar que el despliegue no romperá el sistema en vivo?

Tus pipelines de Integración Continua/Entrega Continua, pruebas end-to-end y otros tipos de tests implementados, políticas de escalado automático, un sandbox de staging previo para realizar incluso pruebas manuales si es necesario, etc., determinarán la seguridad y confianza para cualquiera de tus releases. Sin embargo, la calidad de estos temas es un factor decisivo para tener suficiente confianza sobre cómo, cuándo y por qué tendría sentido hacer release a producción.

El objetivo es construir un sistema donde los despliegues a producción sean tan frecuentes, suaves y fáciles como sea posible; en cualquier momento, cualquier día. Tener miedo de tu sistema no debería ser el objetivo. Por el contrario, debería ser algo hacia lo que trabajar para solucionarlo.

Las dinámicas del equipo también son un factor esencial aquí. Si establecemos miedo a los despliegues los viernes, y miedo a nuestro sistema, eso terminará en falta de responsabilidad por defecto. Esto me recuerda a The Five Dysfunctions of a Team.

Si despliegas cambios pequeños y frecuentes tan pronto como pueden garantizar 100% de calidad y éxito de valor, ¿por qué retrasar tal mejora incremental a tu sistema?

Volviendo a “¿Por qué no deberíamos desplegar los viernes?” La única razón que se me ocurre es tener miedo de que tengamos que trabajar el sábado en la cosa rota que entregamos el viernes. Sin embargo, me pregunto si había alguna opción disponible, para que pudiéramos haber identificado tal cosa rota durante el propio viernes laborable.

Monitorear tu sistema en vivo es crucial para garantizar la salud después de cada despliegue. Esto es esencial para asegurar que todo funciona bien y sin problemas. Para construir un sistema resistente, esto debería activar alarmas para notificar a alguien responsable de abordar el problema, deshabilitar o revertir la última característica “rota”… hay muchas técnicas para crear conciencia y actuar sobre ellas.

En caso de duda, podrías usar feature flags para deshabilitar la característica que desplegarás. Aún así, prefieres no habilitarla durante el fin de semana mientras mantienes la opción de agregar valor y desplegar en cualquier momento siempre abierta.

Creo que las releases frecuentes y pequeñas a producción son clave; en cualquier momento, cualquier fecha, mientras tenga sentido, y haya un camino claro para traer valor pronto al cliente para obtener retroalimentación lo antes posible.

Entrega valor de calidad en pequeños incrementos, tan frecuentemente como sea posible.

Poder desplegar los viernes (si es necesario o deseado) impacta la confianza del equipo. De manera similar, prohibir los despliegues los viernes impacta la autoestima del equipo también.

El método Lean Startup

2024-01-26T00:00:00+00:00

La mayoría de las startups fracasan, pero muchos de esos fracasos se pueden evitar. El método Lean Startup es un enfoque que está cambiando cómo se crean empresas y se lanzan productos en todo el mundo.

Eric Ries define una startup como una organización que crea algo nuevo bajo condiciones de extrema incertidumbre. Da igual si es una persona en un garaje o un grupo de profesionales en una sala de juntas de una empresa Fortune 500. Lo que comparten es la misión de atravesar esa niebla de incertidumbre para encontrar un camino hacia un negocio sostenible.

Puntos Clave

Prueba a menudo y aprende rápido
Observa y mide el comportamiento real del cliente
Enfócate solo en métricas accionables
Aprende a pivotar según lo que descubras
Adopta nuevos métodos de contabilidad
Detecta qué no funciona y cambia de inmediato: mantente lean

Resumen

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.

Invincible

2023-12-09T00:00:00+00:00

La calidad de tu vida depende de la calidad de tu mente. Por desgracia, dedicamos poco tiempo a mejorar nuestros pensamientos, y en la escuela casi nunca nos lo enseñan. Así que pasamos por la vida sin entender realmente cómo usar nuestra mente.

Tenemos en la cabeza el objeto más sofisticado del mundo, pero apenas sabemos cómo funciona. La mayoría no consigue dirigir su fuerza mental hacia las metas que realmente desea. Se distraen, se frustran. No resisten la tentación ni perseveran ante la adversidad. Al final, abandonan.

La buena noticia es que la mente se puede entrenar, y este libro te muestra cómo. Combina filosofía estoica con psicología moderna y te da herramientas para visualizar con claridad, actuar con determinación y resistir con disciplina.

“No sufrimos por los eventos en nuestras vidas, sino por nuestro juicio sobre ellos.” Epicteto.

Todo cambio externo empieza por dentro. Si quieres transformar tu cuerpo, primero hay que trabajar la mente. Una mente débil nunca creará un cuerpo fuerte.

Este libro te ayuda a usar tu mente para mejorar tu cuerpo, pero va mucho más allá. No es una simple guía para optimizar hábitos diarios, sino una brújula para tu propia filosofía de vida. Las herramientas que desarrolles te servirán para cualquier cosa que quieras lograr. La vida siempre es más simple con claridad, determinación y disciplina.

La filosofía del Estoicismo

Forming, Storming, Norming y Performing

2023-11-25T00:00:00+00:00

En 1965, el psicólogo Bruce Tuckman creó un modelo que describe cómo un grupo se forma y madura hasta convertirse en un equipo cohesivo y efectivo.

El modelo inicialmente consistía en cuatro etapas: “forming, storming, norming, y performing,” añadiendo una adicional “adjourning” en 1977.

Los equipos no siempre avanzan de forma lineal por estas etapas. A veces vuelven a una etapa anterior según las circunstancias.

Forming

En esta etapa inicial, los miembros del equipo son cordiales pero tímidos, inseguros sobre sus roles. Dependen del líder para orientarse.

Objetivo: Los miembros se están conociendo, y hay un enfoque en definir el propósito, objetivos y roles del equipo.

Enfoque de liderazgo

Proporcionar dirección y orientación claras
Definir claramente los objetivos, roles y expectativas del equipo
Actuar como facilitador, fomentando la comunicación abierta y ayudando a los miembros del equipo a conocerse.

Storming

Surgen conflictos y desacuerdos cuando los miembros empiezan a expresar su individualidad. Pueden aparecer luchas de poder y desafíos a la autoridad del líder.

Objetivo: El equipo clarifica sus objetivos, los miembros aprenden a resolver conflictos y abordar diferencias de manera constructiva.

Enfoque de liderazgo

Facilitar la resolución de conflictos
Reconocer y abordar conflictos de manera constructiva
Fomentar la comunicación abierta y honesta mientras guía al equipo a través del proceso de entender y apreciar perspectivas diversas

Norming

La cohesión empieza a desarrollarse. Los miembros establecen normas y valores. Los roles se aclaran y surge un sentido de unidad.

Objetivo: El equipo se esfuerza por establecer normas, valores y un entendimiento compartido. Los miembros aprenden a apreciar las fortalezas y debilidades de cada uno.

Enfoque de liderazgo

Fomentar la colaboración y la inclusividad
Animar a los miembros del equipo a establecer normas y valores colectivamente
Reconocer y celebrar las fortalezas individuales, fomentando un sentido de unidad y respeto mutuo

Performing

El equipo funciona a pleno rendimiento, enfocado en lograr sus objetivos. Los miembros colaboran, confían entre sí y se apoyan mutuamente.

Objetivo: El equipo está comprometido con su propósito común y opera a un alto nivel de eficiencia y efectividad.

Enfoque de liderazgo

Empoderar la autonomía y la confianza
Proporcionar oportunidades para que los miembros del equipo tomen propiedad de tareas y proyectos
Fomentar un ambiente donde los individuos se sientan seguros de sus habilidades y puedan colaborar sin problemas

Adjourning (o Mourning)

Esta etapa marca el final de la tarea o proyecto. Los miembros pueden sentir cierta pérdida cuando el grupo se disuelve.

Objetivo: Reconocer y celebrar los logros del equipo, proporcionar cierre y reflexionar sobre la experiencia general.

Enfoque de liderazgo

Reconocer logros y proporcionar cierre
Reconocer los logros del equipo y expresar gratitud por las contribuciones individuales
Facilitar una sesión reflexiva para capturar lecciones aprendidas y crear una experiencia de cierre positiva

Para llevar un equipo a alto rendimiento usando el Modelo de Tuckman, los líderes deben conocer las etapas y adaptar su estilo según la situación.

Esto significa dar orientación y estructura en forming, facilitar la resolución de conflictos en storming, fomentar colaboración y comunicación en norming, dar autonomía en performing, y reconocer logros en adjourning.

La comunicación regular, las actividades de team-building y resolver conflictos de forma constructiva son claves durante todo el proceso.

Resumen en video

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

Conversaciones Cruciales

2023-10-31T00:00:00+00:00

Cuando hay mucho en juego, las opiniones difieren y las emociones se disparan, tienes tres opciones: evitar la conversación y sufrir las consecuencias, manejarla mal y sufrir las consecuencias, o leer este libro y aprender a comunicarte mejor cuando más importa.

Si no lo hablas, lo actuarás.

Capítulos

Conoce tu corazón
Asegura la seguridad
Cuidado con volver a tu estilo bajo estrés
Haz el contenido seguro
Controla tus emociones
Comparte tus historias
Pasa de la conversación a los resultados

Puntos clave

Una conversación crucial es una confrontación delicada con tres características:

Hay mucho en juego
Las opiniones difieren
Las emociones son fuertes

Ejemplos:

Llamar a un cliente que no ha pagado
Hablar con tu jefe sobre un ascenso que se retrasa
Confrontar a un compañero que no cumple con su parte
Discutir la herencia familiar con tus hermanos

Navegar una conversación crucial es como desactivar una bomba. Un movimiento en falso y las emociones explotan. La clave está en mantener un diálogo honesto y productivo.

Son conversaciones no planificadas. Las evitamos porque creemos que las empeoraremos. Reaccionamos mal porque somos humanos, y los humanos “se comportan peor en los momentos más críticos”.

La “Historia”

Todos llegamos a una conversación crucial con una historia ya armada:

“A mi compañero no le importa el proyecto porque no viene a las reuniones”
“A mi jefe no le importa mi carrera porque no me ha ascendido”

Si entras con esa historia en mente, no hay espacio para el diálogo. Tu mente ya decidió.

Framework Cuando… Yo…

Para abrir espacio al diálogo, asume que no conoces toda la historia. Necesitas la ayuda de la otra persona. Usa este formato:

Cuando [no vienes a las reuniones del equipo], Yo [temo que no te importe este proyecto].

Invita a la otra persona a compartir su propio “Cuando… Yo…”. Así pueden descubrir juntos el problema, malentendido o desalineación que existe.

La clave es ser asertivo y honesto con los hechos, no pasivo-agresivo. Esto reduce la actitud defensiva y facilita aclarar la situación.

Objetivo común

Para evitar el choque y volver a un diálogo productivo, convence a la otra persona de que no eres su enemigo. Estáis del mismo lado. Comunica un objetivo, valor o propósito compartido:

“No quiero pelear. Solo busco una forma de que ambos consigamos [objetivo común].”

“Sé que a los dos nos importa [valor común]. Veamos cómo conseguir lo que ambos queremos.”

Asume buena fe. Cuanto más te involucres en un diálogo productivo, más fácil será encontrar acuerdos y trabajar juntos para resolver el problema de fondo.

Keynote: Dominando el Arte de las Conversaciones Cruciales

Resumen en Video

¿Cómo Testear Métodos Privados?

2023-10-20T00:00:00+00:00

Esta pregunta me la han hecho muchas veces a lo largo de los años. Aquí recopilo mis ideas al respecto.

Respuesta corta

Nunca.

Respuesta larga

Nunca jamás.

¿Y si…?

Si realmente quieres testear un método privado, considera extraer esa lógica del método privado en una clase separada, y escribe un test unitario para el comportamiento de esa clase.

Para este, me inspiré en el post original de Fran Iglesias.

Ambiente de Trabajo No Saludable

2023-10-11T00:00:00+00:00

Un ambiente de trabajo no saludable tiene varios síntomas que afectan el bienestar físico y mental de las personas.

Cuando escribía sobre El Principio de Peter, mencioné: “Hablad entre vosotros. Si sientes que no puedes, eso es síntoma de un ambiente de trabajo no saludable, y es un problema mayor.” Pero, ¿cuáles son esos síntomas?

Síntomas

De todos los posibles, estos son los que destacaría: alto estrés, mala comunicación, falta de reconocimiento, microgestión, falta de equilibrio trabajo-vida, trato injusto, pocas oportunidades de crecimiento, conflictos tóxicos entre compañeros, falta de objetivos claros, alta rotación, baja moral y cansancio constante.

Vamos uno por uno.

Alto estrés

Estrés y presión excesivos. Puede venir de cargas de trabajo pesadas, expectativas irreales o falta de apoyo.

Mala comunicación

La comunicación ineficaz (entre compañeros, equipos o con los jefes) lleva a malentendidos, frustración y conflictos.

Falta de reconocimiento

Cuando sientes que tu esfuerzo no se reconoce ni recompensa, te desmotivas y tu satisfacción laboral baja.

Microgestión

Los jefes excesivamente controladores asfixian la creatividad y la autonomía. Eso frustra y reduce la satisfacción en el trabajo.

Falta de equilibrio trabajo-vida

Un equilibrio sano entre trabajo y vida personal es esencial. Jornadas largas, horas extra excesivas o expectativas irreales llevan al agotamiento y bajan la productividad.

Trato injusto

La discriminación, el favoritismo o las oportunidades desiguales crean una atmósfera tóxica y divisiva.

Falta de oportunidades de crecimiento

Cuando sientes que no hay espacio para avanzar profesionalmente, te desconectas y te sientes insatisfecho con tu rol.

Conflictos tóxicos entre compañeros

Desacuerdos constantes o una atmósfera hostil entre compañeros crean un ambiente tóxico.

Falta de objetivos claros

Necesitas orientación clara sobre tu rol, responsabilidades y lo que se espera de ti. Objetivos difusos o que cambian constantemente generan confusión y frustración.

Alta rotación

Si la gente se va constantemente, es señal de que el ambiente no funciona para retener talento a largo plazo.

Baja moral y motivación

Cuando la gente está desmotivada de forma constante, la productividad baja y el ambiente se vuelve negativo.

Cansancio físico o emocional constante

Exponerse mucho tiempo a un ambiente así lleva al agotamiento físico y emocional, incluso a problemas de salud mental.

Estos síntomas varían de un sitio a otro. Abordarlos rápido es clave para crear un ambiente sano y productivo.

¿Qué puedes hacer al respecto?

Tú mismo

Abraza el cambio ¿Quién se ha llevado mi queso?
El proceso en sí mismo es el objetivo Cómo enfocarse y tener autodisciplina
¿Siempre has sido así? Cómo encontrar un equilibrio entre crecimiento y felicidad

Tus managers y líderes

Gran liderazgo El liderazgo comienza dentro de tu propia vida y comportamiento
Entendiendo a las personas Malentendidos, comunicación efectiva y autorreflexión

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.

Es Tu Barco

2023-09-20T00:00:00+00:00

D. Michael Abrashoff comandó el USS Benfold, un destructor de misiles guiados. En este libro cuenta cómo transformó el rendimiento y la cultura de su barco aplicando principios de liderazgo centrados en las personas.

Puntos clave

Dar poder al equipo: Cuando la gente siente que confían en ella, se apropia de su trabajo y rinde mejor.
Escuchar y comunicar: La escucha activa y la comunicación abierta construyen confianza. Abrashoff se esforzó por conocer las opiniones y preocupaciones de su tripulación.
Liderar con el ejemplo: Los líderes marcan el estándar con sus acciones. Abrashoff trabajó para ser el modelo que esperaba de los demás.
Delegar responsabilidad: Dar control a la gente sobre sus áreas de experiencia les permite apropiarse de sus roles.
Fomentar la innovación: Abrashoff animaba a su tripulación a proponer e implementar mejoras en eficiencia y efectividad.
Celebrar los logros: Reconocer las contribuciones del equipo motiva a seguir rindiendo al máximo.
Asumir riesgos calculados: Abrashoff no dudaba en desafiar procedimientos establecidos si creía que llevaría a mejoras.
Construir confianza y respeto: Las relaciones sólidas crean camaradería y confianza mutua, pilares del liderazgo efectivo.
Ser adaptable: En entornos cambiantes, hay que ajustarse rápido a nuevas circunstancias.
Mejorar continuamente: Animó a su tripulación a buscar desarrollo profesional y aspirar siempre a la excelencia.

El libro ofrece perspectivas valiosas sobre liderazgo aplicables a cualquier organización. El enfoque de Abrashoff se centra en empoderar al equipo, fomentar la comunicación abierta y buscar siempre formas de mejorar.

El Día de los Trífidos

2023-08-13T00:00:00+00:00

Fantástico, aterrador y plausible a partes iguales. Los personajes son personas reales, arrancadas de su civilización y lanzadas al horror de un mundo dominado por los “trífidos”.

Los trífidos son plantas grotescas y peligrosas de más de dos metros. Se cultivaban por su aceite de alta calidad. Mientras los humanos mantenían el control, eran un recurso valioso. Pero un desastre global lo cambia todo. Los trífidos aprovechan su oportunidad y se convierten en una amenaza terrible.

Resumen

Resumen basado en la película “The Day of the Triffids (2009)”

¿Cómo Consigues que Todos se Sumen?

2023-08-02T00:00:00+00:00

Fui invitado al WeAreDevelopers World Congress para dar una charla técnica sobre mi experiencia con XP y los profundos beneficios de abrazar el cambio en tu trabajo y vida.

Con más de 12k asistentes, 300 speakers y ~10 tracks en paralelo, fui invitado a dar no una sino dos charlas. Una es sobre mi experiencia con Extreme Programming y los profundos beneficios de abrazar el cambio en tu trabajo y vida.

Disfruté especialmente la participación de la audiencia y las opiniones que me dieron después de cada charla. En particular, una pregunta que había enfrentado muchas veces durante mi carrera: “¿Cómo tratas con personas reacias al cambio?”

Este es uno de los temas más complejos que afecta a cualquier equipo, independientemente de su profesión. Pero, especialmente en nuestra industria del software en constante cambio, si eres reacio a abrazar el cambio, harás más daño que bien a tu equipo, carrera y a ti mismo.

Como se indica en Peopleware, “nuestra profesión del software es menos sobre computadoras y más sobre humanos y sus interacciones”. Este es usualmente el problema raíz para las personas; es un problema humano primero.

Para convertirte en verdaderamente agile, debes tener una buena base de confianza entre tus compañeros. Sin confianza, no hay equipo, y la responsabilidad principal de un buen líder es ayudar a crear un ambiente de confianza sin miedo a conflictos saludables. Todos sienten que pueden hablar y expresarse libremente en un ambiente seguro.

Un ambiente seguro significa que no necesitas llevar una armadura todo el día para protegerte de otros, así que tendrás más energía para impulsar la excelencia en tu lugar de trabajo.

Pero aún así, a pesar de tu esfuerzo por crear un ambiente de confianza y seguro, podrías encontrar personas reacias al cambio. Para esas, podrías necesitar probar diferentes enfoques. ¿Cómo puedes ayudar a crear confianza entre todos?

No tengas miedo al fracaso; en cambio, piensa que todo lo que haces es un experimento del que aprenderás algo. Y cualquier cosa que te acerque a un mejor estado es mejor que nada.

La clave aquí es encontrar una manera de conectar con las personas entendiendo cómo entienden su potencial para que puedas empoderarlas y ayudarlas a crecer.

Concede tiempo para leer

Las reuniones 1:1 son ideales para establecer conexiones personales con tus compañeros. Sin embargo, podrías sentir que la situación requiere un empujón adicional, especialmente si tienes a alguien a quien no le gusta hablar de sí mismo, y es difícil saber qué piensan sobre lo que está pasando.

Aquí hay una idea que podrías probar:

Dales un libro que contenga ideas o conocimiento que podría beneficiar a todos.
Permite leer este libro durante el tiempo de trabajo, ej: los viernes después del almuerzo. Esta es una inversión de la empresa para el desarrollo de tu equipo.
El libro debería leerse en 3-4 horas, o un par de viernes, dependiendo del número de páginas.
No esperes hasta que el libro esté terminado para hablar sobre él. Sigue el progreso.
Tendrás grandes temas para discutir durante tu próximo 1:1.

Podrías usar cualquier libro para este ejercicio

Cualquier libro estaría bien. Aún así, si estás buscando grandes ejemplos, estos son mis tres favoritos para empezar a impulsar una conversación:

Who moved my cheese? es una metáfora de las diferentes actitudes que las personas adoptan como parte de su identidad en la vida cuando tienen que confrontar cualquier cambio.
Extreme Programming Explained contiene una compilación de valores, principios y prácticas altamente relacionados con el toque humano en nuestra industria del software. Enfocándose en el aspecto del equipo, colaboración con tus compañeros y creando un sentido de maestría y propósito en nuestro oficio.
Start with Why aborda la importancia de empezar con “¿Por qué?” para definir un propósito para todo lo que hacemos.

Experimenta con cualquier libro, marco de tiempo, persona o grupo para crear un entendimiento compartido de los valores y motivaciones fundamentales del equipo. El objetivo es participar en el intercambio activo de conocimiento mientras cultivas un equipo que siente que pertenece, fomentando la pasión en el trabajo. Esto ayudará a crear confianza, y puedes empezar a construir sobre ella.

Si estás buscando libros para ayudar a escalar tus habilidades de liderazgo, aquí tienes: “Gran Liderazgo”.

No puedes forzar a las personas a cambiar. Por el contrario, cuanto más intentes forzarlo, más difícil te lo pondrán. En cambio, enfócate en entenderlas reconociendo lo que sienten y pensando sobre lo que hacen para crear un terreno común de entendimiento mutuo.

Fotos mías en WeAreDevelopers World Congress, Berlín 2023.

El Libro de Satoshi

2023-07-10T00:00:00+00:00

¿Te has preguntado alguna vez quién es Satoshi Nakamoto, el creador anónimo de Bitcoin?

Bitcoin nació en 2009 y revolucionó nuestra forma de entender el dinero. Sin gobierno ni banco central detrás, completamente electrónico, funciona gracias a sistemas criptográficos avanzados.

La identidad de Satoshi es tan virtual como la moneda que creó. Solo existe en las publicaciones online donde presentó y explicó Bitcoin en sus primeros días. Puede ser una persona o un grupo, nadie lo sabe. Este libro recopila por primera vez esos escritos esenciales.

El Libro de Satoshi permite analizar lo que su creador escribió durante los dos años de su “vida pública”, antes de desaparecer de Internet… al menos bajo ese nombre.

Su actividad pública comenzó el 1 de noviembre de 2009 con la publicación del paper fundacional. Terminó más o menos cuando PC World especuló sobre una posible conexión entre Bitcoin y WikiLeaks. ¿Existía esa conexión? Tú decides.

Probablemente nunca sabremos quién es Nakamoto. Estos escritos son todo lo que el mundo tendrá de él sobre la creación, funcionamiento y teoría detrás de Bitcoin. Si quieres aprender sobre Bitcoin, ve directo a la fuente: las palabras de su propio creador.

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.

Fahrenheit 451

2023-06-28T00:00:00+00:00

Guy Montag es bombero. Su trabajo: destruir la mercancía más ilegal que existe, los libros, junto con las casas donde se esconden. Montag nunca cuestiona lo que hace. Vuelve cada día a su vida gris y a su esposa Mildred, que pasa las horas pegada a su “familia de televisión”.

Todo cambia cuando conoce a Clarisse, una vecina joven y peculiar. Ella le habla de un pasado donde la gente no vivía con miedo. Le muestra un presente donde las ideas de los libros valen más que la charla vacía de la televisión. Montag empieza a cuestionar todo lo que siempre dio por sentado.

Resumen

Otro gran resumen: https://youtu.be/_agaWPlVG8Q

La Guerra del Tamaño de Bloque

2023-06-20T00:00:00+00:00

Este libro cuenta la guerra del tamaño de bloque de Bitcoin, que duró desde agosto de 2015 hasta noviembre de 2017. En apariencia, la batalla giraba en torno a cuántos datos podía contener cada bloque. Pero el conflicto destapó algo más profundo: quién controla las reglas del protocolo de Bitcoin.

El autor explora a los personajes principales del conflicto. Ofrece cobertura desde las trincheras y también tras bastidores, durante las fases más intensas de la lucha.

El relato incluye conversaciones con actores clave de ambos bandos. Descubrimos sus motivaciones, estrategias y formas de pensar mientras la agotadora campaña avanzaba.

Capítulos

Primer golpe
Marcha hacia la guerra
Scaling I - Montreal
Scaling II - Hong Kong
SegWit
Lightning network
Bitcoin Classic
Mesa redonda de Hong Kong
Faketoshi
The DAO
Scaling III - Milán
Bitcoin unlimited
Exchanges
ASICBoost
Dragons’s Den
Litecoin
User - Activated softfork
Acuerdo de Nueva York
Bitcoin Cash
SegWit2x
Victoria

Resumen

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

Gestión Ágil de Proyectos

2023-05-31T00:00:00+00:00

Una visión general básica y directa de lo que es Agile, presentando algunos ejemplos de frameworks bien conocidos hoy, como Scrum o Kanban—todo condensado en un libro de unas 100 páginas que puedes leer en un par de horas.

Capítulos

El manifiesto fluido
Siendo ágil
Proceso ágil
Planificando para el éxito
Comunicación ágil
Fundamentos de Scrum
Introducción a Kanban
Construyendo un equipo adaptativo
Liderazgo y gestión colaborativa
Errores comunes detrás del fracaso ágil
Palabras finales: ágil es adaptación

“Los beneficios de los proyectos Ágiles se extienden no solo al equipo que lo usa, sino también al cliente que recibe el producto final.”

“Hay una métrica crítica subyacente que consistentemente lleva al éxito de un proyecto Ágil: la comunicación. La mala comunicación, la poca comunicación, o la comunicación deficiente de cualquier tipo lleva al colapso y fracaso de dicho proyecto.”

Puntos clave

Los proyectos que seguían una metodología Waterfall tendían a exceder sus gastos con el tiempo, mientras que el producto entregado estaba por debajo del estándar y era difícil de usar.

Esa situación originó que un grupo de desarrolladores firmara un breve manifiesto de 68 palabras en 2001.

Un breve trasfondo

Durante los años 1960, el software entró en una gran crisis; crear software era complejo pero cambiarlo después se convirtió en puro caos. Waterfall al rescate.

Waterfall delineó un conjunto simple y lógico de procesos que una empresa necesitaría seguir para que un proyecto fuera exitoso. Su nombre viene de la metáfora del agua cayendo suavemente en una corriente predecible, constante e incremental. Su ciclo de vida de desarrollo de software estaría en seis pasos simples.

Requisitos
Análisis
Diseño
Código
Testing
Operaciones

Durante 10 años, Waterfall fue la metodología estándar en el universo del software. Y durante 10 años más, el caos persistió. Aunque la intención era buena, la realidad es que el conjunto siempre cambiante de restricciones no se lleva muy bien con esta metodología porque cada paso depende del anterior.

El 86% del tiempo que una empresa usa el método Waterfall para gestión de proyectos, el cliente recibe software inadecuado o inútil. Muchos proyectos de software no se usaron o nunca se terminaron.

Durante los años 70 y 80, Desarrollo Iterativo e Incremental (IID) probó ser una opción viable. En los 90 surge la Entrega Evolutiva (ED), que cambia la situación. El desarrollador es responsable de escuchar las reacciones del usuario temprana y frecuentemente. El usuario comienza a jugar un rol directo en el proceso de desarrollo.

Unos años después, surgió un nuevo método Prototipado de Producción Iterativa Rápida (RIPP), más tarde llamado Desarrollo Rápido de Aplicaciones (RAD), que afirmaba “Software funcionando en 90 días… o te devolvemos tu dinero.”

Por último, durante los 90 se definieron en detalle Extreme Programming (XP), Scrum y Crystal.

Estas soluciones distintas pero similares estaban descentralizadas, trabajando independientemente unas de otras. Esta realización llevó a esa noche en Utah la unificación de estas ideas bajo una bandera, en un documento.

Agile se convirtió en el estándar definitivo para el desarrollo de software.

El Manifiesto Ágil

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación comprehensiva
Colaboración con el cliente sobre negociación de contratos
Responder al cambio sobre seguir un plan

Es decir, aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

¿Equipos de QA Dedicados en Software?

2023-05-17T00:00:00+00:00

Esto será controvertido, pero hablemos de la posición de QA. La verdad oculta detrás de la falta de calidad del software y por qué esto debería preocuparte si escribes software.

QA es un rol, no una posición

Como desarrollador de software, cuando escribes software, eres responsable de la calidad de lo que sea que estés escribiendo. Una tercera persona actuando como QA podría encontrar que tu solución no funciona como se esperaba, pero ¿cómo es posible? Podrías argumentar que podrían encontrar casos límite, pero ¿cómo podría ser posible si el software ya fue testeado previamente?

El objetivo final de un equipo de software es hacer la posición de QA inútil porque no deberían encontrar nada más que software bien funcionando. Pero ¿cómo llegas a ese punto? ¿Cómo podemos asegurar que el software que escribimos funciona como se espera y no hay necesidad de una persona QA en nuestro equipo?

La verdad oculta detrás de la falta de calidad del software

Desafortunadamente, en nuestra industria del software, la demanda de proyectos “rápidos, rápidos y sucios” terminó en MVPs pobremente desarrollados simplemente aplicando parches y código sobre código con solo testing manual comprobando caminos felices, a veces incluso ignorando casos límite.

“La fecha límite es en una semana, ¡así que mejor termínalo a tiempo!”

No aprendemos la importancia de lo que el testing automatizado puede aportar a nuestro trabajo diario, así que no lo tomamos en serio, y por lo tanto, no lo practicamos lo suficiente. Y, por esa misma razón, porque no lo practicamos, no sabemos cómo realizarlo correctamente. ¡Sí, estoy hablando de escribir tests automatizados que prueban el comportamiento de tu software!

Nuestra incapacidad para escribir código testeable resulta en software que es difícil de testear, y por lo tanto delegamos el testing a terceros trasladando la responsabilidad de la calidad final general del producto o servicio que escribimos.

La práctica hace al maestro

Debes aprender y aplicar técnicas de testing apropiadas cuando tengan sentido. ¿Cómo y cuándo usar efectivamente dobles de test, preparar tests solitarios o sociables, qué compromisos y razones respaldan tu mente al elegir uno u otro camino hacia tus estrategias de testing?

Eres la última y principal persona responsable de tu conocimiento, así que mejor invierte en ti mismo porque nadie más lo hará por ti.

Mira todo lo que haces como una oportunidad de aprendizaje. Practica y mejora por defecto en todo lo que haces.

Si no sabes cómo empezar, aquí está mi consejo favorito: siempre puedes practicar y mejorar tus habilidades de testing usando katas de código. Lee más sobre este tema aquí.

Buena teoría, pero… ¿para qué molestarse?

El testing manual es, por supuesto, necesario. Es otra estrategia de testing que no estoy culpando o atacando. Aún podríamos necesitar una persona dedicada a cargo de descubrir qué nuevas funcionalidades queremos construir para satisfacer a nuestros clientes. Pero este post no es sobre esa posición.

Se trata de acortar el bucle de retroalimentación. Si puedes escribir software para que funcione de maneras específicas, ¿no puedes escribir tests automatizados para probar que el software que escribiste se comporta de la manera que esperas?

Si has cubierto con tests automatizados el comportamiento de tu software a cualquier nivel que tenga sentido, ¿qué queda para una persona QA dedicada?

La próxima vez que pienses “Necesitamos una persona QA para testear esto”, intenta el ejercicio de pensar en cambio, “¿Cómo puedo escribir un test automatizado que verifique lo que esperaría si una persona QA estuviera comprobando esto?”

Y así es como cambias la “posición de QA a tiempo completo” en una “mentalidad de rol para todos los que escriben software.”

El código nunca miente y nunca olvida; una vez que está escrito y automatizado en tu pipeline, puedes ejecutarlo en cualquier momento sin coste.

Trabajo Remoto Efectivo

2023-04-17T00:00:00+00:00

Un buen entorno de trabajo remoto trata a todos por igual: mismo acceso, misma información, sin importar dónde estés.

Parte 1 - Orientándose para el trabajo remoto

Establece las bases del trabajo remoto. Hoy parece sentido común, sobre todo tras el covid, cuando no tuvimos más remedio que trabajar desde casa durante más de un año. Aun así, viene bien tener estos fundamentos por escrito para cuestionar suposiciones en los siguientes capítulos.

Capítulos

Un futuro remoto: Una breve historia del futuro. Confinamiento. El remoto llegó para quedarse. Hora de prepararse.
Preparándose: La oficina: lo que queremos y lo que no. Lo básico, brevemente. En el mundo real. Instalando andamiaje mental. La regla de oro.

Parte 2 - Construyendo equipos remotos efectivos

Seguro que alguna vez trabajaste desde casa antes de que fuera tendencia y te sentiste apartado de la dinámica del equipo. Por eso “tratar a todos como remotos” es tan importante cuando al menos una persona trabaja en remoto.

La forma de comunicar depende de la urgencia, la intención y cuánto debe durar el mensaje. Es la diferencia entre comunicación síncrona y asíncrona.

La calidad de los mensajes importa tanto como el canal. Una llamada no es lo mismo que un chat o un email. Usa la herramienta adecuada para cada mensaje y contexto.

Capítulos

Tratar a todos como remotos: Ojos que no ven, corazón que no siente. Un principio para el cambio cultural. Tomando acción práctica. ¡Construyamos un modelo!
El espectro de la sincronicidad: Sincronicidad. Permanencia. Restaurando tu humanidad. Adelante a Hyrule.
Lo mismo pero diferente: Un día normal en la oficina. A través del espejo mágico. Conquistando el mundo oscuro. Descubramos algunos artefactos.
Artefactos para un futuro mejor: Comparando artefactos. Artefactos escritos. Artefactos de código base y grabados. Subiendo a bordo con el onboarding.
Onboarding y orientación: La curva de contribución. La ecuación del onboarding. Y aquí está el truco. Considerando la comunicación.
Técnicas de comunicación efectiva: Por qué los humanos comunican. Principios para mejor comunicación remota. Técnicas para mejorar las interacciones. Las herramientas correctas y cuándo usarlas. Volviéndonos hacia adentro.
Gestionándote a ti mismo: Una base organizacional. Sobre ser no observado. Navegando picos y valles. De ti mismo a los equipos.
Gestionando equipos: La ecuación de output revisitada. Reduciendo el factor de escala. Potenciando el factor de escala. Hora de subir de nivel.

Parte 3 - Creando una cultura remota de primer nivel

Puede que una empresa 100% remota no sea posible por razones que escapan a nuestro control. Pero si la empresa dice ser “remote-friendly”, hay aspectos que vale la pena evaluar:

¿Tratas a todos como remotos?
¿Proporcionas configuración de espacio de trabajo remoto?
¿Gastas dinero equitativamente en personal de oficina y remoto?
¿Optimizas para la comunicación asíncrona?
¿Creas artefactos de las interacciones síncronas?
¿Mides al personal por su impacto?
¿Permites que el personal elija horarios flexibles?
¿Los miembros del equipo ejecutivo son trabajadores remotos?
¿Usas las mejores herramientas colaborativas que el dinero puede comprar?
¿Contratas personal en cualquier parte del mundo?
¿Apoyas a las familias así como a los empleados?
¿Devuelves algo a la comunidad local del empleado?

Un “Test de Joel” adaptado al trabajo remoto. El original nació en el año 2000, durante la burbuja punto-com: preguntas de sí/no para medir la calidad de un equipo. Si respondes “sí” a todo, probablemente el equipo funciona bien. Más sobre el Test de Joel original.

Capítulos

El test de trabajo remoto: El test de Joel. Doce preguntas sobre trabajo remoto. Haciendo cambios en tu empresa. Algo que nos guíe.
Creando un handbook: El handbook de GitLab. Creando un handbook para tu equipo. Un handbook para la empresa. Haciendo el cambio completamente.
Volviéndose completamente remoto: El espectro de la remotidad. El desafío de adaptar cultura completamente remota. El triángulo de transición. Aprendiendo de pioneros. Ahora lo difícil.
Las partes difíciles: Caminando las curvas. El impacto físico y mental de trabajar remotamente. Apoyando a otros remotamente.
El camino hacia la igualdad es remoto: Diversidad e inclusión. Remoto: El gran igualador. Esto es solo el comienzo.

Resumen del libro

Introduciendo un Nuevo Stack Tecnológico

2023-04-14T00:00:00+00:00

Cuando introduces una nueva tecnología en tu equipo, necesitas explicar el porqué y tener una estrategia clara. Va a afectar a todos.

¿Por qué ese nuevo stack tecnológico?

Antes de decidir, recuerda que es una decisión de equipo. Piensa en la estandarización y mantenibilidad del proyecto. Pero lo más importante: ¿qué problema quieres resolver? ¿Es porque mola? ¿O hay una necesidad real que esta tecnología resuelve?

La dirección de la tecnología

Cuando propones adoptar una nueva biblioteca, framework o tecnología, hay que conocer su trasfondo y hacia dónde se dirige.

¿Cuál es la motivación detrás de esa tecnología? ¿Por qué quieres añadirla a tu stack actual?

Acoplamiento y dependencias

Al adoptar nuevas tecnologías en el día a día, es fácil acoplarse a ellas. Eso hace más difícil dar marcha atrás si después nos arrepentimos.

No me malinterpretes: aprender y experimentar con nuevas tecnologías está genial. Pero introducirlas en tu trabajo diario es otra historia. Afecta a todo el equipo, así que hay que ser cuidadosos.

El enfoque de la conversación

¿Qué aporta esta nueva tecnología al proyecto?
¿Qué problema queremos resolver?
¿Podemos resolverlo con nuestra tecnología actual?
Si ya tenemos algo similar, ¿queremos mezclar ambas?
¿Cuáles son los trade-offs de usarla vs. no usarla?
¿Vale la pena la complejidad extra a largo plazo?
¿Cuál es la estrategia para que todos se suban al carro?

Architectural Decision Records (ADRs)

Sea cual sea el resultado, escríbelo como un ADR para poder revisarlo con el tiempo. Un ADR documenta las decisiones del equipo: pros, contras y los argumentos que encontrasteis juntos para decidir qué hacer y por qué.

Los ADRs ayudan a entender decisiones antiguas. Guárdalos en el control de versiones, en el mismo proyecto si es posible. Son útiles para el equipo actual y para los nuevos que lleguen.

Gracias a mis amigos Manu, Antonio y Jesus, que me ayudaron a crear este resumen de ideas haciendo brainstorming juntos.

Accelerate

2023-03-19T00:00:00+00:00

Accelerate explora cómo los equipos que usan Lean Software y DevOps pueden medir su rendimiento. También muestra cómo el rendimiento de ingeniería impacta a toda la organización.

Nota: DevOps integra y automatiza el desarrollo de software (Dev) con las operaciones de TI (Ops). El foco: mejorar y acortar el ciclo de vida de desarrollo.

Capacidades Clave

Entrega Continua

Usar Control de Versiones para todos los Artefactos de Producción
Automatizar tu Proceso de Despliegue
Implementar Integración Continua
Usar Métodos de Desarrollo Basado en Trunk
Implementar Automatización de Tests
Entrega Continua (CD)

Arquitectura

Usar una Arquitectura Débilmente Acoplada

Producto y Proceso

Recopilar e Implementar Feedback del Cliente
Hacer Visible el Flujo de Trabajo a través del Value Stream
Trabajar en Lotes Pequeños
Fomentar y Habilitar la Experimentación del Equipo

Gestión Lean y Monitoreo

Tener Procesos Ligeros de Aprobación de Cambios
Monitorear la Aplicación e Infraestructura para Informar Decisiones de Negocio
Verificar la Salud del Sistema Proactivamente
Mejorar Procesos y Gestionar el Trabajo con Límites WIP (Work-In-Process)
Visualizar el Trabajo para Monitorear la Calidad y Comunicar a través del Equipo

Cultural

Apoyar una Cultura Generativa
Fomentar y Apoyar el Aprendizaje
Apoyar y Facilitar la Colaboración entre Equipos
Proporcionar Recursos y Herramientas que Hacen el Trabajo Significativo
Apoyar o Encarnar el Liderazgo Transformacional

Cuatro Métricas Clave

Lead Time de Cambio
- Tiempo para implementar, probar y entregar código para una funcionalidad
Frecuencia de Despliegue
- Número de despliegues en un período de tiempo dado
Tasa de Fallo de Cambios
- Porcentaje de cambios fallidos sobre todos los cambios (independientemente del éxito)
Tiempo Medio de Recuperación
- Tiempo que toma restaurar el servicio después de un fallo en producción

¿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?”

21 Lecciones

2023-03-11T00:00:00+00:00

Gigi presenta Bitcoin como mucho más que dinero: una inmersión en economía, filosofía y cultura. Explorar Bitcoin es como caer por la madriguera del conejo. Te enseña sobre dinero, inflación y descentralización. Redefine qué es el “buen dinero”, muestra su impacto cultural y deja claro que aprender sobre Bitcoin es un viaje personal en constante evolución.

Puntos clave

Filosofía y conceptos

Bitcoin enseña más que la educación tradicional. Ofrece perspectivas únicas sobre economía y filosofía. Involucrarse con Bitcoin se siente como caer por una madriguera, llena de aprendizaje y sorpresas.

Economía y dinero

Bitcoin recupera la idea del “dinero sólido”. Enseña sobre inflación y sistemas bancarios. Emitir dinero nuevo reduce el valor del existente; Bitcoin, con su suministro fijo, funciona diferente.

Tecnología y cultura

Las ideas centrales de Bitcoin incluyen escasez, seguridad y consenso. Pero el libro no es un manual técnico. Bitcoin refleja un giro hacia la descentralización, influenciado por el movimiento cypherpunk.

Viaje personal

Cada persona aprende lecciones diferentes de Bitcoin. El libro fomenta la exploración personal. Las lecciones evolucionan y requieren estudio continuo.

“21 Lecciones” explica por qué Bitcoin importa a nivel filosófico, económico y cultural. No se trata de cómo usarlo.

Puedes comprar el libro o leerlo gratis en su propio sitio web: https://21lessons.com/preface

Gran Liderazgo

2023-02-27T00:00:00+00:00

Cuando el negocio crece, el foco de los líderes debe pasar de los clientes a los empleados. Quiero compartir los puntos clave que cualquier líder debería trabajar regularmente.

Para cada punto tendrás recomendaciones de libros que profundizan en el tema, con referencias de expertos reales.

Ya escribí sobre la belleza del liderazgo, y como un rápido resumen, para convertirte en líder, necesitas habilidades específicas:

Excelente comunicación, dando apoyo y habilitando a tu gente
Liderar con el ejemplo, especialmente para convertirte en una mejor versión de ti mismo
Pasión por compartir tus habilidades de liderazgo, para que construyas otros líderes

Para ampliar ese post con recursos y ejemplos, aquí encontrarás libros sobre los siguientes temas:

Motivación
Liderar a través del cambio
Empoderar a tu gente
Comunicación efectiva
Persuasión
Disfunciones de equipo
Principios de gestión
Mentalidad de CEO
Liderazgo de ingeniería

Para líderes “principiantes”

Motivación

Primero necesitas definir un propósito para tu liderazgo. Recomiendo “Start with Why” (Empieza con el porqué), que ayuda a clarificar la diferencia entre grandes líderes y los que no lo son.

“La capacidad de inspirar a quienes te rodean y lograr cosas notables comienza con POR QUE.” – Empieza con el porqué

El liderazgo no es ser el jefe de nadie sino servir a otros. Deberías ser un ejemplo que tu gente copiaría y seguiría, especialmente en tiempos difíciles. Esta es una filosofía donde el líder busca servir. “Leaders Eat Last” (Los líderes comen al final) profundiza en este tema.

Si quieres más, la guinda es “The infinite game” (El juego infinito), el tercer libro de Simon Sinek. Cuestiona nuestra mentalidad al confrontar problemas de negocio: la necesidad de una causa justa, liderazgo valiente, equipos de confianza y un rival digno.

“No existe la organización ‘correcta’. Solo existen organizaciones, cada una con fortalezas distintas, limitaciones distintas y aplicaciones específicas. Una organización no es absoluta. Es una herramienta para hacer que las personas sean productivas trabajando juntas.” – The infinite game

Liderar a través del cambio

Liderar a través del cambio es algo que hay que afrontar muchas veces en la vida, te guste o no. “Who moved my cheese?” (¿Quién se ha llevado mi queso?) es una fábula sobre las diferentes actitudes que adoptamos al confrontar el cambio.

¿Cómo eliminas malos hábitos y creas buenos? “The Power of Habit” (El poder de los hábitos) y “Atomic Habits” (Hábitos atómicos) ayudan a entender que los hábitos son como un músculo. Puedes entrenarlos.

“Cambia cómo te identificas. El entorno es más importante que estar motivado. Reduce la fricción para los buenos hábitos y aumenta la fricción para los malos hábitos.” – Atomic Habits

Empoderar a tu gente

Deberías empoderar a tu gente para que se conviertan en líderes. Recomiendo “Turn the ship around!” (¡Gira el barco!), donde el autor desafía el modelo de líderes vs. seguidores hacia una relación de líderes-a-líderes.

“El liderazgo es comunicar a las personas su valor tan claramente que se inspiran para verlo en sí mismas.” – Turn the ship around!

Comunicación efectiva

La comunicación es una de las habilidades más difíciles porque constantemente te comunicas con personas de diferentes orígenes, experiencias, expectativas y visiones de la vida. Lo importante no es solo lo que dices sino cómo lo dices para que tu mensaje llegue bien al receptor.

“Leadership is Language” (El liderazgo es lenguaje) desafía el modelo de la era industrial (donde los líderes dan órdenes y los empleados las siguen), con estrategias como: controlar el reloj, colaborar, comprometerse, completar y mejorar.

“Tus palabras importan más de lo que piensas.” – Leadership is Language

Es importante reconocer nuestras emociones y no dejar que controlen nuestras acciones. Crear un ambiente abierto, honesto y seguro es clave para generar confianza.

“Dare to lead” (Atrévete a liderar) plantea que los líderes necesitan ser más vulnerables. Los valores sólidos te guían a hacer lo correcto en lugar de lo fácil. La confianza y las conversaciones difíciles importan, aunque te hagan sentir incómodo.

“Los grandes líderes deben ser valientes y siempre atreverse a dar retroalimentación constructiva, decir la verdad y ser claros sobre sus expectativas.” – Dare to lead

Persuasión

En comunicación, necesitas buenas habilidades de persuasión para convencer a otros. “Never split the difference” (Rompe la barrera del no) es un libro sobre negociación de un ex negociador de secuestros del FBI. Ofrece ideas para negociar bien: empezar escuchando, usar espejos para fomentar empatía, empatía táctica para llegar a acuerdos, etiquetar emociones…

“La negociación comienza con escuchar, haciendo que se trate de las otras personas, validando sus emociones y creando suficiente confianza y seguridad para que una conversación real pueda comenzar.” – Never split the difference

Para líderes “experimentados”

Asumiendo que has leído los libros anteriores (para “líderes principiantes”) puedo darte más recomendaciones.

Disfunciones de equipo

Una de las áreas más difíciles en comunicación es gestionar conflictos. “The Five Dysfunctions of a Team” (Las cinco disfunciones de un equipo) aborda la “ausencia de confianza, miedo al conflicto, falta de compromiso, evasión de responsabilidad e inatención a los resultados” como una pirámide de disfunciones a vigilar.

Principios de gestión

Aunque liderazgo y gestión no son lo mismo, conocer algo de teoría de gestión es útil. “High Output Management” es un gran punto de partida.

Si quieres más, recomiendo “The Essential Drucker” (Lo esencial de Drucker), que cubre los principios esenciales de la gestión.

“La gestión es sobre humanos.” – The Essential Drucker

Mentalidad de CEO

No todos los líderes quieren ser CEO, pero “The Great CEO Within” (El gran CEO interior) ayuda a entender las responsabilidades desde el punto de vista más alto de cualquier organización.

“Adapt or Die” (Adaptarse o morir) cubre los aspectos fundamentales para prosperar en cualquier negocio: Producto, Estrategia, Motor de Crecimiento, Modelo Financiero, Personas, Operaciones, Proceso y Liderazgo.

“El liderazgo es sobre ayudar a las personas a adaptarse y liderar a través del cambio para que el negocio y su gente puedan prosperar.” – Adapt or die

Liderazgo de ingeniería

Sobre ingeniería y crecimiento, recomiendo “The Manager Path” (El camino del manager) y “The Art of Leadership” (El arte del liderazgo). Ambos son fáciles de leer y llenos de sabiduría.

“Los managers te dicen dónde estás; los líderes te dicen hacia dónde vas.” – The Art of Leadership

Espero haber captado tu atención sobre las áreas clave en las que trabajar. Sé que hay muchos otros libros que podrían estar aquí. Quizás tienes otros en tu estantería. Estos son solo referencias, no necesariamente mejores o peores que otros.

Tengo muchos más libros pendientes de leer. Aun así, me pareció útil compilar estos para quienes no saben por dónde empezar o cómo convertirse en mejores líderes.

Los puntos esenciales a recordar:

Ten pasión por tu trabajo y compártela con quienes te rodean. No puedes esperar pasión de tus compañeros si tú no la tienes.
Empodera a tu gente, creando líderes en lugar de gente que sigue órdenes.
Aprende a crear un ambiente seguro, clave para la confianza y las relaciones honestas.
Ayuda a crear acuerdos al resolver conflictos. Evitar conflictos saludables no ayuda a largo plazo.
Busca oportunidades para crecer en todas partes y ayuda a tu equipo a crecer contigo.

Tu responsabilidad principal es ayudar a otros a mejorar. Y eso solo es posible si abrazas el cambio y empiezas contigo mismo.

Todos los autores mencionados

Simon Sinek: Start with Why, Leaders Eat Last, The infinite game
Spencer Johnson: Who moved my cheese?
Charles Duhigg: The Power of Habit
James Clear: Atomic Habits
L. David Marquet: Turn the ship around!, Leadership is Language
Brené Brown: Dare to lead
Chris Voss: Never split the difference
Patrick M. Lencioni: The Five Dysfunctions of a Team
Andrew S. Grove: High Output Management
Peter F. Drucker: The Essential Drucker
Matt Mochary: The Great CEO Within
Thomas H. Douglas: Adapt or Die
Camille Fournier: The Manager Path
Michael Lopp: The Art of Leadership

Extra: Leadership Guide for the Reluctant Leader

Especialmente si eres un desarrollador de software, este video es para ti.

“El liderazgo es para todos. Es para todos vosotros.”

Adapt or die

2023-02-26T00:00:00+00:00

A través de la historia de People First IT, este libro presenta El Algoritmo del Éxito: un sistema con potencial para transformar todos los aspectos de una organización.

Cada capítulo revela parte de la fórmula que las pequeñas y medianas empresas necesitan para triunfar. Con ejemplos reales, investigación y herramientas prácticas, el libro explica cómo crear innovación, resolver problemas de personas y ganar en los negocios.

“El liderazgo consiste en ayudar a las personas a adaptarse al cambio para que el negocio y su gente prosperen.”

¿Por qué fracasan los negocios?

Los negocios fracasan porque…

no pueden o no quieren tener conversaciones valientes
se enfocan en el dinero demasiado pronto, olvidando a las personas
saben crear valor pero no escalarlo
no priorizan a las personas como responsabilidad principal
se enfocan en las personas pero carecen de las habilidades para marcar diferencia
escuchan para responder, no para entender
creen que sus problemas son únicos porque su idea lo es
viven dentro del negocio sin trabajar sobre el negocio
esperan que las cosas pasen sin liderar el cambio
luchan contra la verdad en lugar de abrazarla

¿Cómo hacer crecer tu equipo?

“Cuando un negocio escala, el foco del dueño y el liderazgo debe pasar de los clientes a los empleados.”

La clave está en tener conversaciones valientes sobre las habilidades necesarias para el siguiente nivel. El objetivo: mejorar la experiencia profesional de cada persona y de quienes la rodean.

Puntos clave que todos podrían desarrollar:

Buenas comunicaciones
Enfoque y lograr metas y resultados
Todos contribuyen
Ofrecerse apoyo mutuamente
Buen liderazgo
Organización clara y buena
El conflicto constructivo impulsa la innovación

“Las personas no suelen ser el problema raíz. La taxonomía es 3Ps: producto, proceso o personas. ‘Personas’ va al final porque los líderes deben revisar primero producto y proceso. Es decir: las personas primero en valores, pero al último en culpa.”

El Algoritmo del Éxito

Como muestra el diagrama, todo esto depende del liderazgo. Si liderar es ayudar a otros a adaptarse al cambio, debe ser central en nuestras organizaciones.

Producto

Promesas
Resolver un problema o necesidad
Disparadores de liberación de efectivo
La forma en que creamos valor
Dolor o Placer
Innovación
Conexiones: Lógicas, emocionales y competitivas

Estrategia

Perfil del cliente objetivo (Quién)
Estrategia de Creación de Valor (VCS)
Valores Fundamentales
Visión compartida
Ciclo de valor
Procesos clave

El Motor de Crecimiento

Propuesta única de venta
Marketing dirigido
Canales de venta
Pasos de venta
Medición del Motor de Crecimiento
Gestión de embudo y oportunidades
Retorno sobre Ventas

El Modelo Financiero

Gestión de ingresos
Costo de bienes vendidos (COGS)
Costos de ventas y marketing
Administración general
EBITDA, ITDA, NOI
Categorización
Reportes

Personas

Alineación
Elevadores de personas
Resolución de problemas
Bancos de personas
Código de conducta del liderazgo
Planes de carrera
One-on-one’s
Gestión de ingresos

Operaciones

Identificar las operaciones centrales
Responsabilidades
Gestión de cadencia
Reuniones
GSD (Get Shit Done)

Proceso

Promesas Cumplidas
Downstream / Upstream
Responsabilidad
Repetible
Eficiencias

Puedes encontrar el libro en https://www.adaptordie.com/the-book/.

El juego infinito

2023-01-29T00:00:00+00:00

¿Cómo ganamos un juego que no tiene fin? Los juegos finitos (fútbol, ajedrez) tienen jugadores conocidos, reglas fijas y un final claro. Los juegos infinitos (negocios, política, la vida misma) son diferentes: los jugadores van y vienen, las reglas cambian y no hay línea de meta. No hay ganadores ni perdedores, solo avances y retrocesos.

Los líderes con mentalidad infinita entienden que “el mejor” no es un estado permanente. Se esfuerzan por ser “mejores”. Esa palabra sugiere un viaje de mejora constante y nos invita a contribuir con nuestros talentos y energía.

La pregunta clave es: ¿cómo jugamos para tener éxito en el juego en el que estamos? Simon Sinek ofrece un marco para liderar con mentalidad infinita:

Causa Justa
Liderazgo valiente
Equipos de confianza
Rival digno

#1 Necesitas una Causa Justa

Una Causa Justa responde a: ¿Por qué existe tu organización?

Tiene que ser una causa por la que la gente esté dispuesta a sacrificarse. Trabajar más horas, dar sus mejores ideas, rechazar otras ofertas porque creen en lo que hacen.

Para ser felices necesitamos propósito. Los negocios no son diferentes. Al desarrollar una Causa Justa, hay que defender algo inclusivo que exista principalmente para beneficio de otros.

En resumen: una Causa Justa es una visión de futuro tan convincente que la gente quiere construirlo, aunque quizá nunca lo vea terminado.

#2 Necesitas liderazgo valiente

Los líderes valientes sacrifican el corto plazo para avanzar en el largo plazo.

Liderar significa aceptar la responsabilidad de crear un ambiente donde las personas puedan dar lo mejor de sí.

Los más senior en una organización no son responsables del resultado. Son responsables de las personas que producen ese resultado.

#3 Necesitas equipos de confianza

Un equipo de confianza es un ambiente donde la gente puede levantar la mano y decir “Me equivoqué. No me siento preparado para este trabajo. Necesito formación. Necesito ayuda. Tengo miedo.” Sin miedo a humillación ni castigo.

Sin equipos de confianza, tienes un grupo de personas mintiendo y fingiendo. Y les estás forzando a ello. No es su culpa. Has creado un ambiente donde nadie comparte errores porque teme meterse en problemas. Al final, todo se acumula y explota.

El líder es responsable del ambiente. Si el ambiente es correcto, tendrás equipos de confianza. Si no, estarás forzando a la gente a protegerse de ti.

#4 Necesitas un rival digno

Tu único competidor real en un juego infinito eres tú mismo. Pero la competencia ayuda a revelar tus debilidades.

El objetivo no es ser el número uno (eso no existe en un juego infinito). Se trata de construir una base sólida y mirar a largo plazo.

El dinero es un resultado, no un propósito.

No existe la organización “correcta”. Solo hay organizaciones, cada una con fortalezas, limitaciones y aplicaciones distintas. Una organización no es absoluta. Es una herramienta para que las personas sean productivas trabajando juntas.

Los líderes con mentalidad infinita construyen organizaciones más fuertes, innovadoras e inspiradoras. Son ellos quienes nos lideran hacia el futuro.

Entrevista sobre XP y Agile

2023-01-09T00:00:00+00:00

Mi entrevista con devm.io sobre Agile y Extreme Programming.

devm.io: Hablamos con Chema, un desarrollador de software y experto en Extreme Programming, sobre su tema favorito y su próximo evento en vivo Update Your Team To Be More Extreme.

¿Podrías contarnos un poco sobre ti, quién eres y qué haces?

Chema: Mi nombre es Jose Maria Valera Reales, pero todos me llaman Chema. Soy originalmente de España pero vivo en Berlín desde 2015. He estado trabajando como desarrollador de software desde 2013. En los últimos años, me he enfocado en alcanzar la excelencia y descubrir cómo ayudar a mis compañeros y, con ellos, a toda la comunidad de software a mejorar en nuestra profesión.

Actualmente soy Tech Lead en Lautsprecher Teufel GmbH, donde trabajo con el equipo del webshop de e-commerce. También disfruto del software de código abierto, así que me gusta crear pull requests para otros repositorios, y también me encanta cuando recibo pull requests de otros.

¿Cómo describirías Extreme Programming? ¿Qué lo hace tan “extremo”?

Extreme Programming es el enfoque más directo y pragmático para abrazar Agile en tu equipo de software. Incorpora soluciones basadas en valores, principios y prácticas. No tienes que usar o hacer todo, sino lo que se ajuste a ti y a tu equipo en tu contexto. Sin embargo, estas son soluciones generales útiles que funcionan mejor cuando se combinan.

Desde mi experiencia, la palabra “extremo” puede ser engañosa, pero la veo como una oportunidad para enfatizar la dificultad de los fundamentos detrás de ella. El punto crítico es darse cuenta de que nuestro “sentido común” no es tan “común” como tendemos a pensar, ni las mejores prácticas para el trabajo en equipo efectivo. Por lo tanto, esto se trata de llevarnos a la efectividad extrema, colaboración y satisfacción mientras trabajamos con otros.

Organizarás un evento en vivo en devm.io sobre el tema el 19 de enero. ¿Podrías darnos un adelanto de lo que tu audiencia puede esperar?

Exploraremos cómo funciona un equipo de software hoy en día, los problemas comunes que encontramos y qué soluciones podríamos aplicar para mejorar las rutinas de nuestro equipo. Buscaremos el verdadero significado de Agile, enfocándonos en las ideas de Extreme Programming.

Además, compartiré algunas ideas para ayudar a tu equipo a crear oportunidades de aprendizaje con ejemplos concretos que cualquier equipo puede incorporar en su trabajo actual.

Durante el evento, también nos contarás algo sobre Katas. ¿Qué son exactamente las Katas?

El término “kata” proviene de los movimientos repetitivos hechos en karate que te ayudan a mejorar tus habilidades de combate.

¿Por qué “katas de código”? Porque como grupo, necesitamos practicar más. La mayor parte de nuestro aprendizaje ocurre en el trabajo, por lo que la mayoría de nuestros errores también se cometen allí. Y porque queremos mantener PROD, somos reacios a probar cosas nuevas.

Las katas existen para ayudar a los desarrolladores a obtener los mismos beneficios que obtendrías de la práctica en cualquier otra profesión. Estos ejercicios simples de simulación te permiten experimentar y aprender sin la presión de PROD. No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Hay katas para ayudarte a mejorar tus habilidades de refactoring (como Gilded Rose Refactoring Kata de Emily Bache) o tus habilidades de testing (fáciles como Fizz Buzz o Roman Numerals, o más avanzadas como Bank Kata de Sandro Mancuso). También son geniales para construir confianza al programar con otros, observar y practicar diferentes roles colaborativamente, fomentar la cohesión del equipo, etc.

¿Qué papel juegan los métodos Agile en el desarrollo de software para ti?

La primera pregunta aquí es definir qué son los métodos Agile. Al final, todos se comunican de alguna manera, dan retroalimentación a otros y simplifican hasta cierto nivel. A veces las personas tienen el coraje de decir lo que piensan y a veces no, y usualmente intentan respetar a sus compañeros. Así que, para mí, Agile es más sobre “cómo” haces ciertas cosas en lugar de “qué” cosas haces.

Agile es un proceso de trabajo altamente colaborativo a cualquier nivel, que podría tener una curva de aprendizaje desafiante al principio, pero vale la pena antes de lo que podrías esperar.

¿Qué tema en el área de agile debería recibir más atención?

La construcción de equipos y abrazar la agilidad, empezando por preguntar “¿por qué?” Necesitamos desafiar el statu quo más a menudo y preguntarnos por qué trabajamos de la manera en que lo hacemos y cómo y qué podríamos hacer diferente para seguir mejorando y nunca dejar de aprender.

También puedes leer la entrevista desde el enlace original: https://devm.io/agile/extreme-programming-agile.

Momo

2022-12-17T00:00:00+00:00

Un cuento de hadas moderno que refleja la lucha entre el bien y el mal en nuestra sociedad. El foco: la falta de tiempo para cuidar a quienes nos importan.

Este libro explora nuestra relación con el tiempo y cómo lo usamos (o malgastamos) en la sociedad moderna.

¿Ignorar Scrum para ser más Agile?

2022-12-06T00:00:00+00:00

Hablando con un amigo sobre agile, me hizo una pregunta interesante: a veces Agile y Scrum encajan mal, especialmente con las reuniones. Aquí van mis reflexiones.

“¿Crees que tendría sentido simplemente usar agile e ignorar scrum (sprints) completamente en una empresa basada en producto? Siento que es difícil ser agile cuando tienes 10 horas de reuniones por semana.” Filip G.

Esto conecta con la esencia de Extreme Programming: el primer valor es la Comunicación Efectiva.

“Probablemente algunas empresas no saben usar bien las reuniones y las hacen por costumbre.” Filip G.

No diría ignorar Scrum del todo. Scrum (bien hecho) es un gran “Framework de Gestión de Producto”. Para entenderlo mejor recomiendo: Scrum: The Art of Doing Twice the Work in Half the Time.

El problema principal con Scrum hoy es que la gestión tomó el control y los desarrolladores no saben practicarlo de forma realmente Agile. Ahí empieza el problema. Recomiendo Zombie Scrum Survival Guide, un libro divertido y fácil de leer que aborda los problemas típicos de equipos Scrum.

No es “Agile sí, Scrum no”. Son compatibles. El reto es enfocar los procesos del equipo desde una perspectiva agile.

Agile en pocas palabras

Recientemente escribí un post sobre fundamentos agile, que te recomiendo leer para entrar en los detalles: Trabajando agile con equipos no agile. Pero, el tl;dr: Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Agile es sobre mantener estos valores siempre presentes:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación de contratos
Responder ante el cambio sobre seguir un plan

Aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Scrum en pocas palabras

Scrum es un framework de gestión de proyectos orientado al desarrollo de software, aunque se usa en ventas, marketing y más. Está pensado para equipos de 5-9 personas (ver número de Dunbar) autónomos y responsables de dividir su trabajo en partes pequeñas para completar en iteraciones llamadas sprints (1, 2 o 4 semanas).

Las ceremonias/reuniones típicas son:

Stand-up: 15 min (o menos) para sincronizar al equipo y actuar si alguien está bloqueado o necesita ayuda.
Refinement: ~2h para asegurar que los tickets están listos antes de planificarlos.
Planning: ~2h para planificar el trabajo del siguiente sprint.
Demo/Review: ~2h para mostrar el trabajo hecho al equipo, stakeholders e interesados.
Retrospectiva: ~2h para que el equipo reflexione y mejore.

La pregunta clave es cómo organiza tu equipo estas reuniones y, sobre todo, si son efectivas. Estas son solo algunas de las reuniones de cualquier “Equipo Scrum”.

Pero además de estas, se acumulan muchas otras reuniones. De pronto el día entero se ha ido y sientes que no has producido el valor esperado. Si tu trabajo no consiste en estar en reuniones constantemente, algo está mal.

Reuniones aburridas

¿Has estado alguna vez en una reunión pensando “Esto es aburrido, qué pérdida de tiempo…”? Yo lo he vivido más de una vez. ¿A quién culpar? Esa suele ser la primera pregunta. Seguida de: “Mi jefe, obviamente. Él organizó esta reunión, me invitó, estoy obligado a asistir, y esta pérdida de tiempo es su culpa.”

No creo que sea una respuesta honesta. Culpar a otros y alejar responsabilidades es mucho más fácil que mirarse a uno mismo.

“Estoy obligado a asistir, y esta pérdida de tiempo es su culpa” puede ser cierto. Quizás estabas obligado y estás perdiendo el tiempo. Pero, ¿de verdad no hay forma de actuar al respecto?

Cuando algo no funciona como espero (no me gusta el resultado, creo que algo está mal), antes de culpar a otros prefiero reflexionar: ¿cuál es la raíz del problema? ¿Qué puedo hacer para mejorar la situación?

¿Qué puedes hacer al respecto?

Volviendo al tema de “muchas reuniones”: si estás en una que se siente mal o aburrida, pregúntate:

¿Me aburro? ¿Por qué? ¿Quizás no participo en el resultado de la reunión? Si es así, ¿mi presencia es realmente necesaria? ¿Podría pedir un resumen después y salir para hacer algo más productivo?

O al revés: ¿está bien aburrirse en esta reunión? ¿Debería participar más y contribuir al resultado?

Veo este patrón:

Si la reunión no aburre, es productiva y dará buenos resultados para todos.
Si aburre, hay dos opciones: A) está bien que aburra, pide salir educadamente y pide el resumen después; o B) no está bien que aburra porque tu participación es necesaria. Involúcrate más con tus compañeros y la reunión dejará de ser aburrida.

Hay muchas estrategias. Depende de ti actuar cuando veas algo mejorable.

Está bien señalar el “elefante en la habitación” y pedir ayuda para mejorar cualquier situación que sientas que no funciona como debería.

Recipes for Decoupling

2022-11-28T00:00:00+00:00

¿Qué es el acoplamiento y por qué nos perjudica? ¿Cómo desacoplar de forma eficiente? Este libro recopila estrategias para separar tu código de dominio de los detalles de infraestructura. El resultado: un sistema más sano a largo plazo.

Aprenderás a crear reglas de PHPStan desde cero. Además, el libro te guía por múltiples oportunidades de desacoplamiento:

framework web
frameworks cli
validación de formularios
orm y base de datos
framework de testing

Lee más sobre el libro: matthiasnoback.nl/book/recipes-for-decoupling/

Cómpralo aquí: leanpub.com/recipes-for-decoupling

Trabajando Agile con Equipos No Agile

2022-11-11T00:00:00+00:00

Asumamos que ya sabes qué es el manifiesto agile. Consideremos que aplicas la mayoría de los valores, principios y prácticas de “extreme programming”. ¿Cómo puedes trabajar con otros equipos que no son agile?

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación de contratos

Responder ante el cambio sobre seguir un plan

Estás usando bucles de retroalimentación cortos, donde las cosas cambian constantemente. Puedes sentir que el equipo está vivo y cada uno es esencial.

Abrazas el cambio hasta el punto de que disfrutas saliendo de tu zona de confort cuando es necesario. Buscando crear valor para tu equipo y sus dinámicas, y siempre considerando el crecimiento personal.

Pero claro, asumamos todo eso, y todo lo demás que pueda haber olvidado respecto a la “agilidad”, ¿cómo podrías trabajar con un equipo externo que no es agile? ¿Cómo podría tu “equipo perfectamente agile” trabajar con otro grupo de personas que no tiene nada que ver con software? Por ejemplo, un médico.

Un médico no tiene tiempo para aprender sobre tus “valores y principios agile para desarrollo de software”. Un médico no tiene tiempo para aprender sobre “extreme programming”. De manera similar, no tienen tiempo para aprender sobre testing, diseño, arquitectura y buenas prácticas relacionadas con el software en general.

¿Cómo podrías crear un puente entre ese médico y tu equipo de software?

¿Cómo podrías trabajar agile con ese médico?

Si necesitas trabajar con ese médico es porque él/ella debería ser un experto de dominio. Sugiero que uno o dos miembros de tu equipo se reúnan con ese experto durante 30/60 min, para que puedan hablar y compartir sus impresiones. Y luego repetir esto tanto como sea posible para acortar el bucle de retroalimentación. Por ejemplo, una vez a la semana.

Recopilar esos requisitos e impresiones de los expertos y luego dirigir el diseño de tu software de acuerdo con eso es Domain-Driven Design. Puedes encontrar mucha documentación sobre DDD en libros (como Domain-Driven Design Distilled) o en muchos blogs en Internet.

Sin embargo, el aspecto crítico aquí no es qué requisitos o impresiones se están resolviendo sino cómo. ¿Cómo podrías trabajar agile con ese médico?

Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Al aplicar verdaderamente estos cinco valores, ya estás actuando de forma agile

Comunicación
Retroalimentación
Simplicidad
Coraje
Respeto

Estos objetivos abstractos aplican a cualquier profesión, e incluso a la vida, no solo al software.

La comunicación continua ayuda a acortar el bucle de retroalimentación, lo que simplifica las tareas. Siempre con el coraje de abordar la verdad y respeto mutuo.

Las prácticas son las cosas que haces

Sentarse Juntos
Pair Programming
Test First
Diseño Incremental
y muchas más

Y a pesar de tener un nombre técnico, podrían aplicar a cualquier profesión:

Sentarse Juntos & Pair Programming: pensar y hacer con otros compañeros

Test First: verifica tus suposiciones primero, luego resuelve el problema

Diseño Incremental: lo que sea que hagas, hazlo mejor incrementalmente

Los principios guían y motivan las prácticas hacia los valores

Beneficio Mutuo
Diversidad
Fracaso
Oportunidad
Pasos Pequeños
Calidad
y muchos más

El beneficio mutuo es el más importante porque se trata de encontrar prácticas que nos beneficien ahora, a nosotros después, y también al cliente.

Otros principios incluyen la diversidad de ideas. No tengas miedo del fracaso. Mira todo lo que haces como una oportunidad de aprendizaje. Evita pasos gigantes porque tienen mayor riesgo de fallar. Apunta a un sistema de alta calidad porque son más predecibles y más fáciles de cambiar.

La pregunta permanece: ¿eres agile?

Creo verdaderamente que un equipo agile es el que puede lidiar con el cambio a nivel de equipo. Por lo tanto, primero debes dominar agile dentro de tu equipo, y luego puedes colaborar con otros equipos de “manera agile”.

Una vez que hayas interiorizado estos puntos anteriores, puedes aplicarlos mientras trabajas con cualquier persona de cualquier equipo.

Aunque estas ideas aisladas son buenas, son aún más poderosas cuando se combinan. Crean una atmósfera de curiosidad y aprendizaje activo. Incluso podría despertar alguna pasión por tu profesión que construye un aura de cohesión de equipo, y así sin más, el equipo respira por sí mismo.

Todos se preocupan y asumen plena responsabilidad de mantener al equipo saludable construyendo confianza. No hay miedo a conflictos saludables. Se sienten empoderados y responsables de sus compromisos. El equipo celebra sus resultados y aprende de sus errores; ya no hay necesidad de máscaras.

Es entonces cuando la magia empieza a suceder, y de repente puedes trabajar agile con cualquier equipo, especialmente el tuyo.

Lo esencial de Drucker

2022-10-29T00:00:00+00:00

Una selección de veintiséis textos sobre gestión organizacional, el individuo y la sociedad.

El libro cubre los principios básicos de la gestión junto con sus problemas, desafíos y oportunidades. Ofrece a managers, ejecutivos y profesionales las herramientas necesarias para afrontar lo que la economía y la sociedad del mañana les exigirán.

4 Principios Esenciales de la Gestión

La gestión trata sobre humanos
La gestión debe definir los valores, objetivos, metas y misión de una organización
La gestión debe permitir que la organización y sus miembros crezcan y se desarrollen
Los resultados solo existen fuera de la organización

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.

Contexto

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.

Gracias a mi anterior Engineering Manager, Evgenii Sokolov, quien me inspiró a escribir estas líneas adicionales después de compartir el post original.

Atrévete a liderar

2022-09-30T00:00:00+00:00

El liderazgo no va de títulos, estatus ni poder sobre los demás. Los líderes reconocen el potencial en las personas y las ideas, y se comprometen a desarrollarlo. Este libro es para quienes están listos para elegir el coraje sobre la comodidad y marcar la diferencia.

Coraje y vulnerabilidad

Los líderes necesitan ser más vulnerables

El problema es que la mayoría de las personas asocian esa vulnerabilidad como sinónimo de debilidad, pero eso no es cierto.

“La vulnerabilidad es la emoción humana universal que sentimos cuando nos exponemos a otros durante momentos de riesgo o incertidumbre.”

Y de esto se trata el núcleo del liderazgo: el coraje para actuar como debemos a pesar del miedo, la incertidumbre o el peligro en nuestro camino.

Valores

El lugar de trabajo moderno puede sentirse como una “arena de gladiadores”. Aunque puede que no sea una cuestión de vida o muerte, todavía requiere valentía, y mucho esfuerzo y lágrimas, al punto de que podemos sentirnos tan abrumados que estamos tentados a irnos. Entonces, según Brené:

“Una de las fuentes más significativas de motivación para aguantar es tener absolutamente claros nuestros valores fundamentales.”

Los valores son los ideales que tenemos y que dan propósito a lo que hacemos en nuestra vida. Nos guían y nos dan algo a lo que aferrarnos durante tiempos oscuros y difíciles. Los valores fuertes nos guían a hacer lo correcto en lugar de lo fácil.

Honestidad

Un gran líder fomenta el potencial en las personas y posee el coraje de guiar este potencial mientras se desarrolla. Una de las habilidades críticas para hacer esto es el coraje y la capacidad de dar retroalimentación honesta y abierta.

Desafortunadamente, muchos líderes tienen miedo de dar retroalimentación difícil y dejan a sus empleados en la oscuridad. Sí, a veces la verdad duele, pero a menudo evitamos las conversaciones difíciles porque nos hacen sentir incómodos a nosotros.

“Los grandes líderes deben ser valientes y siempre atreverse a proporcionar retroalimentación constructiva, decir la verdad y ser claros sobre sus expectativas.”

A largo plazo, esto es más amable y más productivo.

Confianza

“La confianza es un aspecto esencial de nuestras relaciones laborales.”

7 comportamientos que fomentan la confianza

Expresados junto con el acrónimo: BRAVING

Establecer Boundaries (Límites) - respetar los límites de cada uno
Reliability (Fiabilidad) - lo que significa seguir las palabras con acciones
Accountability (Responsabilidad) - ser responsable y reconocer los errores
Vault (Bóveda) - la capacidad de mantener privada la información confidencial
Integrity (Integridad) - elegir el coraje sobre la comodidad
Non-judgment (No juzgar) - hablar entre nosotros sin juzgar
Generosity (Generosidad) - asumir que las personas se encuentran contigo con las mejores intenciones

Fracaso

La capacidad de fracasar y recuperarse de ello es una habilidad esencial para cualquier gran líder. El miedo al fracaso nos frena y nos impide alcanzar la verdadera grandeza.

Es crucial quitarse la armadura del perfeccionismo y saltar a la incertidumbre de la vida. Solo de esta manera ganamos realmente el coraje para tener éxito y liderar.

Resumen

La Belleza del Liderazgo

2022-09-25T00:00:00+00:00

El liderazgo no es sinónimo de gestión, no tiene nada que ver con títulos o atributos personales. Entonces, ¿qué es? ¿Cómo podemos convertirnos en líderes? Y lo más importante, ¿por qué?

Investigando este tema, encontré “What is leadership” de Kevin Kruse, que me gustó mucho. Quiero compartir los puntos clave de ese post porque explica muy bien qué es y qué no es liderazgo.

¿Qué no es liderazgo?

El liderazgo no tiene nada que ver con títulos. Tener un cargo de nivel C no te convierte automáticamente en líder. No necesitas un título para serlo.

Tampoco tiene que ver con atributos personales. No hace falta ser extrovertido ni carismático para practicar el liderazgo.

Liderazgo y gestión no son lo mismo. Gestionar implica planificar, medir, monitorear, coordinar, resolver, contratar, despedir… Los managers gestionan cosas. Los líderes lideran personas.

¿Qué es liderazgo?

“Un líder es alguien que tiene seguidores.” Peter Drucker.

Esta definición es demasiado simplista y puede ser peligrosa. Que tengas personas “bajo ti” haciendo lo que dices porque “siguen órdenes” no te convierte en líder. Podrías ser un comandante, pero no necesariamente un líder.

“La capacidad de traducir la visión en realidad.” Warren Bennis.

Cada sprint, visualizas frutos en tu jardín. Y trabajas hacia ello y lo haces realidad. Esto te hace jardinero, no líder.

“Los líderes serán aquellos que empoderen a otros.” Bill Gates.

Empoderar a otros es esencial, pero falta la visión u objetivo común.

“El liderazgo es influencia.” John Maxwell.

Un manager tiene el poder de despedir miembros del equipo, lo que da mucha influencia. Igual que un ladrón con pistola tiene “influencia” sobre sus víctimas. Nos falta la fuente de esa influencia.

Entonces, ¿qué tal combinarlas todas?

“El liderazgo es un proceso de influencia social, que maximiza los esfuerzos de otros hacia el logro de un objetivo.” Kevin Kruse

Elementos clave de esta definición:

El liderazgo comienza desde la influencia social, no la autoridad o el poder
El liderazgo requiere otros, no necesariamente subordinados directos
Incluye un objetivo
No hay mención de un título o atributos de ningún tipo

Fin de los puntos clave de “What is leadership” por Kevin Kruse.

¿Por qué alguien querría convertirse en líder?

Hay dos concepciones diferentes en esta pregunta, y conviene separarlas desde el principio.

Por un lado está el “título de líder”, asociado normalmente con puestos de gestión. No me refiero a eso. Puedes ser un gran manager y un pésimo líder.

Un líder es alguien con actitud de multiplicador. Busca desarrollar habilidades (relacionadas con su influencia social) para potenciar el valor que genera.

Entonces, ¿puede cualquiera convertirse en líder? ¿Cuáles son esas habilidades necesarias?

¿Puede todo el mundo convertirse en líder?

Con esta definición clara, podemos ver que el liderazgo tiene distintos grados según la persona y las responsabilidades que quiera asumir.

Para convertirte en líder necesitas habilidades específicas. Estas son las que considero más importantes:

Excelente comunicación, dando apoyo y habilitando a las personas a tu alrededor
Liderar con el ejemplo, especialmente para convertirte en una mejor versión de ti mismo
Pasión por compartir tus habilidades de liderazgo, para que construyas otros líderes

El liderazgo comienza dentro de tu propia vida y comportamiento.

Sé que no todos quieren aceptar los cambios necesarios para convertirse en líder. Pero creo de verdad que cualquiera puede desarrollar ciertas habilidades de liderazgo, lo que también significa inspirar a quienes te rodean.

¿Cómo convertirse en un mejor líder?

Puedes inspirarte en muchas fuentes. Aprendes de tus errores y éxitos, y de quienes te rodean. Pero también es muy útil escuchar la sabiduría de gente fuera de tu círculo: podcasts, charlas TED, libros, audiolibros…

La belleza del liderazgo es que no pide permiso. Ni título, ni promoción, ni organigrama. Empieza en el momento en que decides elevar a quienes te rodean.

Entendiendo a las Personas

2022-08-22T00:00:00+00:00

Uno de los mayores retos es evitar malentendidos y aceptar que los demás no piensan igual que tú.

Percepciones diferentes

Cada persona tiene experiencias y antecedentes distintos. Todos percibimos la realidad de forma diferente. Ser consciente de esto es el primer paso para entender tu rol en la comunicación con otros, y para desarrollar empatía.

Muchas veces, el verdadero problema detrás de la fricción en un equipo es la mala comunicación. A veces nadie sabe cómo ni por qué dos miembros del equipo ya no se llevan bien. Pero el conflicto es obvio.

El problema es que impide al equipo trabajar con eficacia. La razón suele ser la incapacidad de entender las motivaciones y problemas del otro.

Y eso lleva a malentendidos.

Malentendidos

Lo que tú entiendes de una conversación puede diferir de lo que percibe la otra persona. Eso causa problemas. Y puede convertirse en algo serio que afecte la relación entre ambas partes.

¿Cómo resolverlo?

Evitar malentendidos no es fácil, pero puedes mejorar paso a paso trabajando tus habilidades de comunicación.

Empatía

Empatía es la capacidad de entender lo que sienten otras personas. Ver las cosas desde su punto de vista e imaginarte en su lugar. Ponerte en su posición.

Comunicación efectiva

La solución no suele empezar por arreglar a la otra persona. Lo que ayuda es trabajar en ser más explícito. Por ejemplo:

Clarifica las expectativas sobre el objetivo común
- Crea conversaciones abiertas y honestas sobre lo que esperas
- Las suposiciones son peligrosas
Da tanto contexto como sea necesario
- Aunque te parezca evidente
Cada detalle cuenta
- Más información siempre es mejor que menos

Para comunicarnos bien, hay que reducir el riesgo de malentendidos al mínimo.

Autorreflexión

Los conflictos saludables son normales y aceptables. No hay que tener miedo a los desacuerdos. Está bien cambiar de opinión al descubrir nuevas posibilidades. Cuanto antes, mejor.

En mi experiencia, entender a las personas es complicado por muchas razones. Pero sobre todo por los malentendidos que generamos por falta de contexto, más que por desacuerdos reales.

Si algo no funciona como esperabas, empieza mirándote a ti mismo. No culpes a otros. ¿Qué podrías haber dicho para crear más claridad? ¿Qué harías diferente?

La autorreflexión es esencial para mejorar y corregir tu actitud. Para adaptarte al cambio constante que nos rodea, especialmente cuando tratas con personas.

Mira más allá de tu área de influencia. Comparte tus ideas y no te avergüences de tus errores si los tomas como oportunidades de aprendizaje.

Continuous Discovery Habits

2022-08-21T00:00:00+00:00

Este libro te enseña cómo product managers y diseñadores pueden crear productos que realmente impacten la vida de sus clientes. Propone un proceso claro de toma de decisiones para equipos de producto que quieran mejorar continuamente.

Parte 1: ¿Qué es el descubrimiento continuo?

El Qué y Por Qué del Descubrimiento Continuo
Un Framework Común para el Descubrimiento Continuo

Parte 2: Los hábitos de descubrimiento continuo

Enfocarse en Resultados Sobre Outputs
Visualizar Lo Que Sabes
Entrevistas Continuas
Mapear el Espacio de Oportunidades
Priorizar Oportunidades, No Soluciones
Ideación Potenciada
Identificar Suposiciones Ocultas
Probar Suposiciones, No Ideas
Medir el Impacto
Gestionar los Ciclos
Muestra Tu Trabajo

Parte 3: Desarrollando tus hábitos de descubrimiento continuo

Empieza Pequeño e Itera
¿Qué Sigue?

Enfocarse en resultados sobre outputs te ayudará a crear los productos correctos para tus clientes.

El Qué y Por Qué del Descubrimiento Continuo

El Gran CEO Interior

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

Matt Mochary hace coaching a CEOs de las empresas tech de más rápido crecimiento en Silicon Valley. Comparte sus herramientas de liderazgo y operaciones con cualquier CEO o manager del mundo.

El libro enseña a escalar tu negocio de startup a empresa con sistemas de responsabilidad, resolución de problemas y feedback transparente.

Leer, hablar con expertos, practicar y enseñar son las mejores formas de aprender y mejorar.

3 ideas clave

Aprende a gestionarte a ti mismo antes de gestionar tu negocio.
No ignores los conflictos. Sé transparente, da y recibe feedback a menudo, y escucha activamente.
Obsesiónate con conocer a tu cliente. Haz mejores preguntas.

Resumen

El equipo

Evita sociedades 50/50. Aunque suena ideal, genera problemas cuando hay que desempatar.
Busca un socio con habilidades complementarias. Dale un buen porcentaje de la empresa; vale la pena.
El equipo fundador no debería crecer más de seis personas hasta tener product-market fit (PMF).
Las métricas de PMF importan: ingresos, tasas de renovación…

Hacer las cosas

Lee “Organízate con Eficacia” (Getting Things Done) de David Allen.

Inbox cero

Mantén tu bandeja de entrada limpia, como el triaje de un hospital.
- Distingue lo urgente de lo que no lo es.

Meta principal

Reserva dos horas cada día para trabajar solo en tu meta principal.
Cuanto más temprano en el día, mejor.

Puntualidad y presencia

No desperdicies el tiempo de los demás.
Si vas a llegar tarde, avisa cuanto antes.
Estate presente y enfócate en lo que se discute.

Si lo dices dos veces, escríbelo

Documenta todos los procesos. Ante la duda, escríbelo.

Gratitud

Enfócate en lo positivo.
Rendimos mejor cuando disfrutamos y nos sentimos bien.
Sé agradecido. Dile a la gente cuando hace algo bien.

Auditoría de energía

Analiza tu tiempo: qué actividades te dan energía y cuáles te la quitan.
- Delega o externaliza lo que te drena tanto como puedas.

Salud

Tu salud mental y física es tu recurso más importante.
- Cuídate y cuida a quienes te rodean.

Toma de decisiones

Exige que quien quiera discutir un tema lo escriba antes, junto con la solución propuesta.
Lleva tiempo, pero produce decisiones mucho más reflexivas.

Conseguir compromiso

La gente se compromete cuando siente que es parte de la decisión y su opinión importa.
A más influencia, más involucración.

Problemas y solución propuesta

Quien presente un problema en una reunión debe traerlo por escrito.
- Incluir descripción del problema y solución propuesta. Nada de “no sé”. Al menos una hipótesis.
Los problemas se presentan en la reunión semanal.
Da 5 minutos para discutir cada solución.
- Si hay consenso, perfecto.
- Si no, usa el framework RAPID en lugar de seguir debatiendo.

La voz más fuerte en la sala

Piensa quién está en la sala durante las discusiones grupales.
Evita influir en los demás: que escriban su voto o ideas antes de que tú compartas las tuyas.
Deja que los juniors pregunten y hablen primero.

Acuerdos descuidados

Acuerdos descuidados: la gente no llega a tiempo o no cumple lo que prometió.
El antídoto son los “acuerdos impecables”:
- Definidos con precisión
- Acordados por todas las personas relevantes
Tiene que haber consecuencias por romper acuerdos.
Si no puedes cumplir, avisa cuanto antes a los involucrados.

Transparencia

No ocultes información negativa.
La imaginación es más poderosa que la realidad.
Comparte toda la información relevante con tu equipo, buena y mala.
- Deja que se adapten.

Resolución de conflictos

Los conflictos interpersonales casi siempre ocurren porque la gente:
- No comparte del todo sus pensamientos y sentimientos
- No se siente escuchada
Demuestra que has escuchado resumiendo lo que dijeron hasta que respondan “exacto”.

Identificación de problemas

Pide a la gente que imaginen ser el CEO y respondan:
- “¿Cuáles son los 3 problemas más importantes a resolver en los próximos 90 días?”
Pide que escriban sus pensamientos sobre la empresa cuando sientan alegría, emoción, tristeza, ira o miedo.

Liderazgo consciente

Interésate más en aprender que en tener razón.

Obsesión por el cliente

Enfócate en el resultado, no en el output.
Resuelves un problema del cliente, no solo haces un producto.

Cultura

No eliges tus valores. Los tienes.
Úsalos como guía para contratar y despedir.
Celebra. Reconoce los logros públicamente.
No midas horas. Mide resultados.
Evita la política de oficina: nunca dejes que el lobbying funcione.

Wiki de empresa

Ten una wiki y haz obligatorio que los nuevos empleados la lean.
Si haces algo dos veces, documenta exactamente lo que hiciste.
- Todo el equipo debería contribuir.

Seguimiento de metas

Nunca asignes una acción sin que la persona la acepte verbal o por escrito.

Áreas de responsabilidad

Cuando varias personas comparten una responsabilidad, a menudo se hace mal o no se hace.
Asigna una persona a cada función en la empresa.

Sin punto único de fallo

Documenta todos los procesos.
Entrena a una segunda persona para cada rol.

KPIs

Conoce tus 5-6 KPIs más importantes y haz seguimiento constante. Que sean visibles para todo el equipo.

Colaboración

Define visión y metas para empresa, departamento e individuo.
Comunícalas a cada miembro del equipo.
Haz seguimiento semanal del progreso.
Da feedback sobre qué va bien y qué hay que ajustar.

OKRs

Apunta a 3 objetivos con 3 resultados clave cada uno.
Para empresa, departamento, equipo e individuo.
- Que estén alineados en cascada.
Objetivo = “¿a dónde queremos ir?”. No tiene que ser medible.
Resultados clave = “¿cómo sabemos que llegamos?”. Tienen que ser medibles.
Reúne a tu equipo de liderazgo con sus propuestas de OKRs para el trimestre.
- Deja que cada persona proponga los suyos. Se involucrarán más.

Feedback

Nunca des feedback negativo por canales unidireccionales (email, mensaje, buzón de voz).

El problema de no dar feedback

No verás los problemas de tu empresa.
La comunicación se romperá.
Tu mejor talento se irá.

Las 4 A’s para pedir feedback

Pídelo.
Reconócelo: repite lo que dijeron. Que se sientan escuchados.
Agradécelo.
Actúa.

Cómo dar feedback negativo

Pide permiso.
Describe el comportamiento (hecho).
Di cómo te hace sentir (sentimientos).
Comparte tus pensamientos y opiniones (historia).
Haz una petición: qué cambio te gustaría ver.
Pregunta si aceptan el feedback.

Recaudación de fondos

Elige un socio, no una empresa.
Para contactar a un inversor, pide a 3-5 personas de tu red que lo conozcan que envíen un email de recomendación.
Concentra las referencias en la misma semana para que te noten.
Habla de tu empresa cuando el inversor ya confíe en ti.
Véndete a ti mismo, no solo la empresa.

Reclutamiento

Dedica poco tiempo a candidatos que no vas a contratar y mucho a los que sí.
Como hiring manager, escribe un plan de 90 días para el puesto.

Onboarding

Dale al onboarding más atención que al reclutamiento.
Asigna a cada nuevo empleado un compañero con quien reunirse 15 minutos diarios las primeras 2 semanas.

Despido

Al anunciarlo, elogia las contribuciones de la persona y asume la responsabilidad de no haber podido encajar sus habilidades con las necesidades de la empresa.
No culpes ni critiques. Asume la responsabilidad de la situación.

Ventas efectivas

Construye confianza.
Vende resultados, no características.
Identifica los dolores de los clientes.

Construir confianza

Pregunta a los clientes sobre ellos mismos.
- Escucha activamente y refleja lo que dicen.
- En la segunda reunión, demuestra que recuerdas lo que dijeron en la primera.
Deja claro que no vas a hablar de tu empresa.
Pide poco tiempo.
Invítalos a un evento social sin agenda.

Desarrollo de clientes

Las preguntas correctas te ayudan a identificar los desafíos del cliente.
Entiende su dolor antes de presentar tu solución.
1. ¿Cuáles son sus metas?
2. ¿Qué les impide alcanzarlas?
3. ¿Cuáles serían sus soluciones ideales?

Vende resultados, no características

A la mayoría no le importan las características de tu producto. Les importan sus resultados de negocio.
Enfócate en el por qué.
Pinta la visión de un mundo donde el cliente logra lo que quiere gracias a tu producto.

Equipo de ventas y pipeline

No contrates vendedores de inmediato.
En general, los vendedores no venderán mejor que los fundadores. Y no podrán vender si tú no puedes.
Contrata un equipo de ventas solo si:
- Tienes una versión inicial de product-market fit (tus clientes de pago renuevan).
- Sabes qué vendes y a quién.

Estructura del equipo de ventas

Generar leads y cerrar son funciones distintas. Sepáralas.
Los vendedores senior son caros. Que se enfoquen en cerrar tratos.
Estructura ideal:
- Calificadores (SDRs): generan leads.
- Cerradores (Account Executives): cierran leads.
- Cultivadores (Customer Success): atienden clientes existentes.

Generación de leads

Leads predecibles es el primer paso hacia ingresos predecibles.

Marketing

Empieza por la fruta al alcance de la mano: el segmento de clientes cuyo problema tu producto resuelve 10x mejor que la competencia.
Pasa al siguiente segmento cuando tengas recursos para ello.

Product-market fit (PMF)

Diseña una solución claramente mejor que las existentes para el problema de tus clientes objetivo.
¿Cómo sabes si tienes PMF?
- Tus clientes te lo dicen: renuevan, compran más, te recomiendan.
B2B: PMF = contratos a largo plazo.
B2C: PMF = segunda compra, renovación, compartir en redes sociales.

Matt Mochary habla sobre su método de coaching, cómo entender y superar el miedo primigenio, el síndrome del impostor y más.

El Triángulo de Gestión de Proyectos

2022-07-25T00:00:00+00:00

Un triángulo de tiempo, calidad y coste. Es un indicador de que estos tres parámetros están interconectados. Puedes fijar uno o dos de ellos, pero no los tres.

La triple restricción

Barato y rápido: la calidad sufrirá.
Barato y bueno: llevará más tiempo.
Rápido y bueno: subirá el precio.

Waterfall vs Agile

En metodologías de software, puedes adaptar esta idea cambiando calidad por alcance:

Waterfall

En proyectos waterfall, el alcance está fijado, mientras que el tiempo y el dinero serán más variables. Dependiendo de si es más importante terminar a tiempo o dentro del presupuesto.

Agile

Por otro lado, en un entorno agile normalmente trabajamos en iteraciones de pocas semanas, así que esta es la parte fija: el tiempo, para entregar valor lo antes posible, y así obtener retroalimentación y recalibrar una y otra vez.

Los costes en un equipo de software también están fijados por las personas que pertenecen a él.

El tiempo está fijado, el coste está fijado, así que por la regla del triángulo de hierro, el alcance debe ser variable.

Un equipo agile no puede predecir el alcance de su trabajo en un proyecto de un año, sin embargo, no necesitan hacerlo. Su enfoque debería estar en entregar constantemente valor tanto como sea posible, o al menos al final de cada iteración, reflejando sus aprendizajes y recalibrando sus prioridades una y otra vez.

Como puedes ver, un dato curioso es que waterfall y agile comparten un triángulo invertido con sus parámetros fijos y variables. Realmente interesante.

Referencia

La Estrella de Mar y la Araña

2022-07-19T00:00:00+00:00

Si cortas la cabeza a una araña, muere. Si cortas una pata a una estrella de mar, le crece otra y esa pata puede convertirse en una estrella nueva. Las organizaciones jerárquicas tradicionales son como arañas. Las organizaciones descentralizadas son como estrellas de mar, y están cambiando los negocios y el mundo.

¿Qué hay detrás del éxito de Wikipedia, Craigslist y Skype? ¿Qué tienen en común eBay y General Electric con los movimientos abolicionistas y de derechos de la mujer? ¿Qué decisión puso a General Motors y Toyota en caminos tan diferentes?

Ori Brafman y Rod Beckstrom ofrecen respuestas sorprendentes, historias fascinantes y conexiones inesperadas. El libro explora qué pasa cuando las estrellas de mar se enfrentan a las arañas. Muestra cómo empresas e instituciones (IBM, Intuit, el gobierno de EE.UU.) están adoptando principios de estrella de mar para tener éxito.

Rod Beckstrom resume las ideas principales del libro en esta charla:

Artesanía Limpia

2022-07-11T00:00:00+00:00

El libro tiene tres partes: disciplinas, estándares y ética.

La primera es la más técnica. Te guía con ejemplos de TDD y muestra cómo el testing te ayuda a diseñar tu código.

La segunda trata sobre productividad, calidad y coraje.

La tercera explica cómo hemos llegado hasta aquí como profesionales del software y nuestra responsabilidad ética: no hacer daño, integridad y trabajo en equipo.

Una de mis partes favoritas del libro:

Nuestra industria es dinámica y cambia constantemente. Hay que aprender de forma continua y agresiva.

¿Cómo y cuándo aprendes? Si tu empresa te da tiempo para ello, aprovéchalo al máximo. Si no, tendrás que hacerlo por tu cuenta.

Prepárate para dedicar varias horas al mes. Reserva ese tiempo.

Sí, ya sé: familia, facturas, viajes, la vida. Pero también tienes una profesión. Y las profesiones requieren cuidado y mantenimiento. Aprendamos de forma continua y agresiva.

Capítulo 11. Coraje - Aprendizaje Agresivo Continuo

Índice

Parte I: Las Disciplinas

Capítulo 1. Artesanía

Extreme Programming
Test-Driven Development
Refactoring
Diseño Simple
Programación Colaborativa
Tests de Aceptación

Capítulo 2. Test-Driven Development

Visión General
Lo Básico

Capítulo 3. TDD Avanzado

Quedarse Atascado
Arrange, Act, Assert
Test Doubles
Arquitectura

Capítulo 4. Diseño de Tests

Testeando Bases de Datos
Testeando GUIs
Patrones de Test
Subclase Específica de Test
Humble Object
Diseño de Tests
Rompiendo la Correspondencia

Capítulo 5. Refactoring

¿Qué es Refactoring?
El Kit Básico de Herramientas
Extract Method
Las Disciplinas

Capítulo 6. Diseño Simple

YAGNI
Cubierto por Tests
Cobertura
¿Diseño?
Maximizar Expresión
La Abstracción Subyacente
Minimizar Duplicación
Minimizar Tamaño

Capítulo 7. Programación Colaborativa

Capítulo 8. Tests de Aceptación

La Disciplina
El Build Continuo

Parte II: Los Estándares

Capítulo 9. Productividad

Nunca Enviaremos M***da
Adaptabilidad Económica
Siempre Estaremos Listos
Productividad Estable

Capítulo 10. Calidad

Mejora Continua
Competencia Sin Miedo
Calidad Extrema
No Volcaremos en QA
QA No Encontrará Nada
Automatización de Tests
Testing Automatizado e Interfaces de Usuario
Testeando la Interfaz de Usuario

Capítulo 11. Coraje

Nos Cubrimos Mutuamente
Estimaciones Honestas
Debes Decir NO
Aprendizaje Agresivo Continuo
Mentoría

Parte III: La Ética

El Primer Programador
Setenta y Cinco Años
Nerds y Salvadores
Modelos a Seguir y Villanos
Gobernamos el Mundo
Catástrofes
El Juramento

Capítulo 12. Daño

Primero, No Hacer Daño
Mejor Trabajo
Prueba Repetible

Capítulo 13. Integridad

Ciclos Pequeños
Mejora Implacable
Mantener Alta Productividad

Capítulo 14. Trabajo en Equipo

Trabajar como Equipo
Estimar Honesta y Justamente
Respeto
Nunca Dejes de Aprender

Charla de Uncle Bob donde cubre la mayoría de los temas del libro.

Escucha sobre:
* Cita e Intro - [00:00:00]
* Trayectoria Profesional - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programador como Profesión - [00:15:31]
* Artesanía - [00:18:45]
* Disciplinas - [00:22:45]
* Disciplinas: Test-Driven Development - [00:28:49]
* Disciplinas: Refactoring - [00:34:31]
* Cobertura de Código - [00:39:02]
* Estándar: Nunca Enviar M***da - [00:42:35]
* Estándar: Siempre Estar Listo - [00:47:15]
* Ética: No Hacer Daño - [00:50:00]
* Ética: Estimar Honestamente - [00:53:56]
* 2 Sabiduría de Tech Lead - [00:57:50]

Ingeniería de Software Moderna

2022-06-29T00:00:00+00:00

El libro presenta el desarrollo de software como una práctica de ingeniería real. Para dominarlo hay que ser experto en aprender y gestionar la complejidad.

Optimizar para aprender

El libro presenta cinco comportamientos clave para aprender mejor:

Trabajar de forma iterativa
Buscar feedback
Incrementalismo
Empirismo
Ser experimental

La idea central: trabajar en pasos pequeños, recoger feedback y ajustar.

Optimizar para gestionar la complejidad

Cinco ideas para manejar la complejidad:

Modularidad
Cohesión
Separación de responsabilidades
Ocultación de información y abstracción
Gestión del acoplamiento

Gestionar la complejidad de nuestros sistemas es fundamental.

Herramientas para apoyar la ingeniería

El libro profundiza en ideas como:

Testeabilidad
Desplegabilidad
Control de variables
Entrega continua

Un vídeo donde el autor explica las ideas principales del libro:

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.

Bikeshedding

2022-05-27T00:00:00+00:00

El término se acuñó como metáfora de la Ley de trivialidad de Parkinson. La gente en las organizaciones suele dar demasiada importancia a los asuntos triviales.

Bikeshed-ing

El concepto apareció como corolario de la “Ley de Parkinson”, una parodia sobre gestión. “Bikeshedding” es una versión dramatizada de la “Ley de trivialidad”.

C. Northcote Parkinson observó que un comité que debe aprobar planes para una central nuclear puede pasar la mayor parte del tiempo en temas fáciles de entender pero poco importantes. Por ejemplo, qué materiales usar para el cobertizo de bicis del personal. Mientras tanto, descuidan el diseño de la central, que es mucho más importante pero más difícil de criticar. Como él dijo:

“El tiempo dedicado a cualquier tema será inversamente proporcional al dinero involucrado.”

La gente da demasiada importancia a lo trivial

Lo he visto en todas las empresas donde he trabajado. Cuando mezclas temas importantes con otros no tan importantes (o nada importantes), es muy común acabar discutiendo lo trivial con tus compañeros. Mientras tanto, las cosas importantes que darían valor real al cliente quedan aparcadas.

Pasa más de lo que pensamos, y le puede ocurrir a cualquiera.

¿Qué podemos hacer?

Crear conciencia de este problema en tu equipo. La comunicación honesta y la confianza son claves.

Pasos a seguir:

Sé consciente del problema.
Ve valor en cambiar este comportamiento.
Señala el problema cuando lo veas ocurrir.
Espera lo mismo de tus compañeros.

Referencias

Bitcoin: Blockchain y su investigación

2022-05-10T00:00:00+00:00

El libro se publicó en 2017, así que mucha de la tecnología ya es historia. Y eso es justo lo que más me gusta: la parte histórica y el origen de la blockchain.

¿Cómo se crea una dirección Bitcoin? ¿Cómo funcionan las claves privadas y públicas? ¿Qué son las wallets? El libro responde estas y otras preguntas.

En aquella época, algunos sitios web y servicios ya usaban Bitcoin como método de pago. Se veía venir una tendencia interesante.

La primera mitad del libro es la mejor parte. Sigue siendo relevante porque explica los orígenes de la tecnología.
La segunda mitad es más opcional, para curiosos. No hay grandes aprendizajes, más allá de ver qué tendencias había en 2016/2017. Hoy la tecnología (y los proyectos blockchain) ha evolucionado muchísimo.

Me encantaría leer una versión actualizada, cinco años después de la primera edición.

El libro está disponible solo en español: 0xWord

Docker: SecDevOps

2022-04-29T00:00:00+00:00

Un libro muy completo sobre Docker, desde lo básico hasta conceptos avanzados, con ejemplos fáciles de seguir.

Cubre buenas prácticas para construir imágenes Docker y mantener la seguridad al ejecutar contenedores. También explica el demonio Docker y toda la tecnología que hay detrás.

El libro está disponible solo en español: 0xWord

El Número de Dunbar

2022-04-02T00:00:00+00:00

Un límite cognitivo de cuántas relaciones sociales estables podemos mantener. Saber quién es cada persona y cómo se relaciona con las demás.

El estudio muestra que:

Relación cercana: 5 personas.
Confianza profunda: 15 personas.
Relaciones significativas: 50 personas.
Contactos activos: 150 personas.

¿Por qué este límite es 150?

Por nuestra capacidad cognitiva limitada. Nuestra capacidad para razonar, resolver problemas y entender ideas complejas tiene un tope. Al crecer el equipo, aumenta la carga cognitiva y la comunicación sufre. Por eso un equipo muy grande pierde sus beneficios.

Origen

En los 90, el antropólogo Robin Dunbar encontró una correlación entre el tamaño del cerebro de los primates y el tamaño de su grupo social. Extrapoló los resultados al cerebro humano y propuso que podemos mantener unas 150 relaciones estables. Dunbar teorizó que:

“Este límite depende directamente del tamaño del neocórtex, que a su vez limita el tamaño del grupo […] El límite impuesto por la capacidad de procesamiento neocortical es simplemente el número de personas con las que se puede mantener una relación estable.”

Este número incluye también colegas del pasado, como amigos del instituto, con los que querrías reencontrarte si os volvierais a ver.

¿Cómo se aplica esto a los equipos?

Equipos individuales: 5-9 personas.
- Confianza compartida entre los miembros.
- La confianza se construye con el tiempo.
- Deben ser equipos a largo plazo.
Grupo: 50 personas.
- Relaciones significativas.
- Comparten un dominio o subdominio.
- Entienden los retos y se ayudan mutuamente.
Division: 150 personas.

Referencias

Topologías de Equipos

2022-03-31T00:00:00+00:00

El libro explica cómo estructurar equipos dinámicos y sus interacciones para adaptarse rápido a nuevas condiciones y entregar software de forma ágil y segura.

Estructura de equipo

Alta cohesión: agrupa las cosas relacionadas.
Bajo acoplamiento: límites claros entre equipos.
Carga cognitiva: es como la RAM del equipo. Si lo sobrecargas, se quema.

Para evitar cuellos de botella, asegúrate de que la carga cognitiva del equipo no sea excesiva.

Ley de Conway

La estructura organizacional influye en la arquitectura del software.
Las organizaciones diseñan sistemas que copian su estructura de comunicación.
Resultado: nadie se enfoca en la arquitectura óptima para el proyecto.
Primero define la arquitectura, luego forma los equipos.

El equipo primero

Quién está en el equipo importa menos que su dinámica.
Al medir rendimiento, el equipo importa más que las personas individuales.
Equipo = grupo de 5-9 personas trabajando hacia metas compartidas.
- Ver el número de Dunbar.
Formar un equipo toma de 2 semanas a 3 meses.
La carga cognitiva es el esfuerzo mental total usado en la memoria de trabajo.
3 tipos de carga cognitiva:
- Intrínseca: fundamentos del problema. Ej: lenguaje de programación.
- Extrínseca: relacionada con el entorno. Ej: cómo desplegar.
- Germane: requiere atención especial. Ej: dominio de negocio.
Heurísticas:
- 3 tipos de dominio: simple, complicado, complejo.
- Si el dominio es muy grande, divídelo en subdominios.
- Un equipo puede manejar:
  - 2-3 dominios simples.
  - 1 dominio complejo.
  - Evita 2 dominios complicados; mejor divide el equipo.
Define una API de equipo:
- Código: endpoints, librerías, clientes…
- Versionado.
- Documentación.
- Prácticas y principios.
- Herramientas de comunicación.

Topologías de equipo

Organiza equipos por áreas de dominio de negocio, no por conocimiento técnico o actividades.

El éxito depende tanto de los miembros como del entorno, otros equipos e interacciones.
Divide responsabilidades para romper silos.
Tipos de dependencias: conocimiento, tarea y recurso.
Cuatro tipos de equipos:
- Stream-aligned: entregar funcionalidades y productos al mercado cuanto antes.
- Enabling: desarrollar capacidades para los equipos stream-aligned.
- Complicated-subsystem: reducir la carga cognitiva de los equipos stream-aligned.
- Platform: dar autonomía a los equipos stream-aligned.

Interacciones de equipo

Colaboración: trabajo cercano entre equipos con distintas habilidades.
X-as-a-Service: propiedad clara, baja carga cognitiva.
Facilitación: eliminar impedimentos y mejorar la calidad de las interacciones entre equipos.

La Psicología del Dinero

2022-02-27T00:00:00+00:00

Tener más dinero te hará más feliz SOLO si significa tener más control sobre tu tiempo.

“No tenía la intención de hacerme rico. Solo quería ser independiente.” Charlie Munger.

Malentendidos sobre el dinero

Interés compuesto

Empieza a invertir con lo que puedas y mantente invertido.
Aprovecha el poder del interés compuesto.

Volatilidad

No hay altos rendimientos sin volatilidad.
Es el precio emocional que pagas por buenos rendimientos anuales.
Acepta la volatilidad. Es una tarifa, no una multa.

Inversiones de cola

Predecir “lo próximo grande” es difícil, así que diversifica.
Una inversión de cola es esa única inversión que supera a todas las demás y compensa varias malas decisiones.
Diversifica para aumentar tus chances de pillar alguna inversión de cola.

Citas

“No tiene sentido arriesgar lo que tienes y necesitas por lo que no tienes ni necesitas.”

“Las colas largas (los extremos más alejados de una distribución) tienen enorme influencia en las finanzas. Un puñado de eventos puede representar la mayoría de los resultados.”

“Poder hacer lo que quieras, cuando quieras, con quien quieras, el tiempo que quieras, no tiene precio. Es el mejor dividendo que paga el dinero.”

“Como todo lo que vale la pena, invertir bien tiene un precio. Pero no se paga en euros, sino en volatilidad, miedo, duda, incertidumbre y arrepentimiento. Todo eso es fácil de ignorar hasta que lo vives en tiempo real.”

“Pocas cosas importan más con el dinero que entender tu horizonte temporal y no dejarte influir por gente que juega un juego diferente al tuyo.”

Video Resumen

Actualiza tu Equipo para Ser Más Extreme

2022-02-26T00:00:00+00:00

Nuestra profesión del software está en constante evolución y exige aprendizaje continuo. El cambio no es opcional en nuestra industria.

Hay que crear espacios para salir de nuestra zona de confort. Nuestro cerebro necesita entrenarse para adaptarse a un entorno que cambia constantemente.

¿Por qué katas de código, charlas técnicas o viernes de investigación?

El objetivo es crear un ambiente que fomente la mejora continua. Buscar aprender en todas partes, todo el tiempo, como actitud central para cada persona y para el equipo.

Crear oportunidades de aprendizaje

Programa tiempo cada X semanas para practicar juntos.

Al final de cada iteración, o cada 2-4 semanas, trabajamos en katas en parejas o mob durante 2 horas. Ese espacio también sirve para preparar charlas técnicas internas y compartir conocimiento interesante que no sea del “negocio diario”.

El objetivo es salir de nuestra zona de confort. Mejorar nuestra capacidad de adaptación mientras aprendemos otros temas.

¿Qué es una kata de código?

Los desarrolladores no practicamos lo suficiente. La mayor parte del aprendizaje ocurre en el trabajo, y ahí es donde cometemos la mayoría de errores.

El término “kata” viene del karate: movimientos repetitivos que mejoran tus habilidades de combate.

Las katas de código dan a los desarrolladores los mismos beneficios que practicar en cualquier profesión. Son ejercicios simples que permiten experimentar y aprender sin la presión de producción.

No hay respuestas correctas o incorrectas en una kata: el beneficio viene del proceso, no del resultado.

Motivación

Practicar técnicas de refactoring.
Practicar TDD.
Aplicar principios SOLID.
Hacer sesiones de live coding.
Ejercitar el concepto driver-navigator.
Mejorar la cohesión del equipo.
Pasarlo bien mientras aprendes con otros.

Si te interesa mi visión sobre TDD y katas, escribí un post hace poco: Test-Driven Development.

¿Qué es una charla técnica?

Las charlas técnicas nos permiten compartir conocimiento de nuestra industria con el equipo.

Puede ser sobre FrontEnd, BackEnd, DevOps. Pero también animo a compartir:

un nuevo lenguaje que estás aprendiendo,
un resumen de un libro que terminaste,
una tecnología que te da curiosidad,
un software que te gustaría presentar,
una herramienta que mejora tu productividad,
en realidad: cualquier cosa que aporte valor o conocimiento.

¿Cómo presento una charla técnica?

Escribí un artículo con consejos sobre cómo mejorar tu charla técnica. Algunas preguntas que pueden ayudarte:

¿Qué has aprendido recientemente?
¿Qué conocimiento sería interesante compartir con tus compañeros?
¿Qué aspecto de ti te gustaría mejorar profesional o personalmente?

Una sola regla: sé curioso y “abraza el cambio.”

Viernes de investigación y aprendizaje

Reserva el último viernes del mes para investigar y aprender. Todo el equipo tendrá un espacio dedicado al crecimiento y la experimentación.

Es clave construir confianza con tu equipo. Que todos sepan que cada uno usará este tiempo bien. No microgestiones forzando un registro detallado en una wiki.

Eso sí, estaría bien que el equipo comparta lo que hace. Crea transparencia. Un anuncio verbal el día antes con las intenciones, y el día después con los aprendizajes clave.

Resumen

Puedes ayudar a tu equipo a ser más extreme creando un espacio dedicado al crecimiento y la experimentación.

Da flexibilidad para experimentar con estas ideas.
Es una oportunidad para crecer y aprender a la vez.
La responsabilidad es de cada persona y del equipo.

No microgestiones este tiempo. Enfócate en el resultado. Ayuda a tu equipo a crecer, y disfrutarán creciendo contigo.

Charla Técnica

Tras escribir este post (originalmente en febrero de 2022), me invitaron a dar una charla técnica sobre este tema en varias conferencias.

El Poder de la Autoridad y la Obediencia

2022-01-24T00:00:00+00:00

Milgram quiso investigar hasta dónde llegaría la gente obedeciendo una orden que implicara dañar a otra persona. Y qué tan fácil era influenciarles para cometer atrocidades, como ocurrió con los alemanes en la Segunda Guerra Mundial.

El experimento

En los años 60, el psicólogo Stanley Milgram hizo una serie de experimentos sobre obediencia. Quería entender el poder de la autoridad, incluso cuando las órdenes podían tener consecuencias fatales.

Milgram estudió las justificaciones de los acusados en los juicios de Nuremberg. Su defensa era simple: solo seguían órdenes de sus superiores. El experimento buscaba responder esta pregunta:

¿Podría ser que Eichmann y sus millones de cómplices en el Holocausto solo estaban siguiendo órdenes? ¿Podríamos llamarlos a todos cómplices?

El procedimiento

Reclutaron a 40 hombres mediante anuncios en periódicos para un “estudio sobre aprendizaje” en Yale. A cada uno le pagaron $4.50.

Cada participante fue emparejado con otra persona. Un sorteo (amañado) decidía quién era el “aprendiz” y quién el “maestro”. El participante real siempre era el maestro. El aprendiz era un cómplice de Milgram fingiendo ser participante.

Al aprendiz lo llevaron a una habitación y le conectaron electrodos. El maestro y el investigador fueron a otra habitación con un generador de descargas. Los interruptores iban desde 15 voltios (descarga leve) hasta 450 voltios (XXX).

El aprendiz daba respuestas incorrectas a propósito. Por cada error, el maestro debía darle una descarga. Cuando el maestro se negaba, el investigador le presionaba con estas órdenes:

“Por favor, continúe.”
“El experimento requiere que continúe.”
“Es absolutamente esencial que continúe.”
“No tiene otra opción; debe continuar.”

Resultados

El 65% de los maestros llegó hasta el nivel máximo de 450 voltios. Todos llegaron al menos a 300 voltios.

Milgram hizo 18 variaciones del experimento. Alteraba la situación para ver cómo afectaba la obediencia.

Conclusión

La explicación fácil sería que había algo mal en esas personas. Pero la explicación real es que la situación les hizo comportarse así.

Varios factores influyeron: la ubicación, el comportamiento del investigador, y el hecho de haberse ofrecido voluntarios y recibir pago.

La gente tiende a obedecer si reconoce la autoridad del otro. Esta respuesta se aprende en la familia, la escuela y el trabajo.

La teoría de agencia de Milgram

Milgram explicó que las personas tienen dos estados de comportamiento en situaciones sociales:

Estado autónomo: diriges tus acciones y asumes responsabilidad por los resultados.
Estado agentivo: dejas que otros dirijan tus acciones y transfieres la responsabilidad a quien da las órdenes. Actúas como agente de la voluntad de otro.

Para entrar en estado agentivo hacen falta dos cosas:

Percibir que quien da las órdenes tiene autoridad legítima.
Creer que la autoridad aceptará la responsabilidad de lo que pase.

Cuando a los participantes se les recordaba que eran responsables de sus acciones, casi ninguno obedecía. En cambio, muchos que se negaban a continuar lo hacían si el investigador decía que él asumía la responsabilidad.

Variaciones del experimento

Algunas de las variaciones más interesantes:

Uniforme

Cuando una “persona común sin uniforme” asumía el rol de investigador, la obediencia bajó al 20%.

Cambio de ubicación

La obediencia bajó al 47.5% cuando el experimento se hizo en unas oficinas normales en vez de la prestigiosa Universidad de Yale.

Otros dos participantes (cómplices) eran también maestros pero se negaron a obedecer: uno a 150 voltios, el otro a 210. Ver a otros desobedecer a la autoridad redujo la obediencia al 10%.

Experimentador ausente

Cuando el investigador daba instrucciones por teléfono desde otra habitación, la obediencia bajó al 20.5%. Muchos participantes hicieron trampa: omitían descargas o daban menos voltaje. La proximidad de la autoridad afecta la obediencia.

Las cuestiones morales

¿Por qué tantos participantes hicieron algo aparentemente sádico al recibir órdenes de una autoridad? Según Milgram, varios factores situacionales lo explican:

La presencia física de una autoridad aumentó el cumplimiento.
Yale es una institución de confianza, así que el experimento parecía seguro.
La selección de maestro y aprendiz parecía aleatoria.
Los participantes asumían que el investigador era un experto.
Les dijeron que las descargas eran dolorosas, no peligrosas.

El experimento de Milgram se convirtió en un clásico de la psicología. Demostró los peligros de la obediencia. La situación influye más que la personalidad a la hora de obedecer.

A menudo no es tanto el tipo de persona que uno es, sino la situación en la que se encuentra, lo que determina cómo actuará.

Stanley Milgram, 1974.

Recursos

Modern CTO

2022-01-23T00:00:00+00:00

Los desarrolladores no son CTOs, pero pueden aprender a serlo.

Joel Beasley ofrece una guía práctica para pasar de desarrollador a CTO. Comparte desde su experiencia los retos, las lecciones aprendidas y los errores típicos en este camino.

Estos son los temas que encontrarás en el libro:

Un CTO moderno sabe…

Los desarrolladores no son CTOs
La epidemia del código espagueti MVP
La sobre-ingeniería es un problema
Si contratar, comprar o superar a la competencia
Cómo no escalar prematuramente
Cómo resolver cualquier problema
Cómo trabajar con programadores cuando no eres uno
Errores de UX a tener en cuenta
Cuándo hablar
Cuándo contratar y despedir consultores
Cómo analizar el fracaso
Cómo recuperarse de restricciones imprevistas
Responder la pregunta: “¿Qué tan difícil es codificar…?”
Cómo evitar al “tipo del noveno inning”
Cuándo responder a la retroalimentación
Cómo validar a un experto en cualquier campo
Cómo comunicar efectivamente ideas complejas

Citas favoritas

Si me apoyo en logros pasados, nunca creceré.

APROVECHA LA EXPERIENCIA DE OTROS. Los libros condensan toda una vida de experiencia en unas pocas horas de lectura.

Solo hay dos razones por las que escribes mal código:

Sabes cómo escribir buen código, pero eliges escribir mal código.

No sabes cómo escribir buen código. Y ambas apestan.

Como CTO, debes tener un enfoque de negocio.

Siempre vuelve a tus metas principales. […] Me aseguro de que cada meta tenga un “por qué” claro detrás. Así, cuando me pierdo, vuelvo a mi “por qué”.

– Referencia a “Empieza con el Por Qué” de Simon Sinek.

Cuando eres el jefe, recuerda esta regla de oro: Pregunta a la gente qué piensa en lugar de decirles qué hacer.

Si no puedo evaluar el componente humano, no puedo liderar un equipo. […] La composición del equipo pesa tanto o más que la experiencia técnica.

Como CTO, si no puedes explicar el valor de forma simple, significa que no entiendes el valor de negocio detrás de tu tecnología.

Los líderes comen al final

2022-01-16T00:00:00+00:00

La mayor fortaleza de una empresa no está en sus productos o servicios. Está en su gente y su capacidad de cooperar y unirse, sobre todo en las crisis.

Pero la lealtad y el compromiso hay que ganárselos. Hoy el trabajo es una relación contractual y transaccional en muchas organizaciones. La competencia intensa y los despidos son la norma. Casi nadie cree en la lealtad a una empresa, mucho menos en el empleo de por vida.

Los 4 químicos (E.D.S.O.)

Somos individuos y parte de grupos sociales a la vez. Cada día tomamos decisiones que requieren sopesar nuestros intereses personales contra los del grupo. Este dilema también ocurre en nuestro cuerpo a través de 4 químicos clave:

Las endorfinas y la dopamina nos impulsan a satisfacer necesidades personales: encontrar comida, desarrollar soluciones, perseverar ante problemas. Nos ayudan a hacer cosas para sobrevivir.
La serotonina y la oxitocina nos animan a trabajar con otros. Construyen confianza, lealtad y camaradería. Fortalecen nuestros lazos sociales y aumentan nuestra inclinación a cooperar para lograr lo que no podemos solos.

Círculos de seguridad

La familia tradicionalmente proporciona un Círculo de Seguridad donde nos sentimos seguros y apoyados. Dentro del círculo tenemos un equilibrio saludable de E.D.S.O. y niveles bajos de cortisol. En las organizaciones, los Círculos de Seguridad dan a la gente un sentido de pertenencia y seguridad. Facilitan la comunicación, cooperación, resolución de problemas e innovación. La gente puede dirigir su atención a amenazas y oportunidades externas. Cuando se sienten amenazados por políticas y luchas internas, miran hacia adentro para protegerse. El grupo se vuelve más vulnerable.

Los líderes deben ganarse el respeto y la lealtad haciendo los mayores sacrificios y estando dispuestos a comer al final. Hay que dar confianza para ganar confianza.

Una sociedad desequilibrada

Los 4 químicos E.D.S.O. juegan roles importantes en nuestra supervivencia. Cuando están en equilibrio, las personas prosperan como están diseñadas para hacerlo. Sus grupos y organizaciones también prosperan. El problema es que el lugar de trabajo moderno está inundado de cortisol y adicción a la dopamina. No tenemos Círculos de Seguridad y estamos peligrosamente desequilibrados. ¿Cómo llegamos aquí?

Abstracción y deshumanización: gestionar con números, sistemas globales e interacciones virtuales puede ser peligroso y llevar a actos descuidados.
Abundancia destructiva: respondemos diferente a la escasez y al exceso. Los líderes se han cegado tanto por el interés comercial que olvidaron a quién deben servir.
Cambios sociales: nuestras normas y valores han cambiado con los Boomers post-WWII, la Generación X y los Millennials. Cada vez más adictos a la dopamina y desequilibrados.

Simon Sinek ofrece muchos ejemplos e historias de líderes en todos los ámbitos: militar, política y negocios.

TED Talk: Por qué los líderes comen al último

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

Las cinco disfunciones de un equipo

2021-12-07T00:00:00+00:00

Una fábula de liderazgo sobre una empresa tech que no consigue crecer. El equipo directivo no trabaja como equipo, les cuesta llegar a acuerdos y la moral está por los suelos. Hasta que llega la nueva CEO, Kathryn Petersen, que identifica los problemas y ayuda al equipo a superarlos.

Es el primer libro que leo de Patrick Lencioni, escritor estadounidense especializado en gestión empresarial. Es fundador y presidente de The Table Group, una consultoría enfocada en salud organizacional.

Resumen del libro

Kathryn Petersen, CEO de Decision Tech, enfrenta la crisis de liderazgo definitiva: unir a un equipo tan disfuncional que amenaza con hundir la empresa. ¿Lo logrará? ¿La despedirán? ¿Fracasará la empresa?

A lo largo de la historia, Lencioni revela las cinco disfunciones que explican por qué incluso los mejores equipos tienen problemas. Presenta un modelo claro y pasos concretos para superar estos obstáculos y construir un equipo cohesivo.

El modelo de las 5 disfunciones

1) Ausencia de confianza

El miedo a ser vulnerable impide que el equipo construya confianza.

Pasa cuando nadie quiere mostrarse vulnerable ni admitir errores, debilidades o que necesita ayuda. Sin ese nivel de comodidad, no hay base de confianza posible.

2) Miedo al conflicto

El deseo de mantener una armonía artificial ahoga el debate productivo.

Los equipos sin confianza no pueden tener debates apasionados sobre temas importantes. El conflicto se convierte en comentarios velados y murmullos. Cuando la gente no expresa sus opiniones abiertamente, las decisiones son peores.

3) Falta de compromiso

Sin claridad ni aceptación, el equipo no toma decisiones firmes.

Sin debate real, cuesta comprometerse con las decisiones. La ambigüedad domina. La falta de dirección y compromiso hace que los empleados, sobre todo los mejores, se sientan descontentos.

4) Evasión de responsabilidad

Nadie quiere la incomodidad de exigir cuentas a los demás.

Cuando no hay compromiso claro con un plan, incluso los más motivados dudan en señalar comportamientos contraproducentes de sus compañeros.

5) Desatención a los resultados

Las metas individuales y el estatus personal erosionan el enfoque en el éxito colectivo.

Cuando no hay rendición de cuentas, la gente pone sus necesidades (ego, carrera, reconocimiento) por encima de las metas del equipo. Si el equipo pierde de vista los logros, el negocio sufre.

Video Resumen

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

London vs Chicago

2021-11-20T00:00:00+00:00

Hay dos escuelas conocidas en TDD: la escuela mockista (también conocida como Outside-in) y la escuela clasicista (también conocida como Inside-out).

¿Por qué London y Chicago?

Dos empresas, una de Londres y otra de Chicago, afirmaban hacer TDD pero con enfoques diferentes. La de Londres construía software de afuera hacia adentro; la de Chicago, de adentro hacia afuera. Veamos cada una.

Outside-in: Escuela de Londres

Un enfoque guiado por comportamiento para TDD. Empiezas desde el exterior de la aplicación y vas hacia adentro, bajando a capas inferiores. Por ejemplo, desde la API/Controladores hacia las capas de aplicación o dominio.

PROS

Enfocado en Comportamiento: requiere muchos dobles de test porque testeas abstracciones que aún no existen (creas lógica de alto nivel primero). No escribirás código muerto, pero es fácil crear tests muy acoplados a la lógica, lo que dificulta el refactoring.
Separación Comando-Consulta: es una disciplina para gestionar efectos secundarios. O realizas una acción (comando) o pides un valor (consulta).

CONTRAS

Tests Frágiles: tiende a crear tests que se rompen fácilmente porque suelen estar muy acoplados al código de producción.
Refactoring Difícil: por la misma razón, tener tests acoplados hace que el refactoring continuo sea lento y complicado.

Inside-out: Escuela de Chicago

Un enfoque informal, exploratorio, basado en estado. Empiezas desde el interior de la aplicación (normalmente el dominio) y vas hacia afuera, hacia las APIs.

PROS

Red de Seguridad Fuerte: produce tests desacoplados de la implementación. Puedes cambiar el software sin miedo a romperlo, ideal para el refactoring continuo.
Alta Cohesión: a medida que los tests se vuelven más generales, el código de producción se vuelve más específico. Alta cohesión lleva a bajo acoplamiento, lo que mejora extensibilidad, mantenibilidad y testeabilidad.
Minimiza Dobles de Test: construir de adentro hacia afuera requiere menos dobles porque construyes sobre tests previamente escritos. Esto ayuda a tener tests menos frágiles.

CONTRAS

YAGNI: a menudo sobre-diseña soluciones, con código que realmente no se necesita (¡o ni siquiera se usa!) al final.

Conclusión

No se trata de elegir uno u otro. Se trata de entender tu contexto y optimizar las cualidades que lo necesitan. London y Chicago tienen sus pros y contras. El mejor enfoque para TDD es integrar ambas escuelas.

Referencias

Leadership is Language

2021-10-22T00:00:00+00:00

Un manual radical para empoderar a tu gente y poner a tu equipo en un camino de mejora continua.

El ex comandante de submarino L. David Marquet analiza el hundimiento del El Faro, uno de los desastres marinos más investigados. De ahí extrae ideas clave sobre liderazgo y lenguaje.

Quizás piensas que un líder efectivo toma decisiones rápidas, da discursos inspiradores y emite órdenes claras para que su equipo ejecute el plan. Ese modelo de liderazgo está obsoleto.

Tus palabras importan más de lo que crees.

David presenta seis jugadas que todo líder debería usar para mejorar cómo opera su equipo. El problema de muchos líderes hoy es que siguen usando el manual de la era industrial. Antes el líder daba órdenes, los empleados las seguían, y ya. Esa forma de liderar ya no funciona.

Las seis jugadas

Controla el reloj, no lo obedezcas. Planifica puntos de decisión y da a tu gente las herramientas para pausar si ven algo mal.
Colabora, no coacciones. Como líder, sé el último en dar tu opinión.
Comprométete, no solo cumplas. En vez de esperar que sigan instrucciones específicas, explica las metas generales y consigue su compromiso para lograrlas paso a paso.
Completa, no continúes. Si cada día se siente igual que el anterior, algo estás haciendo mal.
Mejora, no demuestres. Pide a tu gente que mejore los planes y procesos, no que demuestren que pueden cumplir metas fijas.
Conecta, no conformes. Aplana las jerarquías y conecta con tu gente para que contribuyan a las decisiones.

Video Resumen

Red Work vs Blue Work

2021-10-21T00:00:00+00:00

“Blue Work” y “Red Work” son conceptos que David Marquet describe en su libro Leadership is Language. Ambos requieren mentalidades diferentes y tienen lenguajes distintos.

“Hacer” en nuestro estilo de liderazgo tradicional no nos llevará a donde necesitamos estar en el futuro.

¿Qué es “Red Work”?

Red Work trata de hacer y reducir la variabilidad. Se enfoca en demostrar y en el rendimiento.

En Red Work, buscas completar una tarea sin tener que decidir mucho sobre el qué o el cómo. Es estar en control y tomar el control:

Procesar trabajo y evitar errores.
Tener previsibilidad y controlabilidad.

Hace falta un mecanismo para parar el Red Work y preguntar: ¿estamos haciendo lo correcto?

¿Qué es “Blue Work”?

Blue Work trata de decidir, pensar, planificar. Se enfoca en mejorar con una mentalidad humilde.

El lugar correcto para hacer Blue Work es al principio y al final de un punto de decisión.

Blue Work es crucial para empezar bien. Nos permite decidir la mejor manera de hacer algo con la información que tenemos ahora mismo.

Conviene establecer iteraciones cortas entre las diferentes actividades que queremos completar. Así tenemos “tiempo de Blue Work” para reflexionar. Es perfecto para hacer retrospectivas y ver qué podemos mejorar.

Es el momento de parar, “controlar el reloj”, colaborar y comprometerse para la siguiente iteración. Blue Work también incluye:

Trabajo de pensamiento.
Toma de decisiones.
Buscar alcanzar la excelencia.
Lograr que más personas piensen de forma independiente.
Abrazar la variabilidad y buscar diferentes aportes.

Blue Work aislado es inútil. Su función es hacer mejor el Red Work. Blue Work interminable, planificar sin resultados, no trae beneficios reales.

En nuestra industria del software no hay lugar para la vieja escuela de “Red-Workers” y “Blue-Workers”. Hay “Red Work” y “Blue Work”, y todos debemos participar en ambos.

Por eso todos debemos ser conscientes de estos tipos de trabajo y encontrar un buen equilibrio. Los buenos líderes involucran a todos en Red Work y Blue Work.

Referencias

TDD vs BDD

2021-09-25T00:00:00+00:00

Estas son dos técnicas diferentes. La clave de cada una está en la mentalidad y el contexto de lo que quieres lograr.

BDD es una “funcionalidad guiada por tests”

Básicamente, es un desarrollo test-first, donde el enfoque principal es asegurar el comportamiento final esperado, y por lo tanto el resultado de la lógica de software que quieres tener al final.

En BDD el enfoque principal es el comportamiento de tu lógica de dominio que aún no existe. Es, desde un punto de vista abstracto, sobre toda la funcionalidad y los requisitos del dominio.

TDD es sobre el ritmo

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

TDD no es solo la ya conocida mentalidad “red-green-refactor”, sino principalmente sobre el flujo de trabajo que te ayuda a entender las constantes decisiones de diseño que haces cada vez para cada lógica que estás diseñando.

TDD es sobre retroalimentación constante de tus decisiones.

En el contexto de OOP (para hacer los ejemplos más claros), siempre hay toneladas de formas diferentes de diseñar tu clase:

¿Cuál es el nombre de la clase de este método?
¿Cuáles son las dependencias o colaboradores de esta clase?
¿Cómo se comportará esta clase cuando use esta otra clase dentro de ella?
¿Cuál es el resultado esperado de este método cuando le doy estos argumentos?
etc, etc…

Hacemos estas preguntas (y muchas más) cada vez, y también les damos una respuesta, pero normalmente sin ningún pensamiento racional o reflexión sobre ello. Simplemente hacemos lo que creemos que es “lo mejor” en ese momento particular enfocándonos en hacer que algo funcione, pero ¿es suficiente hacerlo funcionar?

El bucle de retroalimentación constante

El testing no es solo una gran herramienta porque te da una red de seguridad para refactorizar con confianza, sino también porque ayuda a diseñar mejor el sistema. ¿Cómo es eso? Porque antes de implementar cualquier solución, te obliga a pensar en las decisiones que necesitas tomar. Te desafías a ti mismo para entender los argumentos de tus decisiones, y por qué A y no B es mejor solución en un contexto particular.

BDD y TDD no son mutuamente excluyentes, de hecho, pueden y deben coexistir. Depende principalmente del contexto de lo que quieres construir y testear.

BDD es sobre desarrollo de funcionalidades Test-First. El objetivo no es el cómo sino el qué. El bucle de retroalimentación es largo porque obtendrás el “verde” una vez que la funcionalidad esté implementada y funcionando como se esperaba.

TDD también es otro desarrollo guiado por Test-First pero, a diferencia de BDD, se trata de un bucle de retroalimentación más corto y rápido.

Primero, especificas lo que quieres. Piensas sobre el diseño de tu clase o método. Su nombre o firma. Sus dependencias. Pero todo esto con pequeños pasos, uno a la vez.
Segundo, haces que esa pequeña cosa funcione de la manera más simple posible.
Finalmente, lo haces mejor. Porque el software es lo suficientemente difícil y complicado como para hacerlo bien al primer intento, así que el refactoring es imprescindible para mantener un sistema saludable. En este punto, con un “test verde ejecutándose”, puedes refactorizar y mejorar tu lógica de forma segura.

Lo anterior es básicamente TDD, cierto, pero… ¿qué tiene de especial? El bucle de retroalimentación constante y las decisiones de diseño que necesitas tomar antes de escribir realmente la solución. Este es el poder de TDD.

¿Por qué pasos tan pequeños en TDD?

Teóricamente “debes” escribir pequeños pasos para cada iteración, pero ¿por qué? Se trata del bucle de retroalimentación. Esto depende de ti, tus expectativas y tu experiencia con testing.

Recursos

El patrón Bitcoin

2021-09-20T00:00:00+00:00

El libro analiza el contexto histórico de Bitcoin, las propiedades económicas que lo hicieron crecer tan rápido, y sus posibles implicaciones económicas, políticas y sociales.

Bitcoin es un invento de la era digital, pero el problema que resuelve es tan antiguo como la humanidad: transferir valor a través del tiempo y el espacio. Ammous nos lleva por la historia de las tecnologías que han funcionado como dinero. Desde piedras y conchas, pasando por metales y monedas, hasta el patrón oro y la deuda gubernamental moderna.

Con ese contexto, el libro explica cómo funciona Bitcoin de forma clara e intuitiva. Es un software descentralizado y distribuido que convierte electricidad y poder de procesamiento en registros precisos e indiscutibles. Permite usar Internet para las funciones tradicionales del dinero sin depender de ninguna autoridad o infraestructura física.

El capítulo final responde las preguntas más comunes sobre Bitcoin:

¿La minería de Bitcoin desperdicia energía?
¿Bitcoin es para criminales?
¿Quién controla Bitcoin y pueden cambiarlo?
¿Cómo se puede matar a Bitcoin?

El patrón Bitcoin es el recurso esencial para entender esta alternativa descentralizada, apolítica y de libre mercado frente a los bancos centrales.

Video Resumen

Extra: Podcast de Lex Fridman con el autor de este libro

Turn the Ship Around!

2021-09-12T00:00:00+00:00

Marquet comparte sus teorías de liderazgo y cómo implementó un modelo diferente. Explica las limitaciones de la jerarquía tradicional, por qué falló antes al intentar empoderar a su equipo, y cómo el submarino Santa Fe fue el lugar perfecto para probar el enfoque líder-líder.

Casi todos dividimos el mundo en líderes vs seguidores sin darnos cuenta. Asumimos qué puede o no puede hacer cada grupo. Esas suposiciones afectan cómo pensamos y actuamos, impactando el rendimiento de cada persona y de la organización.

Es muy común: un empleado entusiasta propone una idea nueva y le dicen “eso no es tu trabajo” o “eso no va a funcionar”. La gente se frustra y al final deja de intentarlo o se va. Los jefes también se frustran cuando su equipo prefiere hacer lo mínimo en vez de innovar o asumir responsabilidad.

El modelo líder-líder parte de que todos tienen capacidad y potencial para liderar. Aprovecha ese potencial en todos los niveles, reduce la dependencia de un solo líder y logra un rendimiento sostenido.

Los 3 componentes clave: Control, Competencia y Claridad

Control

El control es la libertad y autoridad para decidir el por qué, el qué y el cómo de tu trabajo. La meta es delegar las decisiones lo más abajo posible en la organización.

Encuentra el código genético del control y reescríbelo.
Actúa para llegar a un nuevo pensamiento.
Las conversaciones cortas y tempranas hacen el trabajo más eficiente.
Usa “Tengo la intención de…” para convertir seguidores pasivos en líderes activos.
Resiste el impulso de dar soluciones.
Elimina los sistemas de monitoreo de arriba hacia abajo.
Piensa en voz alta (tanto jefes como subordinados).

Competencia

Cada persona debe ser técnicamente competente para tomar buenas decisiones en su nivel. Si das más responsabilidad sin el conocimiento y recursos necesarios, todo se desmorona.

Toma acciones deliberadas.
Aprendemos en todas partes, todo el tiempo.
No informes, certifica.
Repite el mensaje de forma continua y consistente.
Especifica metas, no métodos.

Claridad

Para tomar buenas decisiones en cualquier nivel, hay que estar alineado con el propósito de la organización. Hay que entender bien los objetivos y los criterios para decidir.

Busca la excelencia, no solo evitar errores.
Construye confianza y cuida a tu gente.
Usa tu legado como inspiración.
Usa principios guía para los criterios de decisión.
Usa el reconocimiento inmediato para reforzar los comportamientos deseados.
Empieza con el fin en mente.
Fomenta cuestionar las cosas en vez de obedecer ciegamente.

Citas favoritas

El liderazgo es comunicar a las personas su valor y potencial tan claramente que se inspiran a verlo en sí mismas.

Resumen

David Marquet habla sobre el liderazgo que cambia el rumbo en su keynote en el Worldwebforum.

El guardián entre el centeno

2021-08-08T00:00:00+00:00

Aunque fue escrita para adultos, los adolescentes la adoptaron por sus temas de angustia, alienación y crítica a lo superficial.

Salinger refleja su propia juventud, su relación complicada con crecer y el trauma de haber vivido la Segunda Guerra Mundial.

Es una novela claramente autobiográfica. Salinger usó sus experiencias en la guerra y su Nueva York natal para crear a Holden Caulfield.

El protagonista se convirtió en icono de la rebeldía adolescente. La novela toca temas como la inocencia, la identidad, la pertenencia, la pérdida, el sexo y la depresión.

Del capítulo 22:

— “No te gusta nada de lo que está pasando.” Me deprimió aún más cuando dijo eso.

— “Sí me gusta. Sí me gusta. Claro que sí. No digas eso. ¿Por qué diablos dices eso?”

— “Porque no te gusta. No te gusta ninguna escuela. No te gustan un millón de cosas. No te gustan.”

— “¡Sí me gustan! Ahí es donde te equivocas—¡es exactamente donde te equivocas! ¿Por qué diablos tienes que decir eso?” dije. Cielos, me estaba deprimiendo.

— “Porque no te gustan,” dijo ella. “Nombra una cosa.”

— “¿Una cosa? ¿Una cosa que me guste?” dije. “Vale.”

El problema era que no podía concentrarme muy bien. A veces es difícil concentrarse.

Resumen

Test-Driven (Development)

2021-08-01T00:00:00+00:00

La complejidad aquí no está en escribir tests en sí, sino en los hábitos que tenemos que cambiar para crear software que sea fácil de testear.

La raíz del problema

Sin experiencia sólida en testing, los desarrolladores lo pasan mal al intentar aplicar tests en su trabajo diario. No es solo por la complejidad del tema, sino porque están acostumbrados a escribir código difícil de testear.

Escribir tests para software que ya funciona (sobre todo cuando se hizo sin pensar en testing) se siente aburrido y casi inútil. Viene acompañado de falta de motivación, culpando al sujeto equivocado: “los tests me hacen ir más lento”.

En un contexto de dominio, si una pieza de lógica de software es difícil de testear, el problema no es el test, sino el código que no estaba bien escrito.

Ya hay cientos de tutoriales, libros y documentación sobre testing. Aquí comparto mi experiencia y cómo aplico esta filosofía en mi trabajo diario.

Test-Driven se basa en esta simple regla

En lugar de: diseñar código -> desarrollar código -> escribir tests.

Se trata de: escribir test automatizado que falla -> ejecutar test que falla -> desarrollar código para hacer pasar el test -> ejecutar test -> repetir.

La idea de guiar tu código con tests depende del nivel de abstracción de lo que estés escribiendo. No quieres acoplar mal los tests con el código testeado. Quieres testear el comportamiento de tu lógica.

TDD se basa en un bucle de pequeños pasos que te ayuda a encontrar patrones y guiar tu diseño de software con refactorizaciones constantes. Es la mejor opción si quieres asegurar el comportamiento esperado de todos los caminos posibles de tu lógica.

Lo bonito es que no necesitas conocer el algoritmo completo desde el principio. Vas descubriendo cómo debería ser tu lógica expresando la implementación deseada, paso a paso, en tests automatizados.

Escribir tests al mismo tiempo que escribes el código te obliga a escribir mejor software. Porque quieres que sea fácil de testear, y eso lleva a mayor calidad.

Ya escribí otro post sobre la relación entre calidad y testing del software: El Arte del Testing: donde el diseño se encuentra con la calidad.

Mejora tus habilidades de Test-Driven

La mejor manera de aprender Test-Driven es haciendo katas de software. Pruébalas solo y con otros. Ambas son igualmente importantes.

Solo: para desafiar tu yo interior sin ninguna distracción excepto tú mismo.
Con otros: el pair-programming es esencial en nuestro trabajo. Las katas son las mejores herramientas para entrenar nuestras habilidades de comunicación y aprender juntos unos de otros.

¿Qué es una Code Kata?

Los desarrolladores no practicamos lo suficiente. La mayor parte de nuestro aprendizaje ocurre en el trabajo, y ahí es donde cometemos la mayoría de nuestros errores.

Otras profesiones creativas sí practican: los músicos tocan piezas técnicas, los poetas reescriben obras constantemente. En karate, un estudiante dedica la mayor parte del tiempo a aprender y perfeccionar movimientos básicos. Esas son las katas.

¿Cuál es el objetivo de una kata? ¿Qué deberíamos tener al final?

Las katas existen para que los desarrolladores obtengamos los mismos beneficios que practicar en otras profesiones. Son ejercicios simples y artificiales que permiten experimentar y aprender sin la presión de producción.

No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Consejos

Cuando resuelvas una kata, vuelve a intentarla en unas semanas o meses.
Explora nuevas soluciones. Sé creativo y no te apresures.
En grupo, no es una competición para ver quién logra más.
El foco debe estar en el proceso, nunca en el resultado.
El verdadero valor de cualquier kata son los aprendizajes que obtendréis después de hablar y compartir experiencias.

Puedes encontrar muchas katas en Internet. Por ejemplo:

TDD es más un flujo de trabajo que un diseño

“TDD es una herramienta de diseño.” Eso es lo que Sandro dijo durante años. Pero ya no. Tras trabajar con diferentes equipos y organizaciones, y observar cómo trabaja él mismo, Sandro cambió de opinión sobre el rol de TDD en el diseño de software.

TDD en pocas palabras; se trata del ritmo.

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

Kent Beck

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— Kent Beck 🌻 (@KentBeck) July 30, 2021

Imágenes originales de Emmanuel Valverde Ramos.

El señor de las moscas

2021-07-10T00:00:00+00:00

Un clásico que mezcla parábola, alegoría, mito, cuento moral y hasta parodia política.

Un grupo de niños británicos acaba varado en una isla desierta. Su intento de gobernarse a sí mismos termina en desastre.

El libro explora la tensión entre lo grupal y lo individual, entre la razón y la emoción, entre lo moral y lo inmoral.

Los primeros capítulos van lentos, pero construyen el contexto necesario. Después la historia escala rápido.

Responsabilidades de un Tech Lead

2021-07-01T00:00:00+00:00

El Modelo de Carrera Tridente de Patrick Kua tiene tres vías. Cada una representa dónde uno pasa la mayor parte de su tiempo o energía.

Historia Arquetípica

Contribuidor Individual

70–80% del tiempo dedicado a “Ejecutar, hacer”.
Diseñar. Testear. Programar.

Gestión

70–80% del tiempo dedicado a “Gestionar el sistema”.
Planificar. Organizar. Apoyar. Presupuestar.

Líder Técnico

70–80% del tiempo dedicado a “Liderar Temas Técnicos y Equipos”.
Alinear al Equipo. Visión Técnica. Aumentar el Conocimiento Técnico. Gestión de Riesgo Técnico y Deuda Técnica.

¿Qué es un Tech Lead?

“Un Tech Lead es un ingeniero de software, responsable de liderar un equipo de desarrollo, y responsable de la calidad de sus entregables técnicos.” (fuente)

Un Tech Lead es un Desarrollador que es un Líder

Un buen líder se asegura de que el equipo vaya en la misma dirección. Juntos se avanza más lejos que siendo solo personas que trabajan “juntas”.

Habilidades de liderazgo en las que invertir

Empatía
Autoconciencia
Motivación
Resolución de Conflictos
Comunicación
Coaching
Dar retroalimentación
Influencia
Delegación

El rol de Tech Lead es una posición de liderazgo, no necesariamente una posición de gestión.

Sorpresas y Luchas

Sentirse solo: te conviertes en un “outsider”. Tienes un rol diferente. Eres escudo y filtro.
Incertidumbre: no hay respuesta correcta. Vienes del hábito binario del código. Trabajas con información imperfecta.
Las personas desconciertan: son únicas, con diferentes fortalezas y arquetipos.

Un Gran Tech Lead

Un gran Tech Lead se enfoca en desarrollar a otros para que el equipo mejore sus capacidades.

¿Decir o Delegar?

El objetivo es alcanzar una delegación completa, paso a paso. Hay que trasladar responsabilidades a otras personas para que también crezcan. Esto depende de sus habilidades, motivaciones y la urgencia de la tarea.

“Nadie es perfecto, pero un equipo puede serlo.” - Meredith Belbin

Puntos clave

Tech Lead es un cambio de rol.
Requiere habilidades de liderazgo.
Otros han estado en este camino.
Hay muchos recursos disponibles.
Pasa del modo creador al multiplicador.

Libros recomendados en este campo

Referencias

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.”

Experimentos de Conformidad

2021-06-01T00:00:00+00:00

¿Hasta qué punto las fuerzas sociales alteran las opiniones de las personas? ¿Qué aspecto de la influencia del grupo es más importante — el tamaño de la mayoría, o la unanimidad de opinión?

El psicólogo Solomon Asch

Durante los primeros años de la Segunda Guerra Mundial, cuando Hitler estaba en la cúspide del poder, Solomon Asch empezó a estudiar el impacto de la propaganda y el adoctrinamiento. Era profesor en el departamento de psicología del Brooklyn College y luego estuvo 19 años en Swarthmore College.

En los años 50, Asch se hizo famoso por sus experimentos sobre la presión social y la conformidad. ¿Hasta dónde llega la gente para encajar con otros en un grupo? Su investigación mostró que los participantes tendían a conformarse con el grupo, incluso cuando creían que estaba equivocado.

Asch preguntó

¿Hasta qué punto las fuerzas sociales alteran las opiniones de las personas? ¿Qué aspecto de la influencia del grupo es más importante — el tamaño de la mayoría, o la unanimidad de opinión?

Asch creía que las personas se comportan según cómo perciben el mundo, no según cómo es realmente.

El experimento de Asch

Asch diseñó un experimento basado en un “simple test de visión”.

Metió a un participante en una sala con otros actores (cómplices). Los actores habían acordado dar respuestas incorrectas a propósito la mayoría de las veces.

El participante real no lo sabía. Creía que todos eran participantes como él.

Cada persona en la sala decía en voz alta qué línea (A, B o C) se parecía más a la línea objetivo. La respuesta siempre era obvia. El participante real se sentaba al final y respondía en último lugar.

Asch quería ver si el participante se conformaría con la mayoría. Los actores daban la respuesta incorrecta la mayoría de las veces (las llamadas pruebas críticas).

Hallazgos

Casi el 75% de los participantes en los experimentos de conformidad siguieron al resto del grupo al menos una vez.

Asch también descubrió algo clave: cuando uno de los actores daba la respuesta correcta mientras el resto se equivocaba, la conformidad bajaba drásticamente. El apoyo social es una herramienta poderosa para resistir la presión del grupo.

Después de combinar las pruebas, los resultados indicaron que los participantes se conformaban con la respuesta incorrecta del grupo aproximadamente un tercio de las veces.

Conclusión

¿Por qué los participantes se conformaron tan fácilmente? En las entrevistas posteriores, la mayoría admitió que no creían en sus respuestas conformistas. Simplemente siguieron al grupo por miedo a quedar en ridículo.

Unos pocos sí creían que las respuestas del grupo eran correctas.

La gente se conforma por dos razones principales: quieren encajar (influencia normativa) o creen que el grupo sabe más que ellos (influencia informativa).

La conformidad puede ser influenciada tanto por una necesidad de encajar como por una creencia de que otras personas son más inteligentes o están mejor informadas.

Factores que influyen en la conformidad

Asch siguió experimentando para entender qué factores influyen en la conformidad. Descubrió que:

Aumenta cuando hay más personas presentes.
Aumenta cuando la tarea es más difícil.
Aumenta cuando los otros miembros tienen un estatus social más alto.
Disminuye cuando la gente puede responder en privado (cuando nadie ve su respuesta).

Recursos

Solomon Asch | Wikipedia

Peopleware

2021-05-28T00:00:00+00:00

El desarrollo de software va de personas: cuándo, cómo y dónde trabajan mejor juntas. No de lenguajes de programación ni herramientas. No de ordenadores rápidos, redes o internet.

Las habilidades blandas importan más de lo que la gente cree en IT.

Desarrollar software va de personas que se comunican con clientes y stakeholders, reciben apoyo de sus managers y colaboran en equipos.

Citas favoritas

Quedarse hasta tarde o llegar temprano es una acusación al entorno de oficina.
Alguien que ayuda a dar forma y avanzar un proyecto vale por dos que solo ejecutan.
Hay que preguntarse por qué las cosas se hacen como se hacen.
Siempre debe haber equilibrio entre calidad y cantidad.
Las organizaciones tienden a crear “días ocupados” con muchas reuniones, en lugar de confiar en que sus empleados se autoorganicen.
El factor humano suele ser el cuello de botella de un proyecto.
La gente no trabaja más duro bajo presión. Puede que rindan más un tiempo, pero se quemarán y se irán.
El rol del manager es facilitar que la gente trabaje, no forzarla.
Cualquier cosa que necesites medir puede medirse de alguna forma, y eso es mejor que no medirla.
El pecado capital de la gestión es desperdiciar el tiempo de la gente.
El cambio no arranca si la gente no se siente segura.
El cambio solo funciona si un poco de fracaso está permitido.
La experiencia se convierte en aprendizaje cuando la organización se adapta a lo que ha descubierto.

Los profesionales quieren crecer y ser felices en el trabajo. Este libro da ideas sobre lo que managers y desarrolladores pueden hacer al respecto. Si te importan las personas y buscas mejorar cómo desarrollas software en equipo, este libro es para ti.

El todo es mayor que la suma de las partes

Usamos la palabra “equipo” de forma muy imprecisa en el mundo empresarial. Llamamos equipo a cualquier grupo de personas que trabajan juntas. Pero muchos de estos grupos no parecen equipos. No tienen una definición común de éxito ni espíritu de equipo. Algo falta: un fenómeno que llamamos cohesión (jell).

El equipo cohesionado

Un equipo cohesionado es un grupo tan unido que el todo supera la suma de las partes. Su producción es mayor que si las mismas personas trabajaran por separado. Y el disfrute que obtienen de su trabajo supera lo que esperarías por la naturaleza del trabajo en sí.

Una buena serie con reflexiones sobre cada capítulo del libro.

Software de Código Abierto

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

¿Qué es el Software de Código Abierto (OSS)? ¿Cuáles son sus beneficios? ¿Cómo puedes empezar a contribuir a cualquier OSS? ¿Proyectos personales? ¿Compartir conocimiento? ¿Por qué todo esto?

¿Qué es OSS?

OSS tiene similitudes con el software libre, pero no es lo mismo. El software libre es una forma de OSS, aunque eso no significa que tenga que ser gratis. Por ejemplo:

PHPUnit es un ejemplo de OSS que es gratuito.
Spryker es un ejemplo de OSS que no es gratuito.

OSS es básicamente software que es público, abierto al mundo.

Beneficios

Para Empresas

Adopción: cuanto más fácil el acceso, más fácil la adopción.
La formación y los tutoriales ayudan al crecimiento del sistema.
Tecnología: suelen estar en la vanguardia. La tecnología avanza rápido y quedarse atrás significa volverse obsoleto.
Comunidad: la gente quiere mejorar a medida que el proyecto crece. Los canales públicos facilitan el acceso y construyen comunidad.
Confianza: el software es público y accesible. Cualquiera puede verificar su calidad en cualquier momento.

Para Contribuidores Individuales

Flexibilidad: decides en qué trabajar.
Autoconfianza: la experiencia mejora tus habilidades.
Formación: sin la presión de un entorno de producción.
Tecnología: puedes jugar con las últimas novedades. Prueba nuevas versiones de tu lenguaje o incluso lenguajes nuevos.
Habilidades blandas: mejoras tu comunicación. Esto importa mucho, especialmente cuando hay desacuerdos.

Contribuyendo a OSS

Empezando con GitHub

Hoy en día, es realmente trivial empezar a contribuir a OSS:

Puedes empezar tu propio proyecto. ¡Un proyecto personal encaja aquí perfectamente!
Puedes contribuir a un proyecto OSS existente.

Proyectos Personales

Un proyecto personal es un terreno de juego para crear software y entrenar tus habilidades. Tener proyectos personales en tu perfil público de GitHub tiene todos los beneficios de contribuir a OSS, y además eres tu propio jefe:

Tú dictas la hoja de ruta.
Tú decides qué hacer 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:

php-best-practices: lo que considero mejores prácticas para desarrollo web.
php-scaffolding: un scaffolding básico de PHP con Docker.

Inactivos:

stock-ticker: recibe una notificación con las noticias de tus Tickers favoritos.
jira-status-notifier: notifica cuando los tickets de JIRA no avanzan.
edifact-parser: un parser para formato de archivo UN/EDIFACT en PHP.

Abandonados:

knob-mvc: un framework para crear plantillas WordPress (2015/2017).

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

Posts del Blog

Pull Requests vs Pair Programming
El proceso en sí es la meta
El arte del refactoring; Cuándo, Cómo y Por qué
El arte del testing: Donde el diseño se encuentra con la calidad

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

La Belleza del OSS

Ver las correcciones que constantemente sigues haciendo
Ver cómo tu propio código envejece con el tiempo
Ver los muchos errores que has cometido
Ver cómo estás mejorando en programación con el tiempo

Vas desarrollando un sexto sentido para detectar patrones que ya has visto, con sus experiencias buenas y malas.

Mostrando tus habilidades y ayudando a la comunidad a tu alrededor.

El Software de Código Abierto te ofrece una de las mejores oportunidades para empezar a construir tu camino profesional 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. Básicamente presento todas estas ideas junto con una demo en vivo de cómo contribuir a un OSS real.

El arte del liderazgo

2021-04-19T00:00:00+00:00

Notas destacadas

Liderar son pequeñas cosas hechas de forma consistente.
La empatía es una habilidad poderosa.
Los uno a uno son clave para conectar con el equipo.
Pedir feedback genera confianza y fortalece relaciones.
Ante el feedback, da las gracias y haz preguntas para entender mejor.
El feedback es un regalo.
No es personal, es profesional.
El liderazgo es un traje que eliges ponerte para que otros lo vean.
Los managers te dicen dónde estás; los líderes, hacia dónde vas.
Tus compañeros se convierten en tus aliados.

97 cosas que todo Engineering Manager debería saber

2021-04-05T00:00:00+00:00

La lección principal

Tu trabajo como manager es crear claridad. Claridad y más claridad.

Ideas clave

Trabaja en corregir tus propias manías.
Haz experimentos en lugar de tomar decisiones definitivas.
“Test de malas noticias”: si tienes dos tareas, delega aquella sobre la que preferirías dar malas noticias.
Cuando un equipo tiene problemas, responde primero dos preguntas:
- ¿Cómo creo claridad?
- ¿Cómo creo capacidad?
Pide que te aclaren las cosas.
Para dar feedback constructivo, observa dónde la persona se bloquea, se desvía o se descuida.
Gestionar no es un ascenso. Es un cambio de carrera.
La mayoría de las disfunciones vienen de objetivos poco claros.
Con fecha límite fija, el alcance y la calidad siempre son negociables.
El contagio emocional existe.
Si eres nuevo como manager, escucha y entiende antes de cambiar nada.
Buenas preguntas de entrevista:
- ¿Qué has aprendido en los últimos seis meses?
- Cuéntame de una vez que fallaste y qué aprendiste.
- ¿Tienes las habilidades y experiencia para este trabajo?
Las quejas son buenas: significan que confían en ti.

Otro artículo con ideas clave más detalladas: Danlebrero Blog ;)

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Hablemos de los beneficios de los Pull Requests y el Pair Programming, y mis reflexiones sobre estos después de algunos años de experiencia con ellos.

Pull Requests

Un Pull Request (PR) es una forma de mostrar tus cambios de código para que se comparen fácilmente con el código existente. Es parte de un flujo de trabajo que ayuda a compartir conocimiento sobre los cambios que se hacen en el sistema.

Un Pull Request es el momento donde pides a tus compañeros que revisen y examinen tus cambios de código.

Normalmente, también se usa:

Para discusiones sobre estilo de código.
Para detectar bugs potenciales.
Para discusiones de arquitectura o diseño una vez que la solución está hecha.

Los Pull Requests no son la mejor herramienta para todo

El problema es que los PRs suelen estar listos cuando la funcionalidad o bug ya está terminado, en la última etapa del desarrollo. Un PR es una “propuesta de cambio ya hecha para fusionar en el sistema actual”.

El concepto de “Draft PR” existe para indicar que el PR aún no está listo para fusionar, pero ese es otro tema.

Los Pull Requests son una de las mejores herramientas para compartir conocimiento sobre cambios en el sistema, pero a veces se usan mal:

Discusiones sobre estilo de código. El estilo no debería discutirse en un PR. Ya debería haber un CI ejecutando un linter. Si quieres cambiar algo, proponlo en el linter, no en un PR aleatorio.
Detectar bugs. Los bugs y comportamiento esperado deberían cubrirse con tests automatizados. El desarrollador es el primer responsable.
Discusiones de arquitectura o diseño. Cuando una solución está desarrollada y lista para revisión, es difícil “deshacerla” y reescribirla. “¿Por qué lo harías? Ya está hecho y funciona.”

Tener a alguien extra revisando decisiones de diseño puede ayudar, pero podríamos haber resuelto posibles desacuerdos antes.

¿Cuál debería ser el propósito de un Pull Request?

Compartir conocimiento sobre los cambios propuestos con el equipo.
Asegurar que el equipo está alineado con los múltiples cambios que se envían cada día. Sí, puede incluir verificar el diseño, pero… ¿y si ya es demasiado tarde?

Pair Programming

El “Pair Programming” puede entenderse de varias formas: pair thinking, roles conductor-navegador, live coding… En realidad es más sencillo de lo que parece:

Miras y ayudas a la otra persona a escribir código, o
Escribes mientras tienes otro par de ojos mirándote y ayudándote.

El Pair Programming ayuda al equipo a trabajar juntos.

El pair programming es trabajar con un cerebro extra y otro par de ojos. La clave es construir un contexto donde ambos compartan el mismo objetivo para encontrar la mejor solución posible, aprendiendo el uno del otro. No se trata de dar con la mejor solución desde el principio. Se trata de hacerlo funcionar, compartir ideas y mejorar juntos. Luego ya refactorizas y limpias el código.

El Pair Programming es una revisión de código continua

Los Pull Requests son una forma asíncrona de compartir cambios de código, mientras que el Pair Programming es totalmente síncrono porque sucede al mismo tiempo.

Los Pull Requests y el Pair Programming no son excluyentes, pueden coexistir. Son herramientas, y hay que elegirlas con criterio según nuestros objetivos.

El miedo más común que he visto al animar a hacer Pair Programming es la timidez. A algunas personas no les gusta tener ojos encima mientras programan:

Miedo a no saber qué programar o por dónde empezar.
Miedo a que otros se rían de sus soluciones.
Miedo a no tener éxito en público.
Miedo a no poder desarrollar la solución esperada por múltiples razones: malentender la tarea o falta de conocimiento.
Miedo a cambiar de opinión frente a otros.
Miedo a discutir y tomar decisiones en voz alta.
Miedo a estar en desacuerdo con otros.

Después de varios años de experiencia en este tema

El patrón que rechaza el Pair Programming es básicamente el miedo a salir de tu zona de confort. Y viene de no entender qué es realmente el Pair Programming.

No se trata de presumir ni de ser juzgado, sino de ser transparente (mostrar tus habilidades tal como son) y mejorar como equipo.

Programar es un proceso iterativo que requiere refactorizar continuamente nuestra forma de pensar. Programar con otra persona (con otra forma de pensar) ayuda al equipo a sacar lo mejor de cada uno y a descartar malos hábitos.

El Pair Programming no tiene que usarse siempre ni para todo. Es una herramienta flexible: puedes elegir cómo, cuándo y por qué.

Una regla personal: antes de empezar tareas que tocan múltiples módulos o reglas de negocio complejas, haz un Pair Thinking rápido con un colega más experimentado en ese área.

Todo depende de un contexto y personas particulares: los desarrolladores, las parejas, las tareas, el estado de ánimo.

¿Todavía incómodo con el Pair Programming?

Si aún te sientes incómodo con alguien a tu lado mientras programas, quizás no estés contento con tu propio código o con el proceso que sigues. Mi forma favorita de trabajar esto es practicar por mi cuenta y mejorar mis habilidades como desarrollador.

Crea y juega con tus propios proyectos personales.
Trabaja en katas de código por tu cuenta y con otros.

La práctica hace al maestro.

Resumen

No me malinterpretes, los Pull Requests son geniales. Sigue haciéndolos.
La colaboración en equipo es esencial. El Pair Programming apunta a esto.
El Pair Programming anima al equipo a trabajar juntos proactivamente.
No tengas miedo de programar mientras tienes ojos a tu alrededor. Haz preguntas cuando algo no esté claro. Pide ayuda cuando no sepas cómo resolver algo.

Está totalmente bien no saber todo. Lo más importante es saber cómo trabajar juntos.

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

Guía de supervivencia Zombie Scrum

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

Disfruté mucho las ideas y experimentos del libro. Pone el dedo en la llaga sobre muchos equipos que dicen hacer Scrum o Agile de forma cuestionable. A eso lo llaman Zombie Scrum.

Resumen

El libro explica por qué Scrum se estanca y cómo mejorar tus resultados divirtiéndote en el proceso. Con humor y ejemplos muy reconocibles, ofrece enfoques prácticos, ejercicios y herramientas para escapar del Zombie Scrum.

Aunque estés rodeado de escépticos, este libro te ayudará a construir lo que los usuarios realmente necesitan, entregar más rápido, mejorar continuamente y sentirte mejor con tu trabajo. Un día recordarás: para esto adoptamos Scrum.

Cómo te infecta el Zombie Scrum, por qué se propaga y cómo prevenirlo
Acércate a tus stakeholders y hazles entender el valor
Por qué los equipos Zombie no aprenden y qué hacer al respecto
Elimina los obstáculos para la mejora continua
Logra equipos autogestionados donde la gente actúe como humanos, no como zombies

Un buen webinar donde comparten ideas clave del libro y discuten sus hallazgos más recientes.

Gestión ágil de productos con Scrum

2021-02-22T00:00:00+00:00

Temas principales

El rol del product owner
Cómo visualizar el producto
Refinamiento del product backlog
Planificación de releases
Colaboración en las reuniones de sprint
La transición hacia el product ownership

Phel: el Lisp que Compila a PHP

2021-02-01T00:00:00+00:00

Un nuevo lenguaje de Programación Funcional construido sobre el ecosistema de PHP.

El Lenguaje Phel

Phel es un lenguaje de Programación Funcional (FP) que compila a PHP. Es un dialecto de Lisp inspirado en Clojure y Janet.

Características

Construido sobre el ecosistema de PHP
Buenos reportes de errores
Diferentes estructuras de datos (Arrays, Tables y Tuples)
Macros
Funciones recursivas
Sintaxis potente pero simple
REPL

¿Por qué Phel?

Phel lo creó Jens Haase. Como menciona en el sitio web, “es el resultado de muchos intentos fallidos de hacer programación funcional en PHP”. Buscaba algo con estas características:

Inspirado en LISP
Lenguaje de Programación Funcional
Que funcione en proveedores de hosting baratos
Sea fácil de escribir y depurar

A finales de mayo de 2020 terminé el libro Seven Languages in Seven Weeks, donde aprendí los fundamentos de Prolog, Erlang, Clojure, Haskell… Incluso creé un repositorio en GitHub para guardar mi progreso.

A principios de junio de 2020, vi un post en el canal de PHP de Reddit mencionando este proyecto “Phel”: un lenguaje de programación funcional escrito en PHP.

Llevo unos 8 años trabajando con PHP, y siempre intento combinar OOP con FP (creo que ambos paradigmas funcionan mejor juntos; no son excluyentes). Un nuevo dialecto de Lisp escrito en PHP 7.4 nativo sonaba emocionante. Decidí echarle un vistazo al código.

Las lecturas recientes de Mathias NoBack, como Object Design Style Guide y Advanced Web Application Architecture, me dieron el empuje para aplicar lo aprendido en un proyecto real. Este fue (y sigue siendo) un desafío que me ayuda a crecer profesionalmente.

Mi primer commit fue el 6 de junio de 2020. Desde entonces dedico un poco de tiempo cada día en mis horas libres. Me ayuda a aprender sobre FP, diseño interno de lenguajes, testing y arquitectura de software en general.

Empecé con cambios menores hasta que acabé refactorizando toda la estructura del compilador para hacer los módulos más legibles. Psalm, tipos estrictos, buena cobertura de tests, estilo de código unificado… Estos fueron algunos de mis temas favoritos.

Ejemplo de código Phel

El siguiente ejemplo da una breve impresión de cómo se ve Phel:

# Define un namespace
(ns my\example)
# Define una variable con nombre "my-name" y valor "world"
(def my-name "world")
# Define una función con nombre "print-name" y un argumento
(defn print-name [your-name]
 (print "hello" your-name))
# Llama a la función
(print-name my-name)

Estado actual de Phel

Preparamos una fácil Guía de Inicio
Preparamos un Repositorio GitHub fácil con una Plantilla de Scaffolding de Phel
Acabamos de lanzar la primera versión oficial: 0.1.0

Consulta el sitio web oficial con toda la documentación: https://phel-lang.org/

También recomendado

Functional Programming with Phel - JesusValera

Invertir en bolsa para principiantes

2021-01-31T00:00:00+00:00

Conceptos básicos del mercado de valores
Análisis fundamental, de industria y de empresas
Estilos de inversión: valor, crecimiento e ingresos
Venta en corto, compra con margen, day trading

Un paso por delante de Wall Street

2021-01-22T00:00:00+00:00

Peter Lynch, uno de los gestores de fondos más exitosos de Estados Unidos, explica cómo el inversor común puede ganarle a los profesionales usando lo que ya sabe. Las oportunidades de inversión están en todas partes.

¿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

Padre rico, padre pobre

2021-01-15T00:00:00+00:00

Desmonta el mito de que necesitas ganar mucho para volverte rico
Cuestiona la idea de que tu casa es un activo
Explica por qué no puedes confiar en la escuela para enseñar a tus hijos sobre dinero
Define de una vez qué es un activo y qué es un pasivo
Te da herramientas para educar a tus hijos en finanzas personales

Mockear o No Mockear

2021-01-11T00:00:00+00:00

Mockear es útil, pero “qué mockear” suele resultar más complicado de lo esperado si no tratas esto con cuidado.

Cómo escapar del infierno del mocking

¿Qué pasa realmente cuando creamos un mock? ¿Qué tipos hay? ¿Es bueno o malo mockear? Como siempre, depende del contexto. Aquí veremos las situaciones principales: cuándo mockear, cuándo no hacerlo, y sobre todo por qué.

¿Qué pasa cuando mockeas algo?

Primero, deberíamos definir qué es un mock:

En un test unitario, los objetos mock pueden simular el comportamiento de objetos reales complejos y por lo tanto son útiles cuando es impracticable o imposible incorporar un objeto real en un test unitario.

Mockear tiene sentido en testing unitario. Un test de integración pasa por la implementación real, verificando cómo interactúan varias unidades. Estos tests sí pueden hablar con la BD o el sistema de archivos. Partimos de esta base: un test unitario es rápido, determinista, no depende de recursos externos y no requiere contexto especial para ejecutarse.

Los mocks cumplen el contrato de la interfaz. Nos permiten testear funcionalidad sin invocar clases colaboradoras complejas.

Un mock es un doble de test que sustituye la implementación real. Además, puede verificar cómo el código bajo test lo utilizó durante la ejecución.

Recomiendo encarecidamente que leas este post si quieres entrar en los detalles de por qué Mockear es un code smell (Temas como estos: ¿Qué es un mock? ¿Qué es un test unitario? ¿Qué es la cobertura de tests? ¿Qué es el acoplamiento fuerte? ¿Qué causa el acoplamiento fuerte? ¿Qué tiene que ver la composición con el mocking? ¿Cómo eliminamos el acoplamiento? ¡y más!)

El problema con mockear

Cuando mockeas, anulas la lógica de la clase mockeada. La lógica real queda oculta, y ahí es donde los bugs se esconden. Ten en cuenta que:

El mock puede tener atributos, métodos o argumentos que el objeto real no tiene.
Los valores de retorno del mock pueden diferir de los reales. Por ejemplo, puede devolver un tipo distinto con atributos diferentes.
Los efectos secundarios y comportamiento del mock pueden diferir del objeto real. Quizás el mock no lanza una excepción que el objeto real sí lanzaría.

Alternativas a mockear

“¿Estás diciendo que mockear es malo y no deberíamos mockear?” No.

Depende de lo que estés “anulando”.

¿Es tu lógica de dominio de negocio lo que estás mockeando? Entonces está mal.
¿Es la conexión a la BD lo que estás mockeando? Entonces está bien.

Depende del contexto de la lógica y dónde pertenece esa lógica.

¿Es parte de tu lógica de dominio de negocio? Entonces no deberías mockearla sino instanciarla.

¿Es una dependencia de infraestructura como conexión a BD, sistema de archivos, red, o cualquier servicio externo que no tiene que ver con tu dominio de negocio? Entonces mockéala usando abstracciones/interfaces.

La interfaz es el contrato entre tu lógica de dominio y sus dependencias de infraestructura. Imagina lo fácil que es testear tu dominio instanciándolo y llamando a sus métodos con diferentes argumentos, todo bajo tu control total.

Algunos trucos

Cuando estés escribiendo un test unitario:

Intenta instanciar tus clases primero.
Evita mockear clases concretas. Escribí un artículo exclusivamente sobre esto: fomentando clases finales e interfaces.

Mockea interfaces. Instancia clases concretas.

“El uso excesivo de mocks lleva a código legacy.” — Philippe Boargau

¿Cómo podemos evitar el mocking excesivo?

Favorece el estado inmutable sobre el estado mutable.
Haz las dependencias explícitas.
Programa hacia una interfaz, no hacia una implementación.

Referencias

Mocking is a code smell — Eric Elliott
When to mock & Test Definitions — Uncle Bob
Final classes by default — Matthias Noback
The problem with mocks — Sean Hammond
A Set of Unit Testing Rules — Michael Feathers

Compartiendo tus Parches de Git

2020-12-01T00:00:00+00:00

Descubre otra forma de compartir sugerencias con tu equipo de desarrollo.

Imagina esta situación

Estás revisando un Pull Request (PR), y ves algunas mejoras menores o sugerencias que te gustaría compartir con el autor. Podrías escribir algunos comentarios, y normalmente, eso sería suficiente.

Imagina que para transmitir tu “idea completa” necesitarías cambiar algunos archivos porque simplemente comunicar la imagen completa acabará en un comentario enorme que podría no ser tan claro como podría ser.

¿Qué posibilidades hay aparte de solo comentarios en un PR?

Bueno, hay múltiples opciones. La clave es ser consciente de ellas y usarlas sabiamente dependiendo de la prioridad de la tarea y los cambios en sí:

Como ya se mencionó, escribir un comentario como retroalimentación es una buena idea por defecto, pero no la única.
Siempre podemos hacer algo de pair-thinking, hablar en cualquier momento. La comunicación siempre es buena para aclarar la posible incertidumbre.
Compartir tus parches de git es otra buena opción.

¡Git diff al rescate!

¿Y si tú (como revisor) pudieras compartir tu idea sin ningún commit o comentario en el PR, pero compartiendo tus cambios directamente con el autor?

Bueno, eso es realmente posible y muy fácil. Como ya sabes, el comando git diff te da las diferencias entre dos ramas cualesquiera.

git diff origin develop > ../my-origin-develop.patch

Lo que estamos haciendo aquí es redirigir la salida del comando diff a un archivo (también conocido como: parche), para poder compartir esa salida con cualquier otro compañero de equipo.

¿Y ahora qué?

Bueno, teniendo ese archivo de parche, es bastante fácil aplicar esos cambios en tu máquina local sin hacer ningún commit:

git apply ../my-origin-develop.patch

Aplicar este parche simplemente cambiará tu sistema local de la misma manera que se creó el parche.

“Cómo hacerlo” por pasos

Dividamos las responsabilidades en dos: el creador del parche y su usuario:

El creador del parche: la persona que creará el parche

# Cambia a esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Haz tus sugerencias y cambios en la rama objetivo
# Genera el archivo de parche usando el comando diff
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Comparte el archivo de parche con el autor del PR

El usuario del parche: la persona que verá el parche

# Asegúrate de estar en esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Aplica el archivo de parche
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

Referencias

Documentación oficial de “git apply”

Principios de diseño de paquetes

2020-11-12T00:00:00+00:00

Aprende a aplicar principios de diseño a tus clases para que sean reutilizables. El libro te enseña a crear paquetes con la cohesión y acoplamiento adecuados, pensados para usuarios y mantenedores.

La primera parte cubre los cinco principios SOLID para mejorar el diseño de clases. La segunda parte entra en las mejores prácticas de diseño de paquetes: principios de cohesión y de acoplamiento.

Los principios de cohesión te dicen qué clases van juntas, cuándo dividir un paquete, y cuándo un grupo de clases puede llamarse “paquete”. Los de acoplamiento te ayudan a elegir bien las dependencias y evitar ciclos en el grafo de dependencias.

Lo que aprenderás

Aplicar los principios SOLID
Decidir si las clases pertenecen al mismo paquete
Saber cuándo un paquete puede depender de otro

Nunca Uses array_merge en un Bucle

2020-11-10T00:00:00+00:00

Usar array_merge dentro de un bucle mata el rendimiento. El operador spread te ayudará a mejorar esto aplanando el array.

Aplanando un array de un nivel

He visto a gente usar array_merge dentro de un bucle así:

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = [];
foreach($lists as $list) {
 $merged = array_merge($merged, $list);
}
// $merged === [1, 2, 3, 4, 5, 6];

Esto es mala práctica porque destroza el rendimiento de memoria. Mejor usa el operador spread (disponible desde PHP 5.6):

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = array_merge(...$lists);
// === [1, 2, 3, 4, 5, 6];

Desempaquetando un array asociativo

¿Y si tuvieras un array asociativo como este?

<?php
$lists = [
 'key-1' => [1, 2],
 'key-2' => [3, 4],
 'key-3' => [5, 6],
];

En ese caso, necesitarás desempaquetar sus valores:

<?php
$merged = array_merge(...array_values($lists));
// === [1, 2, 3, 4, 5, 6];

En programación funcional, esto se conoce como aplanar una lista. Sin bucles ni problemas de rendimiento.

Aplanando un array multinivel

¿Y si quisieras aplanar un array multinivel como este?

<?php
$lists = [[1], 2, [[3, 4], 5], [[[]]], [[[6]]], 7, 8, []];

¿O como este, incluso con clave-valores?

<?php
$lists = [
 'key-1' => [
 1,
 [2],
 'key-2' => [
 3,
 [
 'key-3' => [4, 5],
 ],
 ],
 ],
 6,
 'key-4' => [7, 8],
];

Para estos casos, puedes usar la librería estándar de PHP:

<?php
$merged = iterator_to_array(
 new RecursiveIteratorIterator(
 new RecursiveArrayIterator($lists)
 ),
 $use_keys = false
);
// $merged === [1, 2, 3, 4, 5, 6, 7, 8];

Conclusión

Normalmente, saber aplanar un array de dos niveles suele ser suficiente:

<?php
$flattenList = array_merge(...array_values($lists));

Para casos más complejos, la librería estándar de PHP te saca del apuro.

Referencias

Rebelión en la granja

2020-11-02T00:00:00+00:00

El Sr. Jones, dueño de la Granja Manor, es tan vago y borracho que un día se olvida de dar de comer a los animales. Eso desata una rebelión. Los cerdos Napoleón y Bola de Nieve toman el liderazgo y los animales se hacen con el control.

Juran acabar con las desigualdades. La granja pasa a llamarse Granja Animal y se organiza para beneficiar a todos los que caminan en cuatro patas. Pero con el tiempo, los ideales se corrompen. Después, se olvidan. Y algo nuevo e inesperado emerge.

Arrays Tipados en PHP

2020-10-13T00:00:00+00:00

Desempaquetado de argumentos, lista de argumentos variables de función, y funciones variádicas.

La combinación perfecta

Desempaquetado de argumentos: pasa los elementos de un array como argumentos individuales a una función.
Lista de argumentos variables: la función recibe los argumentos como un array.
Función variádica: permite verificar los tipos con un type-hint.

Usaremos este snippet para nuestros ejemplos. Tenemos una clase Customer:

<?php
/**
 * @psalm-immutable
 */
final class Customer
{
 // Usando la promoción de propiedades en constructor de PHP 8
 // https://wiki.php.net/rfc/constructor_promotion
 public function __construct(
 public string $name,
 ) {}
}
// Creamos una lista de 6 clientes
$customers = array_map(
 fn(int $i): Customer => new Customer("name-{$i}"),
 range(1, 6)
);

Siempre que queramos manipular una lista de Customers, podemos pasar como argumento: …$customers.

Cómo solíamos hacerlo

Definimos el tipo del array con PHPDoc, pero no podemos forzar el tipo real de cada elemento. El código se ejecuta sin problemas aunque pases cualquier tipo en array $customers:

<?php
/**
 * @param Customer[]
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 // ... alguna lógica irrelevante para este ejemplo
 }
}

El código de abajo funcionaría en “tiempo de compilación”. Pero podría fallar en “tiempo de ejecución”.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]);

Una alternativa recomendada: extraer la lógica y pedir el tipo concreto para verificarlo en tiempo de ejecución. Fallará si alguno de los elementos no es un Customer:

<?php
/**
 * @param Customer[]
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}
function createInvoice(Customer $customer): void
{
 // ... alguna lógica irrelevante para este ejemplo
}

Todo lo de aquí abajo funcionaría en “tiempo de compilación”. Seguro que fallará durante “tiempo de ejecución” si createInvoice(Customer $customer) recibe algo diferente a un Customer.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]); // no funcionará

Con createInvoice(Customer $customer) aseguramos el tipo del argumento. Pero, ¿podemos ir un paso más allá? ¿Podríamos verificar los tipos al llamar a createInvoiceForCustomers(array $customers), y que el IDE se queje si los tipos no son correctos?

Eso es precisamente para lo que sirven los Generics, pero aún no existen en PHP. Ni siquiera en PHP 8. Quizás lleguen pronto, pero por ahora hay una alternativa menos conocida con sus pros y contras. Veamos un ejemplo:

<?php
function createInvoiceForCustomers(Customer ...$customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}

Todo lo de aquí abajo funcionaría en “tiempo de compilación”. Seguro que fallará durante “tiempo de ejecución” si createInvoice() recibe algo diferente a un Customer.

<?php
createInvoiceForCustomers(...$customers); // OK
createInvoiceForCustomers(
 new Customer('any name'),
 new Customer('any name'),
); // OK
// Esto ni siquiera es posible de escribir. El IDE te gritará.
// Está esperando un `Customer`, pero `AnyOtherType` es dado:
createInvoiceForCustomers(new AnyOtherType());

PROS

Podemos tipar una lista de cualquier tipo concreto de forma sencilla.

CONTRAS

Mejor limitar las funciones a uno o dos argumentos. De lo contrario, se complica la lectura.

Observaciones importantes

Debe ser el último argumento de la función.
Ayuda a minimizar el número de argumentos.

Conclusiones

El desempaquetado de argumentos, combinado con funciones variádicas, nos permite simular arrays tipados. Un gran poder conlleva una gran responsabilidad. Hay que conocer bien nuestras herramientas para usarlas con criterio.

Referencias

Guía de estilo para diseño de objetos

2020-10-10T00:00:00+00:00

Los objetos son el corazón de lenguajes como Java, Python y C#. Si aplicas buenas prácticas de diseño, tu código será más fácil de leer, escribir y mantener.

Este libro reúne docenas de técnicas para crear código OO profesional que aguanta el paso del tiempo.

Los ejemplos usan pseudocódigo fácil de entender. Las técnicas aplican a cualquier lenguaje OO, desde C++ hasta PHP.

Domain-Driven Design Distilled

2020-09-10T00:00:00+00:00

Este libro hace que DDD cobre vida. Da igual si eres desarrollador, consultor o cliente: te ayuda a entenderlo y sacarle provecho.

Desarrolladores de todo el mundo lo están adoptando porque da resultados reales. Es una guía accesible que responde:

¿Qué es DDD?
¿Qué problemas resuelve?
¿Cómo funciona?
¿Cómo sacarle valor rápido?

Aprenderás a separar modelos de dominio con Contextos Acotados (Bounded Contexts), a desarrollar un Lenguaje Ubicuo dentro de cada contexto, y a lograr que expertos de dominio y desarrolladores colaboren para crear ese lenguaje.

También cubre cómo usar Subdominios para manejar sistemas legacy e integrar varios Contextos Acotados definiendo relaciones entre equipos.

Domain-Driven Design Distilled da vida a DDD.

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

Testeando Código Legacy de Forma Efectiva

2020-08-17T00:00:00+00:00

Estos tests también se conocen como tests de caracterización.

Un test de caracterización describe el comportamiento real de una pieza de software existente, y por lo tanto protege el comportamiento existente del código legacy contra cambios no intencionados mediante testing automatizado. Este término fue acuñado por Michael Feathers.

Permiten y proporcionan una red de seguridad para extender y refactorizar código que no tiene tests adecuados. Se puede escribir un test que afirme que la salida del código legacy coincide con el resultado observado para las entradas dadas.

¿Cómo empezar?

Estos son mis aprendizajes un año después de leer Working Effectively with Legacy Code y aplicarlo a los diferentes proyectos en los que he trabajado desde entonces.

1. ¿Qué quieres testear?

Averigua las aserciones. Crea un archivo de test para tu clase, y un método de test para la función que quieres testear. Pista:

Si tienes el siguiente método applySomeLogic(): ReturnType,
el test que podrías escribir es test_apply_some_logic(): void.

final class MyBusinessLogic
{
 private DependencyInterface dependencyInterface;
 private ConcreteDependency concrete;

 public function __construct(
 DependencyInterface dependencyInterface,
 ConcreteDependency concrete
 ) {
 this.dependencyInterface = dependencyInterface;
 this.concrete = concrete;
 }

 public function applySomeLogic(Input input): ReturnType
 {
 // caja negra responsable de crear un ReturnType
 // basado en el Input dado
 return returnType;
 }
}

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 // Quiero afirmar que "aplicando alguna lógica"
 // de MyBusinessLogic con el Input dado
 // recibiré un ReturnType concreto con un
 // cierto valor como su propiedad. Algo como:

 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

2. Instancia la clase concreta/final que quieres testear.

No mockees tus clases concretas. Especialmente tu dominio de negocio. Mockea solo interfaces. De lo contrario, puedes estar ocultando bugs sin querer (¡con tests verdes/pasando!). Trata tus clases de dominio de negocio como finales.

O mockea la interfaz o instancia una clase anónima si quieres crear un Stub:

Los Stubs proporcionan respuestas a llamadas hechas durante el test, normalmente sin responder a nada fuera de lo programado para el test.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(/* ... */)
 );
 // O
 myBusinessLogic = new MyBusinessLogic(
 new FakeDependency(),
 new ConcreteDependency(/* ... */)
 );
 // ...
 }
}

Donde FakeDependency es una implementación concreta de DependencyInterface con “datos/implementación falsos” ya preparados que solo es útil para propósitos de testing.

3. Llama al método de esa clase proporcionando la entrada deseada.

La salida será determinada por el estado inicial de la clase de lógica de negocio que queremos testear MÁS los argumentos de entrada que estamos usando.

input = new Input(/* ... */);
returnType = myBusinessLogic.applySomeLogic(input);

4. Afirma la salida con el valor esperado.

Del paso 1 necesitas saber qué quieres. Aplica la(s) aserción(es) ahora.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface::class),
 new ConcreteDependency(/* ... */)
 );

 input = new Input(/* ... */);
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

5. Puede que quieras afirmar diferentes valores esperados.

Puedes proporcionar fácilmente diferentes argumentos a tu lógica de negocio ya sea a través de la construcción de la lógica o diferentes argumentos dados. Para hacerlo, usa la anotación @dataProvider. El método “dataProvider” debe ser público y devolver cualquier iterable.

final class MyBusinessLogicTest extends TestCase
{
 /** @dataProvider providerApplySomeLogic */
 public function test_apply_some_logic(
 array concreteMapping,
 string argInput,
 string expectedValue
 ): void {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(concreteMapping),
 /* ... */
 );

 input = new Input(argInput, /* ... */);

 actual = myBusinessLogic.applySomeLogic(input);
 assertEquals($expectedValue, actual.getProperty());
 }

 public function providerApplySomeLogic(): Generator
 {
 yield [
 'concreteMapping' => ['key' => 'value'],
 'argInput' => 'something',
 'expectedValue' => 'expected-value-A',
 ];

 yield [
 'concreteMapping' => ['key2' => 'value2'],
 'argInput' => 'something-else',
 'expectedValue' => 'expected-value-B',
 ];
 }
}

Por último: limpia lo que hiciste.

Sí, limpia los tests. Merecen estar tan limpios como tu código de producción. De lo contrario, se pudrirán con el tiempo y ¡permanecerán sucios para tus compañeros y tu yo futuro!

Por ejemplo, puedes aplicar el refactoring extract method para mover los detalles de implementación (de la creación de los diferentes objetos) y mantener el mismo nivel de abstracción mientras lees el código del test.

myBusinessLogic = this.createBusinessLogic(concreteMapping);
input = this.createInput(argInput);
actual = myBusinessLogic.applySomeLogic(input);
assertEquals(expectedValue, actual.getProperty());

Por supuesto, todo depende del contexto. ¿Realmente tiene sentido extraer a un método privado createBusinessLogic() o incluso createInput()? Bueno, eso depende de ti. Depende del número de líneas y, lo más importante, del nivel de abstracción que pertenece a ese contexto.

Solo recuerda: mantén tus métodos pequeños.

Ahora puedes refactorizar el código de producción que cubriste con tests sin ese miedo a romperlo.

Todo junto

El código legacy es código sin tests

Por supuesto, hay mucho más que aprender sobre testing y trabajo con código legacy. De hecho, especialmente cuando tratamos con código legacy, encontrarás situaciones donde el código está acoplado de alguna manera que podrías querer mockear tus clases concretas porque no hay interfaz (todavía) para ello.

Este libro te presenta muchas técnicas sobre cuándo, por qué, dónde y cómo puedes aplicar estos cambios.

Cuando trabajas con código necesitas retroalimentación. La retroalimentación automatizada es la mejor. Por lo tanto, esto es lo primero que necesitas hacer: escribir los tests.

Primero, añade tests, luego haz tus cambios.

Cambia la menor cantidad de código posible para poner los tests en su lugar con la receta:

Identifica “puntos de cambio” para romper las dependencias de tu código.
Rompe las dependencias.
Escribe los tests.
Haz tus cambios.
Refactoriza.

Advanced Web Application Architecture

2020-08-16T00:00:00+00:00

Este libro te ayuda a poner en forma tus aplicaciones web. Trae muchas técnicas para desacoplar tu código de la infraestructura (el framework, la base de datos, etc.).

La Parte 1 presenta patrones de diseño para separar código de negocio e infraestructura. La Parte 2 muestra cómo estos patrones encajan con conceptos arquitectónicos como capas, puertos y adaptadores (arquitectura Hexagonal). El libro cierra con estrategias de testing y decisiones de diseño.

Lo que aprenderás

Separar código mezclado en código de negocio e infraestructura usando patrones.
Dividir tu código en capas con una distinción clara entre puertos y adaptadores.
Testear aplicaciones desacopladas.

Compra el libro: https://leanpub.com/web-application-architecture

Patrones de diseño para modernizar código legacy

Strict Types en PHP

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

En diciembre de 2015, PHP 7 introdujo las declaraciones de tipos escalares y la bandera strict types. ¿Qué es esto?

Lo bueno de declarar un archivo PHP como estricto es que se aplica solo al archivo actual. Asegura tipos estrictos en ese archivo, pero no afecta al resto del proyecto. Puedes migrar de código no estricto a estricto paso a paso, especialmente en archivos o proyectos nuevos.

Para habilitar el modo estricto, coloca una directiva declare al principio del archivo. La estrictez de tipado para escalares se configura por archivo. Esta directiva afecta tanto a los parámetros como al tipo de retorno de las funciones.

Strict types afecta la coerción de tipos

Usar type hints sin strict_types puede causar bugs sutiles.

Sin strict types, int $x significa “$x debe ser coercionable a int”. Cualquier valor coercionable a int pasaría:

un int (42 -> 42)
un float (13.1459 -> 13)
un bool (true -> 1)
un null (null -> 0)
un string con dígitos al inicio (“15 Trees” -> 15)

Con strict_types=1, le dices al motor que int $x significa que $x debe ser un int real, sin coerción. Tienes la seguridad de que recibes exactamente lo que se pasó, sin conversiones ni pérdida de datos.

¿A quién le importa esta línea?

declare(strict_types=1); es más para el lector que para el escritor. Le dice explícitamente:

Los tipos en este archivo se tratan de forma estricta.

‘strict_types=1’ es más para el lector que para el escritor

El escritor solo necesita mantener esa estrictez mientras escribe. Pero como escritor, deberías preocuparte por tus lectores. Eso incluye a tu yo futuro.

Referencias

El Arte del Refactoring

2020-06-28T00:00:00+00:00

Si ves algo, en el ámbito de tu tarea actual, que puede mejorarse fácilmente, mejóralo. Y si tienes alguna pregunta al respecto, pregunta.

¿Qué es el refactoring?

Refactoring significa mejorar tu código. Puede ser renombrar una variable, extraer líneas en un método privado, o separar responsabilidades de una clase en varias.

El refactoring demuestra que te importa lo que haces como profesional. Es un tema controvertido desde hace tiempo. Pero eso no debería frenarnos de mejorar la calidad del sistema.

¿Cuándo y cómo refactorizar?

Siempre. Dentro del ámbito de tu tarea actual, a menos que sea una tarea planificada específicamente para refactoring de arquitectura.

El refactoring debería ser parte del trabajo diario, no una tarea separada.

No necesitamos pedir permiso para refactorizar. ¿Acaso pedimos permiso para hacer nuestro mejor trabajo?

Para refactorizar bien, la intención debe estar clara. ¿Qué queremos lograr y cómo? El pair programming (o incluso el “pair thinking”) ayuda porque sincroniza dos cerebros y fomenta mejor comprensión mutua.

Refactorizar de forma colaborativa es fundamental en equipo. No debería ser tabú. Al contrario: ayuda a unificar objetivos y dirección de calidad del código.

Algunos consejos sobre el “cómo”

Buscamos mejora continua, pero…

Si tus cambios generan más ruido que ayuda, para. Piensa si valen la pena en el estado actual del sistema. Quizás no es el momento. Quizás estás contaminando el diff con cambios fuera del ámbito. O quizás es demasiado grande para tu tarea actual. En ese caso, mejor crear una tarea de seguimiento.
Si el refactoring es necesario antes de empezar tu tarea, hazlo primero.

Refactorizamos para aumentar productividad: código más legible es código más fácil de entender.

Testing

Necesitas un buen conjunto de tests cubriendo la lógica que vas a cambiar. Sin tests, refactorizar es arriesgado. Por lo general, cuanto más fácil es testear algo, más fácil es reemplazarlo o eliminarlo.

Puedes leer más sobre cómo el testing está relacionado con la calidad aquí.

¿Por qué hacerlo?

¿No querrías un sistema mejor con el tiempo?

El software no es como el vino: no mejora solo. Si quieres un sistema mejor, tienes que trabajar para conseguirlo.

Rompe la barrera del No

2020-06-12T00:00:00+00:00

Chris Voss pasó de patrullar las calles de Kansas City a ser el negociador principal de secuestros internacionales del FBI. Ahora enseña negociación en universidades de élite. Las técnicas de este libro las ha probado en todo tipo de situaciones y funcionan.

Aprendizajes

Negociar empieza por escuchar. Hay que hacer que la conversación gire en torno al otro, validar sus emociones y crear la confianza necesaria para hablar de verdad.
Usa el “espejo” (repetir las últimas palabras del otro) para generar empatía, mantener la conversación viva, ganar tiempo y hacer que el otro revele su estrategia.
La empatía táctica te ayuda a ver tanto los obstáculos emocionales como los caminos posibles hacia un acuerdo.
Etiquetar emociones (ponerles nombre) te acerca al otro sin necesidad de preguntar por cosas que desconoces.
Un “no” es una oportunidad. Te permite a ti y al otro aclarar qué quieren realmente, descartando lo que no.

Video resumen

Scrum

2020-06-10T00:00:00+00:00

Toda organización tiene que lidiar con entregar productos a tiempo y dentro del presupuesto. Da igual el tamaño.

Scrum te muestra cómo hacerlo. Te explica cómo definir lo que quieres lograr, cómo armar el equipo adecuado y cómo seguir el progreso hasta completar el proyecto con éxito.

Clases Final en PHP | Java | Cualquiera

2020-06-06T00:00:00+00:00

Contratos claros, efectos secundarios aislados, testeabilidad, baja complejidad y carga cognitiva, fluidez del código y confianza en ti mismo.

Motivación

Reduce la visibilidad al mínimo

Cuando una clase es final, no puede ser extendida. Esto la hace más legible y te asegura que la lógica está limitada a esa clase.

Fomenta “composición sobre herencia”

El Principio Abierto-Cerrado dice: abierto para extensión, cerrado para modificación.

Si decides crear una herencia (por una buena razón, de la que deberías ser consciente), simplemente quita final y listo.

Cuando por defecto no puedes extender una clase, te fuerzas a pensar en composición en lugar de herencia.

¿Por qué esta clase no es final?

Si preferimos composición sobre herencia, deberíamos evitar la herencia tanto como sea posible. La herencia se usa mal a menudo en POO.

Un concepto mal entendido

Cuando nos enseñaron POO, normalmente empezamos con el ejemplo clásico de herencia.

Pero cuando Alan Kay creó Smalltalk, la herencia no era el concepto principal. Lo principal era el paso de mensajes: enviar mensajes a objetos que encapsulan datos y lógica, cambiando comportamiento mediante diferentes objetos. Eso es composición. La herencia se hizo tan popular que terminó eclipsando a la composición.

Beneficios

Contratos claros. Usar interfaces te obliga a pensar en comunicación entre objetos.
Código aislado, sin efectos secundarios. Inyectar solo interfaces elimina efectos secundarios molestos.
Testeabilidad. Mockear interfaces es muy fácil.
Complejidad manejable. Todo aislado significa menos cambios en cascada.
Baja carga cognitiva. Menos complejidad, más foco en lo importante.
Flexibilidad. Sin acoplamiento innecesario, mover código es más fácil.
Confianza. Testear código aislado te da seguridad para cambiarlo.

Composición sobre herencia

Si necesitas reconfigurar un objeto, cambiar partes de un algoritmo o reescribir parte de la implementación, considera crear una nueva clase en lugar de sobreescribir una existente.

¿Necesitas representar una jerarquía donde las subclases sustituyen a las clases padre? Esta sería la situación clásica donde podrías usar herencia. Aun así, el resultado suele ser mejor si heredas de interfaces abstractas, no de clases concretas.

Qué hacer en su lugar

Usa interfaces para definir contratos entre clases.
Usa clases finales para implementar esas interfaces.
Usa composición (inyección de dependencias por constructor) para unir las piezas.

Interfaces -> Clases finales -> Composición

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

La Llamada de Cthulhu

2020-05-18T00:00:00+00:00

Un horripilante monstruo submarino despierta y amenaza a la humanidad. Este relato dio origen a toda una mitología: los Mitos de Cthulhu, con el poder de sembrar terror incluso en los corazones de los Grandes Antiguos.

La Metamorfosis

2020-05-16T00:00:00+00:00

Una novela corta de Franz Kafka, publicada en 1915. Es una de las obras fundamentales de la ficción del siglo XX y se estudia en todo el mundo occidental.

La historia comienza con Gregor Samsa, un viajante de comercio, que despierta convertido en una criatura monstruosa parecida a un insecto. Kafka nunca explicó la causa de la transformación. El resto de la novela trata sobre los intentos de Gregor de adaptarse a su nueva condición mientras lidia con ser una carga para su familia, que siente repulsión por la criatura en que se ha convertido.

1984

2020-05-13T00:00:00+00:00

Una de las novelas más populares de Gran Bretaña. Está ambientada en una sociedad aterrorizada por una ideología totalitaria propagada por El Partido.

Winston Smith trabaja para el Ministerio de la Verdad en Londres, ciudad principal de Franja Aérea Uno. El Gran Hermano observa desde cada cartel. La Policía del Pensamiento descubre cada acto de traición. Cuando Winston encuentra el amor con Julia, descubre que la vida no tiene que ser aburrida y gris. Despierta a nuevas posibilidades. A pesar de los helicópteros policiales que sobrevuelan, Winston y Julia empiezan a cuestionar al Partido y se sienten atraídos hacia la conspiración. Pero el Gran Hermano no tolera la disidencia, ni siquiera en la mente. Para quienes tienen pensamientos originales inventaron la Habitación 101…

La novela acuñó palabras y frases que aparecen regularmente en la cultura popular: “Gran Hermano”, “crimental”, “doblepensar” y “neolengua”.

El Arte del Testing: Donde el Diseño se Encuentra con la Calidad

2020-04-07T00:00:00+00:00

¿Por qué considerar el testing parte de tu desarrollo diario? Porque está directamente vinculado a la calidad del software.

No voy a explicar las diferentes técnicas de testing ni las diferencias entre tests unitarios, de integración, funcionales o end-to-end.

Me sigue sorprendiendo la falta de experiencia con testing en el mundo del software. Hay una ignorancia generalizada sobre buenas prácticas. Si has trabajado en varios proyectos y equipos, seguro que lo has visto.

Testing de software

Algunos patrones horribles que he visto (y hecho):

Testear por testear: testear cada archivo individual, confundiéndolo con una “unidad”.
Mockear cada clase, anulando la implementación real y creando comportamiento falso. Esto da una falsa sensación de cobertura.
Acoplar código de producción con tests por todas partes. Imposible cambiar nada sin romper tests, aunque la funcionalidad siga funcionando.
No testear nada porque “ya funciona, ¿para qué perder más tiempo?”

Una razón principal del testing es verificar el comportamiento esperado del software. Pero el testing puede (y debería) ser mucho más que eso.

Diseño de software

El diseño de software abarca desde algoritmos hasta arquitectura. Aunque estos dos niveles tienen necesidades distintas, comparten patrones comunes. Por ejemplo, el testing:

Si es fácil de testear, probablemente será debido a un buen diseño.

Calidad del software

Medir la calidad es difícil. Hay muchas métricas a considerar. Aun así, seguro que podemos estar de acuerdo en esto:

Si aspiras a la calidad en tu software, mejor busca un buen diseño.

Testear significa “probar”. ¿Cuántas veces hemos abandonado tests por la complejidad de probar cierta lógica?

El arte del testing consiste en usar los tests para contribuir al resultado final. Si usamos el testing a nuestro favor, según el contexto, mejoraremos la calidad del producto.

Por tanto, el testing no solo verifica comportamiento. También guía el software hacia un mejor diseño.

¿Deberíamos testear todo? Depende del contexto. Habrá situaciones donde los tests no aporten beneficio. Aun así, escribe código como si fuera a ser testeado.

El código testeable tiende a un mejor diseño y, por lo tanto, a mejor calidad.

Gestión de Alto Rendimiento

2020-04-03T00:00:00+00:00

Un clásico de Silicon Valley. El ex presidente y CEO de Intel comparte su perspectiva sobre cómo construir y dirigir una empresa. Es un manual práctico para navegar escenarios de negocios reales y un manifiesto de gestión que puede cambiar tu forma de trabajar.

Secciones

Apalancamiento gerencial
Formación
Motivación
Reuniones y decisiones
Reuniones uno a uno
Delegación y madurez relevante para la tarea
KPIs
Evaluaciones de desempeño
Entrevistas
Promociones y reciclaje

Un buen resumen de las conclusiones por Marc Koenig:

El Camino del Manager

2020-03-26T00:00:00+00:00

Lecciones clave

Las reuniones uno a uno con tu manager son esenciales para una buena relación laboral.
El trabajo de un manager es facilitar que su equipo haga las cosas, creando entornos donde el trabajo pueda fluir.
Mentorear a los nuevos empleados es crítico.
El feedback funciona mejor cuando lo combinas con coaching.
Es poco realista pensar que puedes o debes proteger a tu equipo de todo.

Agile Limpio

2020-03-12T00:00:00+00:00

Clean Agile viene de Uncle Bob, uno de los padres fundadores de Agile. Fue una de las diecisiete personas que escribieron el Manifiesto Ágil en 2001.

El libro trata sobre Agile: lo que fue, lo que es y lo que será. Es un regreso a lo básico que cubre la historia de Agile, qué lo motivó y qué ha pasado desde entonces. Cubre las prácticas básicas y las compara con la variedad actual de procesos ágiles.

Programación Extrema Explicada

2020-03-05T00:00:00+00:00

Definición

Extreme Programming (XP) es un framework ágil que busca producir mejor software y mejor calidad de vida para el equipo de desarrollo. Es el más específico de los frameworks ágiles en cuanto a prácticas de ingeniería.

Valores

Los cinco valores de XP son comunicación, simplicidad, feedback, coraje y respeto.

Comunicación

El desarrollo de software es un deporte de equipo. Depende de la comunicación para transferir conocimiento entre los miembros. XP enfatiza la comunicación cara a cara, preferiblemente con una pizarra a mano.

Simplicidad

Simplicidad significa “¿qué es lo más simple que funcionará?” El objetivo es evitar el desperdicio y hacer solo lo necesario. Mantener el diseño lo más simple posible facilita el mantenimiento y la revisión. También significa abordar solo los requisitos que conoces ahora, sin intentar predecir el futuro.

Feedback

Con feedback constante sobre el trabajo previo, los equipos identifican áreas de mejora y ajustan sus prácticas. El equipo construye algo, recoge feedback sobre el diseño e implementación, y ajusta el producto en consecuencia.

Coraje

Kent Beck definió el coraje como “acción efectiva ante el miedo”. Necesitas coraje para:

Plantear problemas organizacionales que reducen la efectividad del equipo.
Dejar de hacer algo que no funciona y probar algo diferente.
Aceptar y actuar según el feedback, aunque sea difícil de escuchar.

Respeto

Los miembros del equipo necesitan respetarse mutuamente para comunicarse bien, dar y recibir feedback de forma constructiva, y trabajar juntos en diseños y soluciones simples.

Principios

Humanidad

Los seres humanos desarrollan software. El libro menciona 5 cosas que necesitan los desarrolladores para crecer: seguridad básica, logro, pertenencia, crecimiento e intimidad.

La magia de los grandes equipos es que, una vez que desarrollan confianza, sus miembros se sienten libres de ser más ellos mismos.

Economía

El software cuesta dinero. Alguien pagó o invirtió en él.

Asegúrate de que lo que haces tenga valor de negocio y sirva a sus necesidades. Resolver primero la necesidad más prioritaria maximiza el valor del proyecto.

Cuanto antes el software genere dinero, antes el desarrollo será valioso.

Beneficio Mutuo

El beneficio mutuo en XP busca actividades que beneficien a todos los involucrados: a mí ahora, a mí después, y a los clientes.

El libro presenta 3 formas de comunicarte con el futuro:

Escribo tests automatizados que me ayudan a diseñar e implementar hoy. Los dejo para que los futuros programadores también los usen.
Refactorizo para eliminar complejidad accidental. Menos defectos y código más fácil de entender para quien venga después.
Elijo nombres de un conjunto coherente de metáforas. Acelera mi desarrollo y hace el código más claro para nuevos programadores.

Auto-Similaridad

Copiar la estructura de una solución a un nuevo contexto.

Por ejemplo, la estructura básica del desarrollo: escribes un test que falla y luego lo haces funcionar. Esta estructura opera a todas las escalas. Ojo: es un buen comienzo, pero no siempre funciona.

Mejora

Haz lo mejor que puedas hoy, pero esfuérzate por hacerlo mejor mañana. XP brilla aquí: se trata de mejorar siempre.

Pon la mejora a trabajar sin esperar la perfección. Encuentra un punto de partida, comienza y mejora desde ahí.

Diversidad

Los equipos necesitan personas de diferentes orígenes, experiencias y actitudes. Así tienen diferentes formas de pensar y resolver problemas.

Los programadores deberían trabajar juntos en el problema y valorar ambas opiniones.

Reflexión

Los buenos equipos reflexionan después de la acción, regularmente. Piensan sobre por qué y cómo están trabajando.

¿Por qué tuvimos éxito? ¿Qué deberíamos seguir haciendo?
¿Por qué fallamos? ¿Qué podemos hacer mejor?

Aunque todo parezca perfecto, siempre hay espacio para mejorar:

¿Por qué las cosas parecen perfectas? ¿Qué hacemos bien? ¿Qué podemos mejorar?

Flujo

El flujo en desarrollo de software es entregar valor constante participando en todas las actividades simultáneamente. No entregues software en grandes porciones. Despliega incrementos más pequeños con más frecuencia.

Oportunidad

Aprende a ver los problemas como oportunidades para aprender y mejorar.

Parte de ser extremo es elegir conscientemente transformar cada problema en una oportunidad: para el crecimiento personal, profundizar relaciones y mejorar el software.

Redundancia

Los problemas difíciles deberían resolverse de múltiples maneras.

El costo de la redundancia se paga con creces por los ahorros de evitar un desastre.

Fracaso

A veces no sabes qué camino tomar. Prueba las ideas que tienes, aunque fallen. El fracaso no es desperdicio, sino aprendizaje.

Cuidado con la trampa de discutir o pensar eternamente sin hacer nada.

Cuando no sabes qué hacer, arriesgarte al fracaso puede ser el camino más corto hacia el éxito.

Calidad

Los proyectos no van más rápido bajando la calidad. Suele ser al revés. Resulta en entregas más tardías y menos predecibles por el tiempo dedicado a corregir bugs.

Aumentar la calidad suele resultar en entregas más rápidas.

La preocupación por la calidad no es excusa para la inacción. Si no conoces una forma limpia de hacer algo que hay que hacer, hazlo lo mejor que puedas. Si conoces una forma limpia pero tomaría demasiado tiempo, haz el trabajo tan bien como el tiempo te permita. Resuélvelo de forma limpia después.

Pasos Pequeños

Da pasos pequeños. Hacer grandes cambios de golpe es peligroso. Las personas y equipos pueden dar muchos pasos pequeños y parecer que avanzan rápido.

Los pasos pequeños reconocen que su sobrecarga es mucho menor que cuando un equipo retrocede desperdiciando cambios grandes abortados.

Responsabilidad Aceptada

La responsabilidad no puede asignarse; solo puede aceptarse. Si alguien intenta darte responsabilidad, solo tú puedes decidir si la aceptas o no.

Prácticas

Se pueden hacer de forma aislada, pero muchos equipos han descubierto que algunas prácticas refuerzan a otras. Hacerlas juntas elimina los riesgos típicos del desarrollo de software.

Sentarse Juntos

La comunicación es uno de los cinco valores de XP. Haz que tu equipo se siente junto en el mismo espacio sin barreras como paredes de cubículos.

Equipo Completo

Incluye personas con todas las habilidades y perspectivas necesarias para que el proyecto tenga éxito.

Espacio de Trabajo Informativo

Configura el espacio para facilitar la comunicación cara a cara, permite algo de privacidad cuando la necesiten, y haz el trabajo transparente para el equipo y las partes interesadas.

Trabajo Energizado

Eres más efectivo en el desarrollo de software cuando estás enfocado y libre de distracciones.

Programación en Parejas

Todo el software de producción lo desarrollan dos personas en la misma máquina. Dos cerebros y cuatro ojos son mejores que un cerebro y dos ojos. Obtienes revisión de código continua y respuestas más rápidas a problemas que podrían bloquear a una persona sola.

Los equipos que usan programación en parejas descubren que mejora la calidad sin tomar el doble de tiempo. Resuelven problemas más rápido y se mantienen más enfocados, escribiendo menos código para lograr lo mismo.

Los programadores en pareja:

Se mantienen mutuamente en la tarea.
Hacen lluvia de ideas sobre mejoras al sistema.
Clarifican ideas.
Toman la iniciativa cuando el compañero está atascado, reduciendo la frustración.
Se hacen mutuamente responsables de las prácticas del equipo.

La programación en parejas es un diálogo entre dos personas programando simultáneamente (analizando, diseñando y probando) e intentando programar mejor.

Si necesitas privacidad y tiempo para trabajar en una idea, adelante. Necesitamos tanto compañía como privacidad. Rota parejas frecuentemente y toma descansos: el pairing puede ser agotador, pero es gratificante.

Historias

Describe lo que el producto debería hacer en términos significativos para clientes y usuarios. Son descripciones cortas de cosas que los usuarios quieren hacer. Sirven para planificar y como recordatorios para conversaciones más detalladas.

Dale a las historias un título corto y una descripción. Escríbelas en tarjetas y ponlas en una pared visible.

En XP las historias se estiman muy temprano. Esto hace que el equipo piense en cómo obtener el mayor retorno de la pequeña inversión.

Ciclo Semanal

El Ciclo Semanal es una iteración. El equipo se reúne el primer día de la semana para reflexionar sobre el progreso. El cliente elige las historias que quiere entregar esa semana, y el equipo determina cómo abordarlas.

La idea es producir algo para mostrar al cliente y obtener feedback.

Build de Diez Minutos

El objetivo es construir automáticamente todo el sistema y ejecutar todos los tests en diez minutos.

Integración Continua

Los cambios de código se prueban inmediatamente al añadirse al código base. El beneficio: detectas y corriges problemas de integración antes.

Requiere disciplina extra y depende mucho del Build de Diez Minutos y el Desarrollo Test-First.

Programación Test-First

Escribe un test automatizado que falle antes de cambiar cualquier código.

El libro menciona 4 problemas que aborda:

Expansión del alcance: Es fácil dejarse llevar y poner código “por si acaso”. Al declarar explícitamente lo que el programa debe hacer, te das un foco. Si quieres ese otro código, escribe otro test después.
Acoplamiento y cohesión: Si es difícil escribir un test, tienes un problema de diseño, no de testing. El código débilmente acoplado y altamente cohesivo es fácil de probar.
Confianza: Es difícil confiar en el autor de código que no funciona. Al escribir código limpio que funciona y demostrar tus intenciones con tests, das a tus compañeros razones para confiar en ti.
Ritmo: Es fácil perderse horas programando. Con test-first, siempre sabes qué hacer: escribir otro test o hacer que el test roto funcione. Se desarrolla un ritmo natural: test, código, refactorizar, test, código, refactorizar.

Diseño Incremental

Invierte en el diseño del sistema todos los días.

Haces un poco de trabajo inicial para entender el diseño general, y luego profundizas en los detalles cuando entregas características específicas.

Este enfoque reduce el costo de los cambios y te permite tomar decisiones de diseño basándote en la información más actual.

Roles

XP especifica prácticas, pero no establece roles específicos. Según la fuente, o no hay orientación, o hay descripciones de cómo los roles tradicionales se comportan en proyectos XP.

El Cliente

Responsable de tomar todas las decisiones de negocio del proyecto.

Se asume que es una sola persona, pero la experiencia muestra que una persona no puede proporcionar toda la información de negocio de un proyecto.

El Desarrollador

Como XP no necesita definición de roles, todos (excepto el cliente y un par de roles secundarios) se llaman desarrolladores. Son responsables de realizar las historias identificadas por el Cliente.

El Rastreador

Su propósito es llevar el seguimiento de métricas relevantes para rastrear el progreso e identificar áreas de mejora.

El Coach

Usualmente un consultor externo (o alguien de otra parte de la organización) que ha usado XP antes. Ayuda a mentorear al equipo en las prácticas XP y a mantener la autodisciplina.

¿Qué es XP? (en 2 min)

Tech Talk de Kent Beck: XP 20 años después

Symfony 5

2020-02-20T00:00:00+00:00

Escrito por el creador de Symfony, este libro presenta un enfoque práctico para desarrollar aplicaciones web con Symfony 5: desde cero hasta producción. Si estás descubriendo Symfony por primera vez o quieres refrescar tus conocimientos, esta guía te da una introducción completa a las aplicaciones modernas con Symfony.

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

Trabajando con código legado

2019-07-01T00:00:00+00:00

¿Qué es código legacy?

El código legacy es simplemente código sin tests.

Beneficios de los tests

El comportamiento es clave para entender los beneficios del testing:

El comportamiento es lo más importante del software. Los usuarios dependen de él. Les gusta que añadamos funcionalidad (si es lo que querían), pero si cambiamos o rompemos comportamiento del que dependen, pierden la confianza.

Cómo implementar tests en bases de código legacy

Para cambiar código necesitas tests. Pero para añadir tests muchas veces tienes que cambiar código.

El enfoque sugerido:

Identificar puntos de cambio.
Encontrar puntos de test.
Romper dependencias.
Escribir tests.
Hacer cambios y refactorizar.

Un término útil es “costura” (seam): un lugar donde puedes cambiar el comportamiento sin editar ese código directamente. Como la costura en la ropa, donde dos partes se unen. En software, estos lugares suelen tener interfaces bien definidas. Puedes aprovecharlos para cambiar implementaciones con inyección de dependencias o mocking en tests.

El Arte de la Guerra

2018-08-10T00:00:00+00:00

El texto tiene 13 capítulos, cada uno dedicado a un aspecto de la guerra. Se considera una obra definitiva sobre estrategia y táctica militar.

Es el más famoso de los Siete Clásicos Militares de China. Durante dos mil años ha sido el tratado militar más importante de Asia.

Ha influido en el pensamiento militar de Oriente y Occidente, en tácticas de negocios, estrategia legal y mucho más.

Citas

Aparenta debilidad cuando seas fuerte, y fortaleza cuando seas débil.
Si el enemigo es superior en fuerza, evítalo.
Ataca donde no esté preparado. Aparece donde no te esperen.
El general que pierde una batalla hace pocas consideraciones de antemano.
No hay país que se haya beneficiado de una guerra prolongada.
La excelencia suprema es romper la resistencia del enemigo sin luchar.
Si conoces al enemigo y te conoces a ti mismo, no temas cien batallas. Si te conoces pero no al enemigo, por cada victoria sufrirás una derrota. Si no conoces ni al enemigo ni a ti mismo, perderás siempre.
Puedes saber cómo conquistar sin ser capaz de hacerlo.
El estratega victorioso busca la batalla solo después de haber asegurado la victoria.
En la batalla solo hay dos métodos de ataque: el directo y el indirecto.
Un ejército puede marchar grandes distancias sin sufrir si va por territorio donde el enemigo no está.
Tendrás éxito si solo atacas lugares sin defensa.
Las tácticas militares son como el agua: el agua huye de lo alto y corre hacia abajo. En la guerra, evita lo fuerte y golpea lo débil.
Que tus planes sean oscuros como la noche. Cuando te muevas, cae como un rayo.
Reflexiona y delibera antes de actuar.
El general inteligente evita al ejército cuando su moral está alta y lo ataca cuando está cansado y quiere volver.
No avances cuesta arriba contra el enemigo ni te opongas cuando baja.
El arte de la guerra enseña a no confiar en que el enemigo no venga, sino en estar preparado para recibirlo.
Abre camino por rutas inesperadas. Ataca puntos desguarnecidos.
Quienes enfrentan la muerte pueden lograr cualquier cosa.
Para dirigir un ejército, establece un estándar de coraje que todos deban alcanzar.
Si es ventajoso, avanza. Si no, quédate donde estás.

Arquitectura Limpia

2018-06-04T00:00:00+00:00

Principios de diseño de código (SOLID)

Responsabilidad Única: una clase debe tener una sola razón para cambiar. O en su versión nueva: un módulo responde ante un solo actor.
Abierto-cerrado: abierta para extensión, cerrada para modificación.
Sustitución de Liskov: puedes reemplazar objetos por instancias de sus subtipos sin romper el programa.
Segregación de Interfaces: mejor muchas interfaces específicas que una general.
Inversión de Dependencias: depende de abstracciones, no de implementaciones concretas.

Principios de componentes

Cohesión de componentes

Equivalencia Reutilización/Liberación: las clases reutilizadas juntas deben liberarse juntas. Mismo número de versión y changelog adecuado.
Cierre Común: las clases que cambian juntas van juntas. Es el principio de responsabilidad única a nivel de componente.
Reutilización Común: no obligues a los usuarios a depender de lo que no necesitan. Segregación de interfaces a nivel de componente.

Acoplamiento de componentes

Dependencias Acíclicas: sin ciclos en el grafo de dependencias. Los ciclos fuerzan a liberar componentes juntos. Usa inversión de dependencias para romperlos.
Dependencia Estable: los componentes menos estables dependen de los más estables. Depende en dirección de la estabilidad.
Abstracciones Estables: los componentes estables deben ser abstractos. Ejemplo: una política de alto nivel que se extiende siguiendo abierto-cerrado.

Principios de arquitectura

Estableciendo límites

Los límites separan elementos de software: lo que importa de lo que no, lo de alto nivel de lo de bajo nivel. Si el código de alto nivel depende del de bajo nivel, los cambios se propagan hacia arriba. Ponemos un límite usando polimorfismo para invertir el flujo. Esto es el Principio de Inversión de Dependencias de SOLID.

Separando capas

Cuatro capas principales (aunque puede variar):

Entidades: objetos con lógica de negocio crítica. Ejemplo: un banco que no da préstamos a clientes sin cierta puntuación crediticia. Se comparten entre aplicaciones de la empresa.
Casos de uso: reglas de negocio específicas de la aplicación. Ejemplo: la secuencia de pantallas para hacer una transferencia.
Adaptadores de interfaz: gateways, presenters, controllers. Aquí va la arquitectura MVC de la GUI y la transformación de datos entre base de datos y casos de uso.
Frameworks y drivers: frameworks web, base de datos, la vista de MVC.

Capítulo 29: Julio, 2017

2017-07-01T00:00:00+00:00

No hablo de autoayuda

No pretendía escribir un libro de autoayuda, sino más bien hacer de la escritura una de mis herramientas más populares con la que pudiera ayudarme a organizar la razón y los sentidos.

No hablo de autoayuda, sino más bien de equilibrio entre la cordura y la locura. La prudencia que debemos considerar, independientemente de nuestros diferentes contextos, no puede flaquear ante el desequilibrio emocional que pudiéramos tener presente.

Adaptación a la transparencia, a la crudeza que sin previa advertencia nos desconcierta sin paños calientes. Me refiero a la inestabilidad emocional que necesita ser reparada.

Recuerdo olvidado: sueño donde el tiempo parecía soplarnos en la nuca y de la mano de un temor constante a la muerte. Hermano mayor solitario, emigrante desplazado. Ideas claras, sentimientos de superación diaria; no querer ser normal por necesidad. Por encima del bien y del mal con memorias olvidadas. Lo más importante será dejar huella y adaptarnos —o habremos muerto—.

Recuerdo ambicioso, de renuncia y denuncia a la idea opuesta del nosotros. Ironías de la vida, como incansables pensamientos que dicen mucho de ti. Juventud, imperdonable religión. Se hizo más notorio en la montaña, cuando saborear el odio a Dios no bastó. Es tiempo de hablar de nuevo. Tantas constantes, tanto desconocimiento para al final no ser conscientes ni tan siquiera de qué estamos perdiendo. ¿Quién nos recordará? Será sólo cuestión de tiempo. Lo más difícil será entendernos con otros ojos. Sólo se vive una vez. El futuro pasará a ser parte de nuestros dulces recuerdos junto a nuestra inocente juventud.

No quiero hablar de autoayuda, sino de nuestra falsa libertad si no vivimos ocupados de nuestras vidas. Buenos hábitos que nos indiquen el valor de la verdad, como nuestra tendencia a desenmascarar la mediocridad.

Este libro termina no sin antes agradecer vuestra compañía. No sin antes desear leernos de nuevo de aquí a muchos años para ver entonces en quién nos hemos convertido. Y esbozar la sonrisa que nos merezcamos.

Trabaja. Quiere. Sueña. Sonríe.

No hablo de autoayuda, sino de terminar para comenzar todo con los ojos en un recuerdo.

Capítulo 28: Junio, 2017

2017-06-01T00:00:00+00:00

Percepciones

No se trata de esperar al momento de encontrarnos con nuestra vida resuelta, sino de resolver nuestra vida, día tras día, de forma que hayamos creado dicha rutina para nuestra excelencia.

«Somos lo que hacemos repetidamente. Por lo tanto, la excelencia», dijo Aristóteles, «no es un acto, sino un hábito».

No es más que nuestra percepción aquélla que nos diluye la realidad frente a nuestros sentidos. Nuestro trabajo por fortalecer nuestros tenues pensamientos debería no estar tan infravalorado como al parecer la sociedad, desde tiempos pasados, muestra.

El desarrollo de nuestra razón, del éxito subjetivo, de los logros impagables, de la consecución de nuestros rendimientos, así como de nuestra realización personal… Somos un conjunto de partes intrínsecas, ¡de ahí la importancia de nuestra comprensión!

Nuestro rechazo hacia la excelencia accidental porque ésta perecerá en un corto plazo debido a nuestra tendencia hacia el adocenamiento. Nuestro trabajo, frente a las dificultades con las que diariamente nos encontramos, delimitará nuestra aprehensión a la vana e injusta realidad a la que ilusoriamente miramos en ocasiones con simpatía.

El apego a nuestro ser no puede ir sino ligado a nuestra idea de quiénes somos, de dónde y hacia dónde vamos. Somos sensaciones abstractas que, muy probablemente, tengan una explicación llanamente biológica desde nuestro más puro instinto de supervivencia. Nuestras ideas son meras emociones que evolucionan a escondidas conforme el paso de nuestras distintas experiencias.

Nuestra impresión (de lo que creemos entender por realidad) evolucionará impulsada por nuestras percepciones de los sucesos de verdad que seamos capaces de discernir, frutos de la crítica categórica, así como posiblemente equivocada. Pues ésta estará condicionada por todo suceso que, en raras ocasiones, seamos capaces de advertir conscientemente.

Nuestra inconsciencia juega un papel determinante, de forma exigente y severa, en el rumbo de nuestro sentido de la vida. Nuestro sentimiento de verdad lo deberíamos juzgar con total agudeza con nuestra capacidad cognitiva. Pues no deberíamos permitir (¡ni mucho menos creer!) que todo brote sea fruto de un azar sin autor más que alguna quimera.

Es por ello que debo recalcar de nuevo la importancia de la proyección de nuestro consciente para que de forma inconsciente terminemos donde habíamos proyectado escrupulosamente.

Capítulo 27: Mayo, 2017

2017-05-01T00:00:00+00:00

Mediocridad enmascarada

La religión como un paquete de hábitos preestablecidos, donde la voluntad de poder se reduce al absurdo del simple seguimiento de la mediocridad, enmascarada por un conformismo hacia el consentimiento de la falta de perseverancia.

Donde la falta de constancia en aquello por lo que deberíamos esforzarnos no pasará obligada factura…, pues se nos «perdonará» y «todos entraremos al reino de los cielos». ¿No es, acaso, bondad infinita?

Hábitos encadenados en un inculto pasado donde la mediocridad era premiada con aparentes promesas consistentes para todos aquellos inconsistentes de voluntad.

Esperanza por parte de aquellos desesperanzados que necesitaban hábitos estables ¡en las medidas de sus mezquinas posibilidades!

No enmascaremos quiénes somos. ¡No queramos ser mediocres!

Tendencia

La vida no es más que hábitos. Es por ello que, cuando nos centramos en las cosas positivas, cuando nuestra mente está aspirando a la mejor versión de nosotros mismos, creamos una rutina que nos empuja hacia nuestro éxito. Por el contrario, ocurre lo opuesto cuando nuestras ideas están encapsuladas en pensamientos negativos, así como destructivos, haciendo de nuestra vida una costumbre hacia la mediocridad.

No será la primera vez que escuchamos afirmaciones como «Si tú hubieras estado en mi situación habrías hecho lo mismo», tratando de excusarse hacia sí mismo cuando se llega a ser consciente de la gravedad de algún hecho que se hizo sin sensatez. ¿Podríamos inventar, acaso, alguna excusa más burda y vulgar que la culpabilidad por la falta de nuestra responsabilidad en nuestro contexto? ¡De eso se trata!, ¡de trabajar nuestro entorno!, ¡de esforzarnos con él!

El diseño de nuestro viaje debería estar por encima de toda idea externa. Seremos tan fuertes como eduquemos a nuestra tendencia a serlo.

No tendremos más oportunidades para abrazar aquello una vez se transforme en imposible.

Capítulo 26: Abril, 2017

2017-04-01T00:00:00+00:00

El valor

«¿Cuánto valemos?», me preguntaba.
«¿Cuánto vales?», me respondía.

¿Qué es lo que verdaderamente definirá el valor de los valores?

La valentía,
el esfuerzo,
la efectividad,
el coraje,
la estimación,
el mérito,
la osadía,
el interés,

Así como la importancia de cada uno de nuestros momentos.

Las experiencias, los hábitos, las excursiones, los viajes…, los pequeños logros que concluyen en ayudarnos a prosperar en nuestros objetivos a corto, medio y largo plazo. ¡Comprobar, ensayar, estudiar, examinar la realidad de primera mano!

¿Qué puede haber más valioso que el mismo hábito de nuestra conquista, desde y hacia nosotros mismos? ¡Nada!

¡El hábito de nuestra conquista debería enfocarse —con máxima prioridad— en nosotros mismos!

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

Capítulo 25: Marzo, 2017

2017-03-01T00:00:00+00:00

La verdad

La verdad está en el conocimiento. Y el conocimiento dependerá siempre del contexto. Conocer la verdad no es más que conseguir relacionar el contexto con el conocimiento que se pretende afirmar como verdad.

En un contexto donde el conocimiento sólo puede ser adquirido de forma empírica, ¿qué es la verdad sino la aserción subjetiva por excelencia? En este contexto no teórico, ¿qué es la verdad sino la manifestación parcial de su comprensión?

Nuestro talento para discernir con exactitud la veracidad de una evidencia subjetiva es tan individual y personal que cuesta creer que realmente podamos alcanzar una verdad ideal de forma global.

Podríamos decir que la verdad es, sin embargo, la representación de nuestro estado contextual en relación con nuestras mentes, es decir: nuestro conocimiento.

Conforme vamos creciendo nuestras verdades se modelan, las afirmaciones parecen (y deben) cuestionarse, las evidencias necesitan mayores pilares que las sostengan y nuestra seguridad —en aquello que defendemos como verdad— debe quedar certificada. De lo contrario, los pilares caerán en cuestión de no mucho tiempo porque realmente no existen muchas afirmaciones que podamos asegurar como absolutas como nuestro tiempo y nuestra muerte.

Crecer nos debería enseñar el significado de la verdad, empezando por el sentido de la vida, la importancia de nuestros momentos y nuestro reflejo hacia los demás, así como a nosotros mismos. Lo cual significa que madurar es sólo cuestión de lo que estamos haciendo con nuestro conocimiento para entender mejor nuestro contexto y, por supuesto, aquello que estamos haciendo en nuestro entorno para expandir nuestra sabiduría.

Todo en esta vida depende de nosotros. Incluso la verdad, especialmente teniendo en cuenta que podría cambiar en cuestión de tiempo. Y con «nosotros» me refiero a nuestra entidad individual en su aislado contexto.

Será, por tanto, nuestra singular proyección aquélla que delimitará nuestras verdades.

Sin final

Historias que acompañan. Menudos años de discurso grabado. Libro nacido de ideas y bocetos sin final acercado que, sin embargo y como todo lo que empieza, debe terminar.

Los finales no tienen por qué ser tristes necesariamente aunque nuestros sentimientos no puedan, en ocasiones, evitar pensar lo contrario. El tiempo es el único responsable, así como la memoria es aquélla que combate el olvido.

Los recuerdos nos acercan al conocimiento residiendo en forma de experiencia. Virtuosismo enérgico como actividad diaria, no conformada con la simple subsistencia.

Exteriorizando la comunicación interna con cierta facilidad aparente. Como bien ya quedó dicho: «No es oro todo lo que reluce»; sólo intentaba ser consecuente.

Ejercicio de saneamiento lógico y personal; acentuando todo aquello donde pudiera expresarme abiertamente hacia mí mismo con, por qué no decirlo, ciertos miedos al principio por no saber ni cómo comenzar. Dejar de temer el estar equivocado al pensar demasiado antes y después de actuar.

Emprender un camino no por terminarlo, sino por el trayecto y todo lo que ello en sí mismo conlleva: el nacimiento de un inicio sin conocer necesariamente un final, sin tener por qué caducar si el cuidado fue el apropiado.

Aprendamos a ser como quien realmente desearíamos conocer el día de mañana. Y todos los finales evolucionarán a principios.

Capítulo 24: Febrero, 2017

2017-02-01T00:00:00+00:00

Nuestra vida

Es la sensación de haber perdido todo aquello que nos puede engañar de forma natural ante la completa percepción de nuestra realidad. ¿Qué es acaso haberlo perdido todo?

Es nuestro contexto el que determina la percepción hacia aquello que estamos juzgando. Jugando a su vez un papel más que importante, que no definitivo de forma expresa.

Considerar no pronunciarnos, no revelarnos ante nosotros, durante un excesivo periodo de tiempo. Sopesar la idea del no tener en cuenta nuestra observación hacia aquello que no podemos dejar de mirar: nuestra vida y nuestro tiempo: nuestros momentos y nuestro ser: a nosotros mismos.

No reflexionar sobre nuestras acciones, sobre la estela que estamos dejando —aunque sea de forma involuntaria—, sentenciará nuestro parecer, así como nuestro aprecio, a todo aquello que linde con su entorno. Todo lo que hagamos, por tanto, dejará un rastro: nuestro inmortal pasado, que es de forma inevitable parte de la causa, transformándonos de forma directa en la consecuencia en la que nos estamos convirtiendo.

Pues la estimación de nuestros valores arbitrará la resolución de los mismos. Cercando nuestra cordura y puntualizando aquello que disponga nuestra disposición. Si no nos estimamos, nuestros valores quedarán mermados en la posible timidez de la cobardía. Si no nos estimamos no podremos ser personas cabales ni libres. De lo contrario, al menos tendremos la oportunidad de serlo en la medida de nuestras posibles consideraciones.

Me refiero al olvido de nosotros:
a nuestro olvido por las mañanas al levantarnos,
a nuestro olvido en cada momento,
a nuestro olvido por las noches al acostarnos.

¿Qué es haberlo perdido todo cuando aún nos queda el desconcierto de la incertidumbre por descubrir? O simplemente disfrutar.

Reflexionar como método, como solución a la disconformidad diaria de la falta de sentimientos y no como hábito arbitrario sin responsabilidades y sin espera de frutos, pues ¿a quién le acabaría importando…?

No dejemos de meditar, de observar, de diagnosticar nuestras impresiones, de disfrutar reflexionando y de resolver nuestras sensaciones para apreciar mejor todo aquello que merece nuestra atención, nuestra comprensión, así como nuestro empeño: nuestra vida.

Hábitos

Reflexionar como método, como solución a la disconformidad diaria de la falta de sentimientos. Rutina para nuestro ser, habilidad para nuestra experiencia.

Hábitos que nos definen, nos determinan e incluso nos limitan en nuestra posible disconformidad. Desde nuestros más básicos instintos, pasando por los simples reflejos, hasta los más complejos que parezcan no quererse dejar domar.

Somos hábitos inconscientes que de forma consciente deberíamos aprender a entender y aceptar para poder superar y, con ello, mejorar. Pues toda aquella costumbre que nunca haya sido cuestionada no podrá jamás ser superada.

Habilidad como deseo, como práctica de nuestra maestría: ensayo y error para posteriormente adquirir inevitablemente sabiduría.

¿Dónde quedó nuestro hábito de nuestro día a día? El conocimiento es poder. Y el poder nos permitirá tener la libertad para elegir lo que realmente queremos para nosotros. Ser conscientes de nuestras rutinas y sus motivos nos permitirá escoger y, con ello, ser responsables de nuestros actos.

Ejercitar nuestra costumbre, nuestra praxis. Sentirnos útiles en nuestro sueño conciliado, prudentes con nuestro juicio así como consecuentes con nuestra madurez frente a lo verdaderamente serio.

Estudio de nuestro comportamiento, de nuestros intentos, de nuestras respuestas, de nuestra observación, del empirismo más allá de la mera teoría: pragmatismo para y con nosotros en nuestro día a día. Pues sobran las palabras cuando los hechos hablan por sí solos.

Capítulo 23: Enero, 2017

2017-01-01T00:00:00+00:00

Falsa libertad

Con tendencias entrópicas a las que la vida parece estar dispuesta por su culpa, por su falta de predisposición y por no poner en cuestión el quedarse desnuda por completo en un instante para percatarse de la “nada” por la que esta puede llegar a estar rodeada.

«Desnudar el alma» no es más que el proceso de la completa sinceridad desde y para nosotros. Un entendimiento puro es imposible a ojos de aquél que sea hipócrita por interés.

Actuar con la mano derecha esperando que la izquierda no se entere no es más que el acto más impuro que podríamos hacer a nuestra conciencia; condenados a perpetua por ello hasta que la vida —en su divina injusticia— dicte sentencia.

La comprensión máxima a la que el hombre extraordinario debe aspirar no puede quedar mermada por necedades absurdas e inconexas, donde las excepciones y excusas parecen ser las protagonistas, y los pilares de la razón y su sentido se ven nebulosos los días con viento favorable, cuando no en completa oscuridad.

Hipocresía es querer pensar como ridículos: por su sinsentido y sus notables incoherencias. Es querer mentir y denigrar nuestro poder y nuestra confianza. Es querer no servir de ejemplo con nuestros actos. Es contradecirnos para posteriormente ni decirnos que lo estamos haciendo mal. Es no atrevernos a ser como realmente quisiéramos, así como pensamos y «predicamos». Aquél que sirva de ejemplo que tire la primera piedra. ¿Ejemplos de qué?

La importancia de una conciencia limpia es fundamental para alcanzar la plenitud con la que ilusamente todos soñamos. Somos responsables de nuestros actos, así como de nuestras omisiones. Uno de nuestros principales problemas es que tendemos a omitir aquello de lo que somos consecuentes, ahí es cuando nuestra libertad, en nuestro mundo «justo», queda limitada sin aparente entendimiento por nuestra parte: eludir nuestras responsabilidades nos privará de autodeterminación, ¡pues falsa libertad es lo que tendremos!

Falsa realidad cuando creemos ser alguien sin serlo, sin autoridad ni derecho a ello. Sin pruebas que puedan certificar nuestra palabra. Seremos libres en proporción a nuestras responsabilidades. ¡A demostraciones me refiero! Pues no somos más que la representación presente de nuestra intención sincera de cara al futuro ligado, por encima de todo, a nuestro pasado.

Fingir vivir sin obligaciones en un mundo justo es, aparte de hipócrita, estúpido. Pues negarnos a ser conscientes del desorden que, día a día, nos rodea, es como querer no salir a ver el sol prefiriendo sombras y oscuridad en la cueva.

Es rechazo por mi parte a aquellos que tras escuchar el mito de la caverna pensaron: «Malditos ellos que mataron al que vió el sol, pues lo tomaron por loco cuando éste lo único que quería era compartir con sus prójimos la verdad tras la misma: la luz y el sol como evidencias». Aquéllos que se conformaban con las sombras y oscuridad, aquellos asesinos de la sinceridad y el progreso. Ellos no merecen mi respeto. A todos aquéllos que tras el mito muestran su descontento hacia algo que luego repiten en su cotidianidad con excusas vanas o suspiros engañosos; falsos testimonios y seducciones cancerígenas llenas de falsedad: hipocresía.

¿Libres para qué? ¿Libres para procurar una vida repleta de cinismos como algo natural? Cuando la verdad se trata con disimulos, con intereses subjetivos…, la libertad queda reducida a su mínimo sentido, pues nuestra libertad no es sólo nuestro margen de movimiento externo, sino también interno.

Seremos más libres cuanto más nos conozcamos y más nos pertenezcamos. Nuestra autodeterminación es fundamental para conocer nuestra voluntad de poder. Nuestra confianza, atrevimiento, osadía, intención, voluntad…: éstos serán los medidores de nuestro grado de libertad.

Vivir ocupados

No debemos vivir preocupados, sino ocupados y no descuidados de nosotros mismos.

Ocuparnos de nosotros el tiempo que haga falta con objetivo principal de encontrar aquello que realmente deseamos. ¿Qué podríamos desear acaso más que nuestra propia dedicación hacia aquello que realmente querríamos? Pues ¿quién en su sano juicio no desearía ocuparse de sí mismo para consigo? Me refiero al sano egoísmo de nuestro deber.

En busca de nuestra plenitud nos movemos con miedos, así como posibles recelos, de todo aquello que no queremos entender. Temores inciertos que nacen de desconciertos, pues nadie nació sabiendo cómo querer.

¡A nosotros, ansiosos de vida, me refiero!
¡No dejemos escaparnos tan fácilmente!
Basta hacer uso de nuestro consciente
para crear con ello nuestro sendero.

Mucho menos cuando uso de razón aún tengamos
aunque a veces parezca ser sólo inconsciente.
A los ciegos de actitud me refiero especialmente,
pues no es cierto que estemos atados de manos.

Lástima por los cegados de voluntad, empeñados en tropezar en la misma piedra una y otra vez. Pena por los obstruidos, aquéllos cuyo deseo tiende al no ser, compartiendo su misma sensación hacia el resto, que tiene que aguantarlos sea como fuere, infectando a cualquier persona en su medida de lo posible.

Solo disgusto y pena por todos aquellos que rechacen su poder, así como su deber de ser, pero, sobre todo, del querer ser. Amar nuestras pasiones no puede ir desvinculado de la ocupación de las mismas: existir con un sentido único que nos identifique ante el resto, que día a día contemplemos, debe ir ligado a la actividad de la misma sin caer en el intento de evasión, impidiendo que nuestra sinceridad se sincere con nosotros.

La verdad sea dicha: encontrar el equilibrio de nuestra ocupación por nosotros, nuestro primer cometido, es la base donde radican los cimientos de nuestro sentido. Es, por tanto, nuestra motivación hacia cualquiera de nuestras metas aquello que marcará de forma notable un antes y un después, en la medida de la seriedad que para nosotros mismos tengamos.

Sernos fieles de pensamiento y de obra para evolucionar cada día más, aspirando algún día a querer realmente ocuparnos de nuestra vida para llegar a ser quienes queremos ser.

La importancia

La misma disposición a la importancia del todo, de los momentos, así como de sus ausencias; consideración hacia aquello que nos rodea, así como a la nada que nos podría abordar en cualquier momento.

El interés hacia aquello que deberíamos valorar por encima de todo en ninguna magnitud medible. Me refiero a aquello que deberíamos considerar en auge hacia su plenitud como entidad trascendente desde la nada hacia el todo. Nuestra vida en sí misma y su proporción de envergaduras y tendencias tan dispares, abstractas y elocuentes como a sí misma se disponga.

La seducción retórica de su abstracción e idealización como aquello a lo que aspiramos sin recelos, pero sobre todo sin miedos más allá de los que las situaciones en sí mismas nos vayan presentando.

No habrá por qué temer a la meditación espontánea con aromas de veracidad, pues estará siempre esperándonos.

La magnitud del todo que tiende a la insignificancia, a la ignorancia por deseo, a la vacuidad de su sentido, a la frivolidad de su importancia.

La repercusión de nuestro interés, de la eficacia de nuestro alcance, de la magnitud de nuestro deseo, de la seriedad de nuestro compromiso…

«¿Cuánto valemos?» es la pregunta.
«¿Cuánto vales?» es la respuesta.

Capítulo 22: Diciembre, 2016

2016-12-01T00:00:00+00:00

Esclavo de la muerte

Tener la muerte tan presente día tras día, tan recurrente, nos es algo inevitable. Pues ser tan conscientes de que nuestro tiempo no es infinito debería hacernos plantear en qué queremos —o deberíamos querer— invertirlo.

Mi mayor temor es el dolor de cabeza que, repentino, a veces me asalta cuando intento conciliar el sueño. No hablo de dolores emocionales, sino físicos, pues, además de parecer aleatorios, podrían estar jugando por última vez sin posible oportunidad de réplica.

Esto fue lo que ocurrió y lo que podría volver a suceder: dolores de cabeza en la oscuridad que desemboquen en la incerteza por excelencia a la que todos tantísimo tememos: la muerte.

En especial en la distancia, donde no me tendría más que a mí mismo. Donde, de ocurrir alguna tragedia, no habría primeros en enterarse…, sólo segundos y terceros, pues estos primeros no podrían hacer más que sospechar y negar lo posiblemente ocurrido hasta que la verdad se torne inevitable.

El origen de la tragedia podría nacer en cualquier instante que, junto a la belleza de su incertidumbre, me desvela hasta nublar el resto de mis sentidos.

Desvelado por la muerte incluso durante el día. Ser testigo de la misma nada, así como de su aparente y ausente presencia.

Hambre de razón definida, de sentido lógico racional, de proyección consentida por nuestra razón. Sed de comprensión, de entendimiento, de impulso hacia aquello que nos realiza.

Miedo por esa esclavitud de aquello inevitable que terminará con toda oportunidad por ocurrir.

Singularidades

Singularidades complejas con uso de razón consecuente. Momentos temporales con proyecciones tan singulares.

Experiencias abstractas que no dejan de orbitar sobre sí mismas procurando evoluciones en las medidas de sus propios intereses.

Ideas que estallan y se desvanecen como simples chispas cuando éstas no se trabajan con disciplina hasta curtir su propia llama.

Falsa falta de oportunidad por no querer transformar desde la misma forma.

Directrices sin dirección aparente, habiéndolas más y menos consecuentes con sus responsabilidades.

Falta de principios que nos aísla de nuestro motivo y razón de ser. Carencia de argumentos que nos invita a creer aquello que no se sostendría.

Creencia en la carencia más atrevida. Rezo al insulto mejor interiorizado por la ignorancia. Cuentos dictadores para aquéllos que no se atreven a cuestionar.

La muerte como real juez determinante.

La educación

El problema de la educación es que no se enseña la importancia de las responsabilidades, así como el trasfondo que se debería ir adquiriendo a lo largo del tiempo. Educación ligada a la responsabilidad y, por supuesto, unida ésta a nuestra libertad.

Nuestra educación viene dada por la enseñanza de las repercusiones de nuestros actos. La falta de educación viene dada por la incorrecta enseñanza de lo que realmente merecemos cuando nuestras responsabilidades quedan olvidadas, cuando nuestras obligaciones quedan en un segundo plano y, sin embargo, nuestro premio es el mismo que el de aquéllos que tienen una correcta educación; es por tanto cuando surge la pregunta: ¿cuál es entonces la correcta educación?

La correcta educación es aquélla que enseña la grandeza de nuestros actos comenzando desde una perspectiva de superación personal: queriendo ser mejores que nosotros mismos día tras día.

Nuestras acciones deberían tener una reacción igual a lo que hacemos; deberíamos actuar como nos gustaría que con nosotros el mundo se comportase. Deberíamos prosperar como a nosotros nos gustaría ver a los nuestros prosperar. Deberíamos ser como aquella persona que nos gustaría realmente conocer.

Capítulo 21: Noviembre, 2016

2016-11-01T00:00:00+00:00

Dulces recuerdos

Paciencia y sosiego.

No es difícil darnos cuenta de que todo es continuo cambio, siempre y cuando queramos realmente ser partícipes de ello.

Sentir que todas estas aventuras, en todo este tiempo, no han sido más que fruto de la necesidad circunstancial en la que nos hemos visto rodeados. Y nosotros, intentando superar toda adversidad sin mayor guía que la dureza, así como espontaneidad, de aquélla que tanto nos sorprende días tras día: la misma vida. Sin lugar a dudas, seremos nosotros aquéllos que tendremos la última palabra sobre nuestro ser y sus decisiones para su posteridad.

Por aquellos recuerdos que aún nos persiguen y viajan con nosotros allá donde vayamos. Cuidarlos en la medida de su valor, alentarnos para mejorar junto a los mismos, pero sobre todo comprender que de ellos somos fruto el día de hoy, pero no necesariamente el día de mañana.

No descuidar nuestras aspiraciones, aquellos deseos que tanto anhelamos, aquella referencia que tanto pudiéramos echar en falta… Mirarnos y reconocernos sin necesidad de espejos. La realidad a veces parece tan distante y diferente a como nosotros creemos que debería ser, pues observarnos sin motivo nos alejará inevitablemente de nuestra esencia.

Memorias aún a la espera de su nacimiento. Sed de reflexión, pero sobre todo deseo de llegar a construir la mejor versión de nosotros mismos. Hasta el fin de nuestros días. Deseando para entonces una amarga despedida, pero inevitables y abundantes dulces recuerdos.

Incluso

Cuando los planes se tornan tan irreconocibles que incluso poder aceptarlos se vuelve todo un reto en su complejidad.

Admitir el porvenir incierto es tan complicado que incluso el mismo futuro se asustaría con sus imprevistos.

Sorpresas no tan gratas y tan inevitables que incluso a nuestro mismo destino alarmaría por su tan inadvertido y posible adocenado mañana.

Oportunidades ciegas que junto a versos indiscretos se sorprenden día tras día tras sus venturas, algunas tan incontrolables y otras tan repentinas que incluso dormir sin sueños, vivir sin aspiraciones, tiende a la normalidad disconforme. Yo soy esas oportunidades ciegas. Yo soy esos versos indiscretos.

Sospechas inseguras y alarmantes hasta que el momento llegue y la realidad sorprenda con crudeza firme —y seguridad inquebrantable— sin importar lo más mínimo nuestro posible descontento.

Discrepancia inevitable. Disconformidad frente a aquella situación que nos parece superar con demasiadas creces. Conmoción aún por asimilar.

Adaptarnos frente a todo aquello que aún esté por llegar. «Quien tropieza y no cae, adelanta terreno».

Nuestro mayor error

Los dos mayores errores humanos: la denigración religiosa y política a la que nos hemos conducido. Y digo dos, cuando podría decir uno; podríamos abstraer estas ramas, tan distantes como ligadas, en una única fantasía que vela por el bienestar de uno mismo.

¿Qué es la religión sino la utopía espiritual por excelencia?, no siendo concluyente, sino adaptativa conforme a las tendencias temporales, así como culturales, en las que como seres racionales hemos ido evolucionando. Y ¿qué es la política sino el ideal administrativo de lo público con el cual parece que estamos obligados a coexistir?, pues somos y seremos seres colectivos.

Tanto la política como la religión han ido siempre de la mano, en mayor o menor medida. Y no me refiero a que estén ligadas entre sí superficialmente, a pesar de que históricamente así haya sido. Incluso aunque hoy en día intentemos desvincularlas, este ligamiento va más allá de una aparente simple conexión.

La religión, como la política, son el reflejo del fracaso de nuestro intento por lograr entendernos como iguales. Es la evidencia más pura de nuestra impureza. Es el manifiesto de nuestra realidad, así como de nuestra falta de entendimiento hacia aquello que no es nosotros.

Tanto la religión como la política no son más que utopías inalcanzables entrelazadas entre sí. Sin un final evidente ni claro. Son el problema sin solución; la paradoja de su lógica, pues estaremos forzados a tener que lidiar con estos temas hasta el fin de nuestros días.

No estoy afirmando que tanto la política como la religión sean innecesarios sin sentidos. Declaro que estaremos equivocados en la afirmación del tener la razón en cualquier utopía. La política es necesaria: de ahí que sea el reflejo de nuestra falta de entendimiento. Así como la religión es también la evidencia de nuestro atraso como seres racionales.

La política, al fin y al cabo, vela —o debería hacerlo— por nuestro bienestar como seres colectivos. Sin embargo, la religión ha abusado de la ignorancia, de aquéllos que quisieron como de aquéllos que no tuvieron otras opciones.

Será, por tanto, nuestro mayor error cualquier creencia dispuesta —incluso predispuesta— en cualquier utopía.

Capítulo 20: Octubre, 2016

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

Entropía

Basta con un simple pensamiento para darnos cuenta de lo frágiles que pueden llegar a ser.

La entropía de nuestro ser tiende al desorden y al caos; basta con descuidarnos unos días para percatarnos de que la vida se nos escapa, en una lucha constante frente al posible desconcierto de nuestro día a día, con sus mayores y menores desafíos, así como sus presiones involuntarias.

Todo será, al fin y al cabo, una lucha frente a una entropía que tiende a la confusión y al enredo en sí misma. Todo debería consistir en nuestra eterna disputa contra nuestro desorden.

Todo sea para nuestro futuro, para cuando nos recordemos de nuevo en unos años con cariño y, por qué no, también con algo de anhelo. Desear sentirnos orgullosos de quiénes fuimos en días pasados. Sobre todo, sentirnos orgullosos de la estela que dejaremos frente a toda adversidad que nos provoque nuestra disimulada entropía.

El futuro

El futuro no será para los que planean continuamente ni para los que no se atreven a dar un paso al frente y encararse contra su misma persona, especialmente cuando ésta esté abrumada y sin razón de buscar esa motivación que parece no haber sido encontrada.

El futuro, por el contrario, será para aquellos que desarrollan su presente. Porque la motivación va y viene, pero la pasión nace, progresa y crece con nosotros.

El futuro no es más que nuestra recompensa por nuestro presente. Por supuesto que en la vida las sorpresas que ésta misma nos guarda dejan a veces mucho que desear, pero no nos estamos refiriendo a éstas en concreto. Es nuestra proyección lo que importa para el desarrollo de nuestro presente. Las influencias y perspectivas que nos hagan progresar como individuos serán las determinantes para nuestro crecimiento.

¿Qué puede haber más importante sino nuestra plenitud en nuestro desarrollo sincero como personas?

No dejemos que el mal tiempo nos impida ser nosotros. No dejemos de prosperar en la medida de nuestras posibilidades. Proyectemos hacia el mundo aquello que nosotros quisiéramos sentir; pues nosotros somos el mundo, pero, sobre todo, el futuro.

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.

Capítulo 19: Septiembre, 2016

2016-09-01T00:00:00+00:00

Solo se vive una vez

Solo se vive una vez, o al menos hasta ahí es donde podemos leer. Todos tenemos problemas, en mayor o menor medida, en mayor o menor grado, de importancias tan relativas como los intereses e intenciones que pudieran tras los mismos esconderse.

Mentirnos sobre nuestros pensamientos o, simplemente, sobre aquello que nosotros creemos entender por realidad hará que ésta no sea más que un engaño desde y hacia nosotros.

Desde un punto objetivo, podríamos afirmar que existe una realidad única para todos en la cual todos convivimos y compartimos sus recursos y bienes. Sin embargo, si tenemos en cuenta el contexto desde el que formulamos la pregunta «¿Qué es la realidad sino nuestra ilusión de la percepción de la misma?», no nos atrevemos a afirmar que existe una única realidad para todos, sino, más bien, que todos formamos, a partir de nuestras individuales percepciones, una realidad aparentemente común.

El mayor mal que podríamos causar al mundo, a la realidad tangible y a todo aquello práctico, así como pragmático, es y será la falta de seriedad en nuestra honradez hacia nuestra persona. Aquello que nos empequeñece es la carencia de lo esencial para con nosotros: nuestra lealtad. Aquello que nos hace grandes frente al mundo es la sobredosis de sinceridad que con nosotros diariamente deberíamos practicar.

De dificultades estuvo, está y por supuesto estará llena la vida. Pero, en contraposición a las mismas, las actitudes juegan el papel de nuestras proyecciones, de nuestra realización profunda, de nuestra percepción de la objetividad.

¿Qué es nuestra preocupación existencial sino el tema tabú por excelencia por su ya conocida ausente respuesta? Deberemos ser nosotros los que actuemos en todo momento. Nuestro rol nunca estuvo escrito. Ser los protagonistas será sólo cuestión de predisposición a serlo. ¡Predisposición sincera, insisto!

A nuestra aparente realidad no deberíamos rogarle ni tan siquiera confiar más de lo que nuestros ojos pudieran ver; pues en la duda de la misma existencia residirá, para todo aquél que la busque, la respuesta.

Jóvenes e inocentes

Qué jóvenes e inocentes hemos sido, simplemente, al creer que podríamos evadir la madurez que en realidad nos rodea. La preocupación, justificada en nuestro compromiso, irá ligada a nuestra seriedad en nuestra profesión. Entender que el aprendizaje es y será siempre algo continuo y unido a nuestra responsable prudencia.

Tantos errores hemos cometido y seguiremos cometiendo… que solamente con una continua mejora conseguiremos sentirnos realizados, pues habrá siempre tanto que renovar…

Contamos con unos tiempos tan limitados que lo aburrido no debería tener cabida; vivir desanimados será, por tanto, no vivir.

Aprender que entendernos no es algo fácil; no será, tampoco y en absoluto, algo de un día para otro. Sólo en la búsqueda del entendimiento podremos aprender del mismo.

Hoy nos deberíamos leer con otros ojos. Ojos renovados en el día de hoy, apuntando al triunfo del mañana incierto.

Ha sido este, verdaderamente, un camino hacia nuestra comprensión donde hemos aprendido muchas cosas juntos, recordado otras tantas y soñadas otras cuantas. Pero, sin duda alguna, una experiencia que merece no ser olvidada, al menos para nuestro recuerdo.

Terminando para comenzar

Terminando para comenzar de nuevo. Sonrío. He procurado jugar con las palabras de tantas formas posibles. He intentado alcanzar el límite de sus posibles conexiones y son tantas… Me leo de nuevo y disfruto; me hace sentir vivo.

¿Sabéis acaso qué es que se os ponga la piel de gallina al pensar en vuestro presente? ¿En todo lo que tenéis por delante esperándoos?

Tengo unas ganas inmensas de volver a ver a mi familia, abrazarlos y sentirlos cerca. Pero no por ello estoy dispuesto a dejar pasar la oportunidad por la que he estado luchando todos estos años y los que me quedan.

Me motiva a seguir tantas cosas…, pero de entre todas ellas destaco el ver crecer a mis hermanos y disfrutar juntos de un presente repleto de sorpresas; no permitir que ninguno pueda sentirse jamás solo ni falto de un hermano mayor.

Son ya dos años en los que la madurez parece nunca terminar de alcanzarnos… aunque lo pudiera diariamente pretender. La brevedad del tiempo no es el verdadero problema, sino el uso que nosotros hacemos de él. Terminar sin terminar del todo, pudiendo comenzar de nuevo una y otra vez; a la muerte me refiero, pues aún estamos vivos.

Amar nuestra familia. Disfrutar, pero sobre todo aprovechar las oportunidades. Luchar por nuestra superación personal, por entendernos y no conformarnos con ser aquello que no queremos ser.

Como si fuera el último día de nuestras vidas. Seamos realmente nosotros.

El día de mañana

Vivir no es respirar un aire lleno de incertidumbres y desventuras.

Querer no es patalear o esconderse tras el falso refugio del derecho o la razón.

Crecer no es despertarnos día tras día sin ambiciones tanto a corto como a largo plazo.

Despertar no es abrir los ojos tras el sueño que podríamos preferir frente a nuestra presente realidad.

Aprender no es memorizar ni repetir sin entendimiento.

Luchar no es crecernos en un simulado aliento de superioridad frente a alguien que no sea nosotros.

Permitir no es acertado cuando no sea realmente merecido.

Dejar que la inseguridad nos juzgue no es equilibrio ni armonía.

Extrañar no es ausencia de dolor.

Vivir es tomarnos en serio el antes y el después de nuestros días. Querer crecer despertando para aprender a luchar nos permitirá dejar de extrañar vivir porque estaremos verdaderamente viviendo.

Sprint

2016-09-01T00:00:00+00:00

“Sprint ofrece una fórmula para probar ideas que funciona en startups y grandes empresas. En cinco días pasas de idea a prototipo y decisión, ahorrando horas y dinero. Lectura obligada para emprendedores.” - Eric Ries, autor de El método Lean Startup

Tres socios de Google Ventures comparten un proceso de cinco días para resolver problemas difíciles, probado en más de cien empresas.

Capítulo 18: Agosto, 2016

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

Vuelvo a ser yo

Soy yo el que os habla de nuevo, pues no querría dar por concluido este viaje lleno de aventuras que durante estos años me han acompañado, procurando recopilar en la medida de lo posible todos aquellos pensamientos que se han dejado atrapar, mientras que otros tantos no quisieron ser escritos por quién sabrá qué motivos…

Vuelvo a ser yo el que os escribe, os siente, os piensa. Aquél que escribe para sí mismo, así como para vosotros que me leéis.

Vuelvo a comer sano, a sentirme vivo así como a hacer deporte con frecuencia. A cuidarme y a preocuparme realmente por lo que hago. Vuelvo a procurar no perder la cabeza en tornados que tienden al desconcierto innecesario. Vuelvo a sentirme vivo y, con ello, a sentirme feliz conmigo mismo y con lo que hago.

Soy consciente de que la vida consiste y consistirá en altibajos constantes. A veces incluso aparentemente arbitrarios, donde la desorientación y las preocupaciones nos podrán nublar en quién sabe cuántas ocasiones consecutivas…, pero que ello no nos quite el aliento ni nuestro deseo de superación.

Ha sido un viaje repleto de incontables experiencias, donde las responsabilidades y los deberes nacían de tantos lugares y formas distintas, a veces incluso en intervalos tan breves de tiempo. ¿Quién podría haber estado preparado o advertido de tal situación? Simplemente asombroso.

Quisiera mejorar como quise hacerlo hace años atrás…, y creo haber encontrado la respuesta que tanto buscaba: es el aprendizaje continuo, sin más misterio, el que nos conducirá día tras día hacia nuestra superación. ¡Aprendizaje sobre nosotros mismos!

¿Qué somos? ¿Qué queremos ser? ¿Hacia dónde vamos? ¿Qué estamos haciendo aquí? ¿Para qué todo esto? ¿Cuál es nuestro cometido o motivo? Todas estas preguntas tienen la misma respuesta. Una respuesta que podrá ser tan diferente como nosotros así lo queramos. La respuesta más breve y sencilla, así como la más compleja en sí misma: la respuesta eres tú.

Con otros ojos

Bajo los ojos de aquella responsabilidad madura que nos enseña a ser quienes queremos ser realmente como si nosotros no supiéramos aún qué queremos para nosotros mismos. Desde aquella perspectiva que nos ayuda a desarrollar nuestros instintos más simples y primitivos, ligada a nuestro Yo más cuerdo y humano.

¿Qué podría ser nuestra superación sino la sincera evolución de la madurez en nuestras ideas? No será más que el replanteamiento de nuestros juicios y sensaciones, así como de nuestros conocimientos y percepciones. Aquello que nos permitirá mejorar directamente desde la raíz de nuestros proyectos e ilusiones, así como convicciones de todos aquellos conceptos de los que creemos no estar equivocados.

La madurez no puede ir sino ligada directamente al compromiso de nuestra responsabilidad y a la seriedad en nuestro deber. Con amor y con pasión… siempre.

Bien es cierto que con otros ojos nos corregimos y nos hablamos hoy en día, y que muy seguramente lo seguiremos haciendo de aquí a un mañana no tan lejano, pues hemos aprendido tantas cosas en estos años…

Con otros ojos mírome. Con otros ojos, simplemente, crecemos y queremos seguir creciendo hasta perder el aliento.

Por vosotros, por nosotros.

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.

Capítulo 17: Julio, 2016

2016-07-01T00:00:00+00:00

Entendimiento

Darnos cuenta de la delicadeza del todo, del esfuerzo necesario y diario que requiere mantenernos constantes en nuestra tan ansiada satisfacción. En este anhelo de emociones, en ocasiones tan dispares, que como una marea podría verse reflejada sobre el mismo océano.

A aguas calmadas nos quisiéramos parecer, pero sólo en su medida necesaria. Porque no es lo mismo necesitar aquello que deseamos que desear aquello que pudiéramos realmente necesitar. Tanta prudencia hace falta para mantenernos cuerdos en esta realidad repleta de imprevistos.

Porque al final todo será cuestión de entendimiento y comprensión hacia el mundo: sus capacidades de respuesta frente a nuestra inquietud, sus novelas diarias e historias perdidas, sus incertidumbres desconsoladas y olvidadas en un posible caos infinito… No será cuestión más allá de una ilusión todo aquello que se nos escape al entendimiento.

En este concierto sin orquesta; en este desconcierto sin aparente principio ni respuesta. Decisiones que pudieron destruirnos por completo. Lecturas de la vida que no supimos comprender. Argumentos que no sabían siquiera cómo darse cabida en nuestro entender.

Entendimiento comprensivo de la lectura diaria de nuestras vidas: será aquello la mayoría de nuestras más profundas y sinceras preguntas sin respuesta.

Eterno retorno

Nos referiremos a un eterno retorno siempre y cuando la búsqueda sincera de nuestra superación se esté llevando a cabo. Volveremos a equivocarnos, de seguro fracasaremos en tantos y tantos de nuestros intentos, pero al final volveremos a nuestro camino, donde por meta se encontrará nuestra profunda superación personal.

Darnos cuenta de este retorno no por leerlo, sino por vivirlo. La experiencia será nuestra mayor maestra tanto como dejemos que nos enseñe. Se nos prestarán puertas abiertas o quizá hayamos sido simplemente nosotros los que las hayamos abierto, pero, con la real importancia de nuestra palabra, seremos nosotros los que tendremos que decidir y actuar en consecuencia; nos referimos al deber de si entrar, o no, en ellas.

Retornar no en otra vida posible —tan incierta como estúpida— sino en ésta. En sentirnos desbordados para advertirnos, otro día, de nuestro anhelo tan añorado, inundándonos de nuevo sin previo aviso.

Tan paradójico como respuestas pudiéramos encontrarle al sentido de aquello que deseemos realmente descubrir. Y es que posiblemente ahí se encuentre parte de nuestra trayectoria: en el intento de mantener el rumbo con mayor o menor lucidez dependiendo de con qué ocasiones nos encontremos, pero sobre todo de cómo las enfrentemos.

Etapas que cierran. Comienzos que terminan. Finales que se acercan. Nosotros como eternos temporales.

Disposición

Pensar que no podremos o que no damos para más es simplemente una falacia. Lo que entendemos por nuestra capacidad real, o más bien lo que creemos entender de ella, no es más que una mera y abstracta percepción de lo que nosotros estimamos de la misma. Estimar no será más que la consideración de aquello necesario para alcanzar una meta dispuesta.

La proximidad de nuestra percepción con lo que nosotros esperamos de la realidad que nos rodea será directamente proporcional a nuestra predisposición, así como preparación que tengamos frente a ello.

La simple negación de nuestra posible predisposición hacia aquello que aparentemente deseemos alcanzar implicará, sin necesidad de palabras ni otros argumentos, un freno desconcertante. Freno culpable de nuestra falta de aliento, cuyas incógnitas crecerán conforme el paso de los días valiéndose de nuestras dudas para pisar más y más fuerte.

La cuestión de la cuestión. Preparemos nuestra disposición hacia y por nosotros. Mejoremos nuestras habilidades sin dejar de formarnos, pero, sobre todo, sin dejar nunca de querer mejorar.

Es momento de prestarnos más atención, especialmente en aquellos momentos que más nos haga falta. ¿Quién dijo que hubiera prisa en este juego donde la voluntad no tiene por qué ir necesariamente siempre con las decisiones finales que escogemos? A esto nos referimos cuando hablamos de perseverancia en nuestra formación: porque nunca sabremos con total exactitud si éste será, por suerte o por desgracia, el último día de nuestras vidas.

Tan valiosas y singulares como nosotros las hayamos querido trabajar. Tan inestimables y extraordinarias como nosotros las hayamos querido considerar. Tan valerosas y reales como nosotros, durante todo este camino, las hayamos querido formar.

Mientras pasa el tiempo

Mientras pasan los años, nuestra existencia se ve obligada a marchitar. La longevidad de nuestra vida será tan limitada como inesperadamente pudiera verse sorprendida en tantos puntos accidentales de la misma.

Con el paso del tiempo pasa de todo menos él mismo, que con sangre fría parece permanecer estático, siendo a su vez el centro, así como raíz, de cualquier tema.

Quizá no estemos más que regresando una y otra vez a aquel momento tan ansiado por nuestra parte. ¿Qué es casual en esta vida sino aquello que se nos pudiera escapar a nuestro periodo?

Mientras pasa el tiempo, nada puede detenerse; todo queda condicionado con el mismo. Todos, sin excepción, quedamos condicionados. No existe el tiempo, sino nosotros, que somos aquéllos que no podemos detenernos.

Con el transcurso del mismo, es él el único que no transcurre. Cada segundo, cada instante…: no son éstos los que ocurren, sino nosotros.

No nos estamos refiriendo a aquello que no es más que una invención que nos ayuda a contar, a medir y a calcular, al fin y al cabo. Hablamos de aquellos momentos que pasan no sólo cuando levantamos la mirada, sino también cuando la bajamos o la giramos. Al tiempo que pasa cuando creemos que estamos dejando pasar el tiempo, lo que realmente estamos dejando pasar no es el tiempo, sino a nosotros mismos.

Algunos

No nos daremos cuenta de lo verdaderamente importante para nosotros hasta que sintamos desesperadamente esa sensación que nos demuestre de forma empírica, desde su máxima complejidad hasta su tímida sencillez, los frutos del camino que estamos persiguiendo.

Algunos simplemente no estarán nunca preparados; y no porque no puedan, sino porque no querrán ser más que lo que ellos pudieran creer dentro de su confort ya condicionado.

Porque no se trata de qué somos ahora, sino de hacia dónde estamos siendo dirigidos en este preciso instante por nuestra actitud y voluntad, y de cómo a éstas les hacemos caso en las medidas de nuestras posibilidades. Porque más allá del simple hecho de las decisiones que podamos tomar, deberemos asumir sus riesgos y actuar en consecuencia: ahí estará la principal diferencia entre unos y otros.

No todos se atreverán a ser parte. No todos querrán serlo, pues no todos estarán dispuestos a pagar un precio que en apariencia nos pudiera exceder. Nada más lejos de la realidad, pues lo que de verdad nos acabará desbordando será el descuido, en su mayoría, de nuestra profunda y sincera escucha hacia lo que realmente deseamos.

El miedo a las responsabilidades, al exceso de libertad, a la experiencia enriquecedora y al tiempo bien invertido. El temor a dejar de ser aquello que apenas costaba esfuerzo mantener, por su evolución en constante cambio que cada día requiere tiempo y atención. El superhombre no será posible de la noche a la mañana.

Capítulo 16: Junio, 2016

2016-06-01T00:00:00+00:00

¿Y si…?

¿Y si dejásemos de dirigirnos en tercera persona y nos mirásemos con otros ojos? ¿Y si intentáramos llamarnos con otro nombre? ¿Y si dejáramos de preocuparnos o de pensar tan siquiera en apartar este nuestro pensamiento racional por un día?

¿Quién nos podría asegurar que nuestro sentimiento objetivo existe y no es más que una variación de nuestro inconsciente de aquello que creemos que es imparcial? ¿Y si llamáramos a cada cosa por su nombre? ¿Qué nombres existirían? Y más importante, ¿qué nombre tendríamos?

¿Y si aprendiéramos a no soltar las riendas de nuestra vida?…, ¿cómo podrían escapársenos sin darnos cuenta de la noche a la mañana? ¿Y si todo no tuviera por qué ser necesariamente tan difícil o complejo?, en especial en algunas situaciones en las que parece estar todo dispuesto de forma desmesurada.

¿Y si tirásemos la toalla, diciendo a todo «basta»? ¿Y si decidiéramos acabar con todo de una vez por todas? ¿Qué es ese todo que podría tanto preocuparnos hasta el punto de llevarnos a un pensamiento tan insensato pero necesariamente humano?

¿Y si no sintiéramos con una fuerza que nos llegara a proporcionar incluso dolor? Fuerza fruto del mismo sentimiento de alegría o tristeza, pues si no fuésemos seres pasionales, así como racionales, ¿qué seríamos entonces?

¿Y si nuestro tiempo no estuviera ligado directamente a nuestro entendimiento del mismo? ¿No sería éste, acaso, un caos? ¿Y si todo no fuera realmente como pudiéramos creer estar viendo desde su aparente complejidad ligada a un desconcierto sin salida?

¿Y si todo fuera más sencillo? ¿Y si estuviéramos equivocados? ¿Y si todo saliera bien, recuperando la normalidad y su tranquilidad merecida?

Es sorprendente la abundancia de desorden en sinfonía con su idea de normalidad y deseo. «¿Y si…?», podríamos preguntarnos.

¿Quién nos recordará?

¿Quién nos recordará lo tanto que valemos cuando se nos olvide?, cuando la cruda realidad nos muestre su rostro y nos escandalicemos al vernos completamente desnudos en nuestra sensación consumida nacida de nuestra ignorancia.

¿Quién nos recordará lo tantísimo que valemos y lo equivocados que podemos llegar a estar?, especialmente cuando sobre nosotros pudiera tratarse nuestro pensamiento o juicio de valor sin consenso y para nada constructivo.

¿Quién nos lo podría recordar sino tú, legado de nuestro interés?, que aunque pudiera no ser tan compartido, estamos seguros de que hay mucho más en común de lo que pudiéramos a priori ver con nuestros propios ojos.

¿¡Quién sino tú podría recordarnos quiénes somos!? Tendernos la mano y ayudarnos a levantarnos cuando tropecemos. Y no estoy hablando de nosotros, sino de ti, que tienes nombre y apellidos. Tú, que nos estás leyendo. Tú, que sabes quién eres aunque a veces, como a nosotros, se te pueda olvidar. Tú, que en tus dudas e incertidumbres querías esconderte, como era normal.

Como si cualquiera lo hubiera hecho y no nos hubiera importado. Pero no tú. Tú sí que nos importas. Y es por ello que escribimos contigo en mente. Porque sabemos que nos necesitaremos el uno del otro para, cuando alguno tropiece, saber que no está solo en este, en ocasiones, abismal trastorno tan oscuro como pudiéramos imaginar pero tan incandescente como podremos juntos lograr.

No tú. Tú estás aquí para recordarnos lo mucho que valemos, así como nosotros estaremos aquí para recordarte lo mucho que valdrás.

Cuestión de tiempo

Crecer no es cuestión de tiempo, sino cuestión de corrección de errores. Ver pasar nuestra existencia como si hubiéramos perdido su noción o su motivación…: qué grandísimo error, pero a su vez qué gran síntoma inevitable.

No será cuestión de tiempo que las flores nazcan o que las situaciones sucedan porque así debían suceder: menudo disparate: creer en un destino destinado a ser historia, especialmente cuando pudiéramos referirnos a su razón por conveniencia.

No fue asunto ni materia que estuviera todo predispuesto o escrito, ni tan siquiera de la forma más absurda o disparada posible. Pues pretender el tiempo como algo con vida propia no es más que un engaño que nos haremos, desde y hacia nosotros; pues el tiempo no existe como tal más allá de nuestra percepción del mismo.

Crecer con circunstancias propias de un entorno repleto de calidades cuestionables —tan longevas como ellas mismas— y que decidían continuar a plazos aparentemente tan arbitrarios. Pudiera ser que se nos haya abierto la mente con tantos controvertidos lugares de forma inconsciente.

¿Cuál es nuestra percepción de la verdad sino aquélla que nuestro subconsciente represente para el entendimiento de nuestra aparente realidad? El tiempo no es más que otra herramienta que hemos desarrollado para ayudarnos a interpretar nuestro curso y condición. A fin de cuentas, ¿quién sino nosotros podría analizar de forma tan exhaustiva todos aquellos aspectos que involucran directamente nuestro sentido?

No será cuestión de tiempo que las flores marchiten, sino la ausencia de auxilio frente a la crudeza de la misma vida que a todos nos acotará por igual y sin posibilidad de recurso alguno. ¿Qué es cuestión de tiempo cuando nuestro tiempo ha muerto?

Madurar no será jamás cuestión de tiempo, sino más bien de sufrimiento fruto de un aprendizaje del que jamás pudimos ser advertidos. Prosperar en nuestra idea del bien, así como del mal. Progresar en las medidas de nuestras posibilidades. Desarrollarnos como aquello que tanto queríamos o pudiéramos haber querido en algún momento.

No será jamás cuestión de tiempo tratar nuestro entendimiento más que con nuestra sincera perseverancia hacia el mismo.

Comenzando los 23

Parémonos unos instantes para voltear la vista atrás, pero tampoco demasiado. Apenas basta con mirar en el comienzo de nuestra vida profesional, hará ahora más de dos años, cuando empezamos a soñar con todo esto que hoy, con tanto empeño, conseguimos lograr. Iniciándonos en nuestra tierra para acabar haciendo también nuestra aquélla a donde fuimos.

Un esfuerzo ejemplar con una sonrisa que cada día florecía desde la sinceridad más absoluta. Donde fuimos conscientes de que teníamos la oportunidad a nuestro alcance. Comenzar desde lo más bajo para ir escalando poco a poco en la montaña de lo que estaba por venir, aquello que podríamos distinguir como nuestro propio aprendizaje.

Han pasado tantos pensamientos tan diversos entre sí, tanto tiempo en tan poco espacio…, que si tuviéramos que recalcar uno en concreto, lo tendríamos ahora mismo más que claro: el estrés que podremos sufrir en ciertas ocasiones, resultado de la sensación abrumadora de no poder con todo lo que se nos pudiera venir encima. Quizá por ser la última sensación con mayor intensidad sufrida, y es que, cuando se trata de apostarlo todo, las medias tintas sólo dejarán manchas arbitrarias con las que tendremos que lidiar sin importar nuestro posible grado de disconformidad. Y dicho lo cual, esperemos aprendamos a superar con mayor facilidad todo esto, fruto de un mundo inconsciente donde las preocupaciones, en ocasiones, parecen limitarnos y no dejarnos ver las posibles soluciones.

Cabe destacar lo tantísimo que hemos aprendido de todo en general, pero en especial sobre nosotros mismos. Esos momentos que nos ayudan, sin duda alguna, a dialogar con nuestra persona, más o menos inquieta dependiendo del día y la hora. Ha habido tantos diálogos no escritos… que sólo nuestro inconsciente los podrá recordar cuando él crea realmente necesario.

Comenzaremos los 23 como jamás en nuestra infancia soñamos, pero como venimos procurando desde estos breves pero intensos años atrás.

Capítulo 15: Mayo, 2016

2016-05-01T00:00:00+00:00

Al final

A un paso del todo y a un paso de la misma nada. A diferencia de todos y de nadie. Donde la verdadera razón de ser se oculta tras las vanas intencionalidades de los perecederos propósitos que con el tiempo se desvanecen. Pues al final sólo quedará el recuerdo de aquello que verdaderamente nos interesó.

Tendemos a mezclar tantos diferentes conceptos entre sí que acabamos combinándolos todos, siendo en la práctica algo digno de admirar si consiguiéramos diferenciar para clasificar aquello que mezclamos. Nos referimos a nuestros juicios de valor; hay tanta distancia a veces entre nuestro personal entendimiento y el objetivismo real que pudiera merecer cada situación individual…

Deberíamos aprender a discernir, al menos en la medida de lo posible y poniendo siempre de nuestra parte, qué es lo que realmente nace de nuestros sentimientos y qué es aquello que nace de nuestra razón argumentada de forma empírica. Pues somos tan humanos… que dejarnos llevar por las mismas emociones nos delata una y otra vez. Y somos tan humanos… que nuestro orgullo nos cegará una y tantas veces sin necesariamente advertirnos primero.

Todos acabaremos teniendo razón en tantas cosas y en otras tantas no tanto, ninguna incluso. Nos asustaríamos si llegásemos a ser conscientes de que dichas afirmaciones conviven en el mismo piso compartido. Al final sólo quedaremos nosotros y nadie tendrá razón porque todos la habremos tenido. Es por ello que lo importante aquí no debería tratarse de un «¿Y al final?».

Como si de contradicciones necesarias, de las que esta vida está llena, se tratara. Esta noche escribimos sin intención de inventar nada nuevo. No aprenderemos más de nosotros que como forasteros de nuestro propio yo, aprendiendo a escuchar y a leer con especial atención todo aquello que realmente deseemos con nuestra persona para finalmente sacar algo en claro de todo esto y prepararnos para cualquier posible último final.

Haber perdido

Sentir haber perdido alguna parte de esa esencia que nos hacía, de aquella sincera forma, sentir. Notar que las mismas notas suenan diferentes a como no hace tanto de forma altruista sonaban.

Ceñir el entrecejo en la duda de y con uno mismo. Pues percatarnos de un ligero desconcierto psicológico en nuestras bases, que en su día fueron pilares fundamentales, nos causará temor y atisbo en consecuencia.

Encontrar los problemas y solucionarlos era nuestra mayor recompensa, pues ahora, como aquellos cobardes a los que tanto criticábamos, nosotros nos vemos reflejados: asustados en nuestro desconcierto. Los problemas hay que solucionarlos, no basta con simples parches que simulen su corrección o escondan la raíz de aquellos malestares.

¿Qué tan lejos aún nos queda todo? ¿Qué tan grande nos podrá quedar el abismo en el que esta vida, con sus emociones tan dispares, puede llegar a convertirse? ¿Qué tan poco podremos conocer del conocimiento en sí mismo en nuestro intento?

Quizá haya sido eso: preocupaciones innecesarias. Quizá haya sido en sus pequeñas dosis acumuladas como una bola de nieve que crece conforme cede por la colina.

La conformidad, la falta de motivación, la carencia de la sonrisa sin motivo. La ausencia desmesurada de afecto desinteresado. No es el miedo el culpable de nada, sino el síntoma de la falta de motivación frente a la realidad con la que nos toca encararnos día tras día.

Quizá no haya sido nada. Quizá aún nos quede tanto por lo que pelear sin temor alguno, por lograr conseguir lo que realmente deseamos. Pues, ¿qué podríamos anhelar más que disponer de esa motivación para alcanzar aquellos sueños predispuestos de forma altruista?

Quizá quede menos simplemente de esta reflexión diaria que últimamente nos tortura, una reflexión que parece algunos días haber perdido el control.

¿Qué es acaso haber perdido algo?

¿Somos realmente?

¿Qué es lo que somos realmente? ¿Qué podríamos considerar como nuestro verdadero Yo? ¿Cuál es esa identidad que podría diferenciarnos frente al resto? ¿Somos acaso la misma persona en esencia que hace algunos años atrás? ¿Y si cambiáramos el tiempo de la anterior pregunta?

¿Somos distintas personas cada día? ¿Qué es eso que nos identifica como seres individuales ante al resto? ¿Qué es aquello que nos distingue frente a nuestro entorno y por lo que él mismo nos reconoce? ¿Qué es esa esencia que nos distingue frente a esta paradoja repleta de cuestiones aleatorias y leyes dictadas aparentemente desde el más absoluto sin sentido?

Aquello que nos identificará, que nos hará ser realmente, que nos representará ante el mundo exterior. Aquello que nos define y caracteriza, pero sobre todo nos individualiza y nos distingue frente al resto del enorme conjunto: es nuestro pasado directamente ligado con lo que nosotros de él hayamos aprendido.

La importancia de nuestra experiencia y perspectiva, de nuestra proyección y confianza, de la inversión que hayamos querido haber hecho de nuestro tiempo.

La diferencia del querer ser al ser realmente no es tan abismal como podría llegar a parecer o como algunos nos quisieron pintar. En la proyección del éxito se encuentra el mismo.

Nuestro pasado es nuestro Yo más puro: cuando muramos no habrá más identidad nuestra que la que nosotros hayamos querido reflejar.

Será, por tanto, nuestra representación presente el fruto de nuestro entendimiento pasado ligado a nuestra inquebrantable y veraz comprensión que no dejará de ponernos a prueba una y tantas veces hasta que nuestro respirar descanse sin permiso y sin retorno.

La historia

La historia como el libro abierto de nuestras vidas, plasmadas para el recuerdo y su aprendizaje, que apenas unos pocos se atreven a leer. Destinándonos a repetir las mismas situaciones, los mismos errores que otros ya pudieron haber cometido y que, sin embargo, parece que estaba en nuestra naturaleza el cometerlos.

¿Qué son los errores más que aquellos propósitos llevados a cabo que nos hacen sentir al final equivocados, que nos transmiten esa cierta angustia inequívoca desinteresada? Rabia… por aquellos necios que no supieron ni quisieron leer a tiempo las señales para saber cuándo pisar los frenos.

Como un libro lleno de errores y de aciertos donde la batalla entre los mismos parece equilibrada por más que pasen los días. Como si no hubiera tendencia a la existencia de un final con un claro vencedor. Como si nuestra disposición se inclinase hacia la repetición hasta lo absurdo, pues en ocasiones no es que seamos ciegos, sino que somos nosotros mismos los que no queremos apreciar. Y es entonces cuando el valor de la historia en sí misma asusta porque no hay más ciego que el que no quiere ver.

Podríamos seguir escribiendo sobre este tema, pero ya estamos cansados, furiosos e incluso quizá asqueados de pensar que pueda existir gente que no quiera pensar.

¡Reflexionemos pues sobre nuestra historia!, especialmente la ya vivida, proyectándola sobre la que queremos para nuestro porvenir.

Números

Cuarenta y nueve, como número que representa este día: 25 de mayo.

Treinta y siete, como el efímero recuerdo desconsolado por excelencia.

Once, como aquél que sin buscarlo hoy se dirige a sí mismo en tercera persona.

Nueve, como los que quedaron y se vieron obligados, sin más opciones posibles, a aprender como fuera de aquella situación, para todos inesperada.

2004, como el año más humano y desalmado.

Cero, como oportunidades de despedidas posibles tras su marcha. No recordar tan siquiera cómo lucía el día anterior, pero sí su pelo rizado y su amable sonrisa… Y sólo alcanzar en nuestra memoria su reflejo tras el marco de la puerta a oscuras horas de la noche, sin tiempo tan siquiera para despedirse. Pues nadie habría podido adivinar lo que estaba por suceder pocas semanas después de su partida; su imposible regreso involuntario.

Cientos de noches han pasado ya desde entonces y apenas podemos encontrar momentos de intimidad en estas cartas que, ambos sabemos, no podrás jamás leer. No podremos conocernos, pero estoy seguro de que sí podríamos reconocernos…, y tengamos claro que no habrá nunca mayor deseo que una sonrisa tuya de regreso hacia nuestra mirada en tu busca.

No recuerdo cuándo fue la última vez que dije «mamá», y creo que eso es algo que mi primera persona no podrá olvidar nunca.

Es bastante duro y complejo. El precio más caro que jamás podríamos experimentar. Una de las experiencias más dolorosas que podríamos tener y que sin duda todos, sin excepción, antes o después, acabaremos teniendo. Y comprenderemos, quizá con otros ojos, a quien se escribe hoy en tercera persona de nuevo.

Tratando de entendernos

En esta recta final en la que nos disponemos a escasos días del cambio de hora interno. Con té hirviendo como suplemento de aquellos pensamientos tristes que podrían incurrir en nuestra mente a estas horas sin pretenderlo.

Y es que nos damos cuenta de la falta de interés real que en ocasiones nos hace tanta falta. Pues lo que no hace tanto tiempo nos parecía obvio en su normalidad, hoy en día nos cuesta algo más llevarlo a la práctica. Somos cambiantes para bien como para mal.

La teoría nunca pudo ser más fácil que el hecho de ser escrita en sí misma. Sin embargo, llevar cualquier teoría a la práctica supone de un esfuerzo mayor que su propio y simple entendimiento: supone hacer de dicha teoría una realidad, pues no hay mayor verdad teórica que aquélla que se pueda demostrar.

Con té hirviendo en la mano, nos damos cuenta de que estamos en la recta final, a pocas semanas de quién sabe qué realmente. Y con esto nos estamos refiriendo no a vivir dejados, sino todo lo contrario, ¡a vivir enamorados hasta que nos consumamos en ello! Enamorados de lo que hagamos, de lo que sintamos, de lo que deseemos realmente para y con nosotros. Más allá de simples ideas vanas o conceptos desconocidos, ¡conozcámonos en profundidad!, ¡sintámonos como nos queremos realmente sentir!, ¡despertémonos con esas ansias devoradoras de arrasar con el día que tanto soñábamos! ¿¡A qué diablos estamos esperando!?

Ya lo hicimos una vez, muestra suficiente para darnos cuenta de que es posible, de que la palabra «imposible» está equivocada cuando a nosotros se pudiera referir.

Pues no somos más que posibilidades que aún esperan para ser despertadas sin miedo alguno, impacientes por ver el sol naciente hasta acostarnos en nuestro merecido descanso. Acompañados, al menos, por nuestra idea y visión global del día vencido; y vaya si vencido, pues nosotros seremos los que habremos ganado. Deberíamos, por tanto, concebir los días como logrados y no como pasados o perdidos.

Contemplar y aprender a discernir, ¿qué es lo que realmente nos gustaría cambiar?, ¿qué es lo que realmente nos gustaría mejorar?, ¿qué es lo que realmente querríamos para nosotros? Soñemos con estas cuestiones. Que se queden en un sueño teórico o práctico será pura y únicamente cuestión de nuestra recompensa.

Código Limpio

2016-05-01T00:00:00+00:00

El código malo puede funcionar, pero si no está limpio, puede hundir a una empresa. Cada año se pierden horas y recursos por culpa de código mal escrito. No tiene por qué ser así.

Resumen

Capítulo 1: ¿Qué es el código limpio?

El código se puede medir como “bueno” o “malo” en una revisión, o por cuánto tiempo tardas en explicarlo.
El código limpio es elegante, eficiente, legible, simple, sin duplicaciones y bien escrito.
Tu código debe añadir valor al negocio.
Al abrir un archivo fuente, el código limpio transmite calidad y se entiende fácilmente.
Haz tu código limpio y legible para que cualquiera pueda entenderlo rápido. No hagas perder tiempo a otros.

Capítulo 2: Nombres significativos

Los nombres de las clases, variables y métodos deben ser significativos e indicar claramente lo que hace un método o lo que es un atributo.
Crea nombres pronunciables para facilitar la comunicación.
Evita acrónimos y nombres confusos, que pueden llevar a conclusiones erróneas a cualquiera que lea el código.
Usa nombres que reflejen el dominio del sistema, el contexto y los problemas que deben resolverse.

Capítulo 3: Funciones

Los métodos deben ser fáciles de leer y entender.
Deben transmitir su intención.
Deben ser pequeños: hasta 20 líneas.
Deben hacer solo una cosa.
Usa nombres que digan claramente qué hace el método.
El número ideal de parámetros es cero, luego uno, luego dos.
Evita tres parámetros; si los usas, justifícalo.
Un Boolean como parámetro indica que el método hace más de una cosa.
Evita la duplicación.

Capítulo 4: Comentarios

Cuando necesitas comentarios suele ser porque el código es malo.
Si piensas escribir un comentario, mejor refactoriza el código.
Los comentarios no salvan el código malo.
El código debe explicarse por sí mismo.
A veces los comentarios son útiles en ciertos lugares específicos.
No expliques el código con comentarios. Usa nombres descriptivos de variables y métodos.
Los comentarios pueden destacar la importancia de ciertos puntos.
No escribas comentarios redundantes, inútiles o falsos.
Para saber quién cambió qué y por qué, usa control de versiones.
No comentes código sin usar. Elimínalo.

Capítulo 5: Formato

El formato es una forma de comunicación entre desarrolladores.
El código desordenado es difícil de leer.
La legibilidad afecta a todos los cambios futuros.
Las clases pequeñas son más fáciles de entender.
Pon un límite de caracteres por línea (por ejemplo, 120).
Mantén los conceptos relacionados cerca verticalmente para crear un flujo natural.
Usa espacios entre operadores, parámetros y comas.

Capítulo 6: Objetos y estructuras de datos

Sigue la Ley de Demeter:
- Cada unidad debe tener solo conocimiento limitado sobre otras unidades: solo unidades “estrechamente” relacionadas con la unidad actual.
- Cada unidad solo debe hablar con sus amigos; no hables con extraños.
- Solo habla con tus amigos inmediatos.
No hagas objetos tontos.
Los objetos ocultan la abstracción de datos y exponen métodos que operan los datos.
Las estructuras de datos exponen sus datos y no tienen métodos significativos.

Capítulo 7: Manejo de errores

Planifica el manejo de errores con cuidado.
Cuando algo falla, hay que hacer que el sistema responda correctamente.
Lanza excepciones en lugar de ocultarlas.
Crea mensajes de error informativos: qué falló, dónde y, si es posible, por qué.
Separa las reglas de negocio del manejo de errores.
Evita devolver NULL; devuelve un objeto vacío.
Evita pasar NULL a los métodos; puede causar NullPointerExceptions.

Capítulo 8: Límites

Al usar código de terceros, encapsula las APIs para no exponer objetos externos.
Haz tests de las APIs de terceros.
Estudia la documentación y prueba la API antes de usarla.
Conoce bien las características que vas a usar.

Capítulo 9: Tests unitarios

Asegúrate de que cada pieza de código hace lo que esperas.
Sigue las leyes de TDD:
- No escribas código sin tener primero un test que falle.
- No escribas más tests de los necesarios para fallar.
- No escribas más código del necesario para pasar el test.
Mantén tus tests limpios.
Los tests evolucionan junto con el código.
Código sucio = tests difíciles de mantener.
Usa la regla F.I.R.S.T:
- Fast: ejecución rápida.
- Independent: independientes entre sí.
- Repeatable: repetibles en cualquier entorno.
- Self-validating: auto-validantes.
- Timely: escritos a tiempo.
Los tests son tan importantes como el código de producción.

Capítulo 10: Clases

Organiza las clases así:
- Constantes públicas estáticas.
- Variables privadas estáticas.
- Variables de instancia privadas.
- Luego los métodos.
El nombre de la clase debe reflejar su responsabilidad.
Cada clase debe tener una sola responsabilidad: una razón para cambiar.
Intenta describir la clase en una frase breve.
Los métodos deben ser pequeños y con una sola responsabilidad.

Esta entrevista se basa en el libro de Uncle Bob “Código Limpio”. Repasan algunas guías que te ayudarán a ser mejor programador y exploran cómo los libros y tendencias actuales están moldeando el mundo del software.

Capítulo 14: Abril, 2016

2016-04-01T00:00:00+00:00

Aparentar o ser

Podremos aparentar tantas cosas y actuar de tantas formas posibles…, hasta el punto, quizá, de nublar el verdadero ser. ¿Pues cuál es este ser realmente sino el mar de sus continuas apariencias? Podremos aparentar en todo momento, pero ¿acaso podríamos ser realmente aquello que aparentamos?

El problema de la identidad nace cuando nuestra apariencia confronta nuestro sentimiento del ser. Es entonces cuando surge nuestro principal conflicto interior. ¿Somos acaso más que constantes apariencias en evolución?, donde la adaptación quedaría ligada a la supervivencia… ¿Qué somos realmente sino el simple sentimiento que nos diferencia frente a lo que nos rodea?, refiriéndonos a otros seres.

¿Acaso tenemos mayor derecho a considerarnos especiales o algo más que simples seres vivos? ¿Quién nos puede asegurar cada mañana al despertar que no somos un simple fruto de algún experimento?, donde por realidad y recuerdo no tenemos más que alguna memoria previamente programada y lista para observar nuestro comportamiento.

En ocasiones tendremos dudas de tan siquiera quiénes somos, de qué buscamos o simplemente de qué esperamos encontrar. ¿Podrían ser las dudas en sí mismas sus propias respuestas?

Tantas

Tantas cosas por hacer, tantos deseos por cumplir. Tantos suspiros que aún quedan en la espera de su momento mientras nos turnamos con nuestra inquietud, siendo ella misma la que nos ayudará a tomar los caminos que acabaremos modelando.

Tantas prisas, tantas alegrías no empleadas, tantos lloros no merecidos y otros cuentos olvidados.

Y es que nuestra percepción de la realidad es tan distinta y tan dependiente de nosotros mismos, que no podríamos ser conscientes tan siquiera de la cantidad de variedades que existen ni de sus diferentes cualidades tan distintas entre sí.

Sensación abrasadora que nos desconcierta cuando bajamos la guardia. Emoción alarmante que nos acompaña en su conformidad desvelada. Intuición que no deja pista alguna de su paso. Alivio añorado, así como extrañado, en tiempos complicados.

Tantas metas, tanto futuro, tantos cuentos…, que podríamos incluso acabar olvidando de dónde venimos y hacia dónde vamos. Sentir el deseo de una pausa. Sentir el desconcierto del no saber qué hay que saber ahora, confundidos en estos momentos de realidad enredada.

Queda aún tanto por contar y por vivir, tanto por saber y por querer, tanto… que esperemos que todo llegue a buen puerto cuando tenga que llegar.

Constantes

Somos una constante muda de ideas. Constante dependiente, en mayor medida, de aquello que no deseamos pero que hayamos sufrido de algún modo. No desear no es lo mismo que no haber deseado, del mismo modo que no querer haber sufrido no implica no haberlo hecho.

El tiempo es sin duda la mayor incógnita en su verdad: el relativismo extremo, el cambio de etapas… Encontrarnos para perdernos momentos después. Tenernos y temer aquello que pudiéramos extrañar de nuevo.

Sentir como el todo y su predilección tienden a la abstracción más pura y arbitraria. Experimentar cómo nuestros pensamientos no son más que frutos inmaduros y que, llegado el día, cualquier temporal imprevisto podría arrancarlos sin remordimiento alguno.

Acordarnos de aquella etapa donde la esperanza dirigía y nos guiaba como madre preocupada por sus hijos, pero ¿qué sabemos nosotros de esto al fin y al cabo…?

Recordar no más que la ilusión añorada, quizá su mera nostalgia, quizá años y años desnudos como el tiempo que no hacían más que acompañarnos sin reales intenciones. Propósitos color azabache que descansan sobre el más puro anhelo de sinceridad hacia y con nosotros. Por nosotros, eternas constantes destinadas a la continua transformación junto a nuestro cambio.

Hablemos de nuevo

Percatarnos de aquello que nos impedía sentir más allá del sufrimiento, en la duda continua de no saber qué dirección tomar. Flaquear una y otra vez hasta el posible cansancio ya olvidado. Desear sinceramente terminar con esta sensación incómoda de desconcierto anónimo.

Acariciar el despido, no ser capaces de prever el caos y su perturbación avecinada hacia nuestra persona. Necia impotencia.

Aleccionarnos una y otra vez, tantas veces incluso de lo mismo. Tropezar y caer con y sin vergüenza, como si fuéramos en busca de nuestros propios límites que creímos en su día inexistentes; vaya cuán equivocados estábamos.

Hay tantas cosas ciertas y otras tantas no tan claras… Pero lo que creo que aprendimos fue a discernir, al menos, aquello que realmente nos superó: el descontrol de la situación, no saber qué hacer ni cómo reaccionar tras flaquear en todos nuestros fallidos intentos por no lograr aquello que se nos encomendó.

La simple idea de la duda hacia nuestras dudas será la culminante si la dejamos brotar. ¿No podría todo volver a ser? Será, por supuesto que será. Volvamos a ser de nuevo.

Es tiempo de

Es tiempo de decir «adiós» a tantas cosas. Sintiéndonos nómadas en nuestra vida en busca de aquella sensación de plenitud donde los sentidos desean por encima de ellos mismos y se sienten parte del todo junto a sus prójimos.

Es tiempo de empezar a decir «adiós» a tantas cosas. En nuestra superación crecimos y no quisimos ni queremos permitir sentir ese descontrol que nos pudiera hacer perder la cabeza, encontrándonos en disconformidad continua por más tiempo del que pudiéramos desear.

Es tiempo de ser conscientes de que deberíamos empezar a decir «adiós» a tantas cosas. No en vano quedará todo lo aprendido, pues permanecerá escrito desde ahora hasta entonces que un día resolvimos y crecimos escogiendo ser.

Es tiempo de decidir cambios para y con nosotros, siendo la finalidad de los mismos el motivo de su creación. Sentir no poder soportar tanto nos hace al final capaces de tolerar en un mayor margen, pero no era esa nuestra intención primera. No debiera ser el sentimiento hacia lo externo de mayor grado frente al interno, pues nuestra traza y aspecto dependerán, de forma directamente condicionada, de nuestra más íntima persona.

Llegará el tiempo en el que las decisiones tomadas cursarán con tan alto grado de importancia, pudiendo incluso cambiar el rumbo de aquello que en meses pasados establecimos para los próximos venideros. Y es que nos queda tanto por equivocarnos y por cambiar…

Es bien cierto, así como debiera ser ya sobradamente conocido, que en la abstracción pura de los errores, así como de los aciertos, existen en común las decisiones que tomamos, en la medida de nuestras mejores posibilidades. No habrá mejor actitud que la que con nuestros ojos miremos.

No debiéramos hacer tantas cosas y hacer otras tantas que tanto deberíamos, que será tiempo pues de decidir a qué responsabilidades queremos realmente rendir cuentas y a qué precio, pero sobre todo qué nivel y qué metas seremos capaces de alcanzar.

Es tiempo de dar la bienvenida a tantas otras, de empezar a ser conscientes de los cambios a estos niveles que a primera vista pudieran sobrepasar cualquier joven perspectiva.

¿Qué podría ser?

¿Qué podría ser que aún no haya sido? Dejarnos llevar por las emociones, dejarnos hacer sin mayores intenciones… Experimentar ese cosquilleo, esas mariposas ansiosas de protagonismo. Ocho meses han pasado desde que nos vimos por última vez en persona. Es lo que tiene vivir en el extranjero.

Mañana despertaremos de nuevo en Berlín, pero dormiremos en nuestra tierra cálida donde nacimos. Donde la familia aguarda por el que será el ansiado momento de un nuevo reencuentro compartido después de tanto tiempo.

¿Qué podría ser que aún no haya sido? Tras experimentar verdaderamente de todo, me atrevería también a decir «renacido», habiendo sido incluso en cualquier modo. No quisiera pensar en estos momentos demasiado, sino soltar simplemente aquellas palabras que, momentos previos de conciliar el sueño antes de este breve viaje de retorno, por mi mente ocurran. Y es que siento la necesidad imperiosa de escribir a escasas horas de partir hacia este vuelo. Será toda una semana cargada de tantas emociones que espero que no nos traicionen los nervios y que seamos capaces de canalizarlas poco a poco.

Conociéndome, y en lo poco que me conozco todavía, estoy seguro de que será una semana inolvidable. Una de tantas semanas que aún nos quedan por viajar y por contar…

Tengo ganas de ver a mis tíos, a mi padre, a mis primos, a todos ellos: a mi familia en general. Pero en especial tengo ganas de ver y abrazar a mis hermanos y hermanas, los cuales extraño tanto cada día. Sólo espero que sepan comprender algún día el significado de todo esto, que entiendan esta motivación y que la apliquen no sólo de forma teórica.

No quisiera entrar hoy en más detalle. Es tiempo de descansar, pues mañana será un gran día: el comienzo de una semana inolvidable.

Capítulo 13: Marzo, 2016

2016-03-01T00:00:00+00:00

Se hace más notorio

El valor de nuestro tiempo que, junto al recuerdo de la muerte, nos evoca esa nostalgia que grita sin cesar, deseando abrirse paso en este camino lleno de incertidumbres y, en ocasiones, desconsuelos.

Se hace, simplemente, más notorio el olor de aquellas aladas almas de las rosas cuando no están. Cuando falta aquella esencia que nos permite revivir con entusiasmo, es precisamente cuando se hace más notorio. ¿Acordarse de qué? ¿De qué teníamos que acordarnos?

Sentir cómo nos quitaron las ruedas de apoyo como cuando aprendíamos a montar en bicicleta, aquéllas que nos aseguraban confianza, pero sobre todo sentirlo hoy en día con la misma realidad. Sentir cómo la presión de las distintas situaciones puede ser, en ocasiones, un verdadero enigma para nada agradable.

Empaparnos de experiencias que no pensábamos encontrar en un principio y que, sin embargo, fueran ellas las que nos acabaran encontrando; no saber cómo responder.

El tiempo nos arrastra sin piedad y sin miedo. Nos obliga con serenidad, haciéndose más notorio cuando él mismo nos recuerda quiénes somos, pero sobre todo quién es él.

Ser los nuevos en este juego sin reglas más allá de las que nosotros inventemos o queramos concebir. Más allá de nuestro sincero entendimiento, donde por razón y verdad despreciamos a aquéllos que utilizan distintos prismas para observar.

Querer existir como eternos principiantes es como agua que fluye por la corriente, teniendo por destino la inmensidad del océano junto a su abandonado olvido. La despreocupación ligada al desinterés por el todo es nuestro mayor riesgo. Pues vivir con la excusa del mañana incierto, combinado con la misma indiferencia de nuestra persona, sólo puede acabar en un vacío infinito y carente de toda posibilidad, así como oportunidad.

Marchitándonos poco a poco, vemos pasar el valor de nuestro tiempo frente a nuestros ojos.

Es cuando

Cuanto más cueste creerlo posible, cuando los lienzos vacíos aún sigan blancos, cuando aquel pensamiento maduro se sienta algo marchitado por culpa de quién sabrá qué ni cómo…

Entrelazamientos de ideas no más allá de nuestros meros y subjetivos pensamientos, y que quizá ya no merecen mucho más… «Claridad» es la palabra con la que, en su ausencia, todo oscurece.

Tanto de forma simple como compleja, es como nuestras ideas pueden llegar a convivir junto a esta práctica que entendemos por vida, donde la finalidad, más allá del aprendizaje, se escapa a nuestro conocimiento, pues otra idea no podríamos concebir. Comprensión motriz, así como audaz, es nuestra experiencia, viéndose más reflejada cuanto más hondo hayamos decidido intimar. Causante de la causa en su consecuencia que a veces nos impide sonreír.

Movimiento sin retorno destinado a la duda y a la continuidad de su carencia. Pues no todo será ciencia, y mucho menos alguna innecesaria creencia.

El tiempo y su no descanso que incansable nos persigue… Nadie nació preparado. En pañales frente a toda pregunta que algún día nos tocará enfrentar; será entonces cuando nos demos cuenta de lo que realmente valdremos.

En nuestra sinceridad tendríamos que admitir que, por lo menos, deberíamos ser; de lo contrario, no estaríamos desempeñando nuestro cometido, pues si de algo somos responsables, es de estar seguros de aquello por lo que nos gustaría haber vivido.

Tendemos a la confusión y a la mezcla entre causas y consecuencias, donde las preguntas pretenden ser respondidas antes siquiera de ser formuladas. ¿Cuál es pues nuestra tarea sino aquélla que ya debería ser más que evidente?

Y no escribo para ti que nos oyes, sino para ti que nos escuchas.

En la montaña

Temblor. Temor. Fracaso. Sufrimiento. Desaliento…

Temer al fracaso y su horror, sufriendo con temblores en nuestra desesperación por no vernos capaces de alcanzar mayores hazañas en los días venideros.

¿Dónde quedamos? ¿Cuándo será el momento perfecto para concluir de una vez por todas? Impotencia en un abismo garantizado por sobredosis de falta de sentido. Reloj de manilla oxidado a punto de dar su última vuelta. Traición traicionada… ¿Acaso perdonada por tratarse de nosotros mismos? ¿Quién podría vivir sin su perdón al fin y al cabo?

Montaña rocosa, años atrás, junto a unos tragos de desaliento que buscaban menos desconcierto en aquel caos sin nombre pero con apellidos.

Al acecho de la admisión, del propósito equívoco en una desilusión que resultaba estar fuera de control. Acompañados por el engaño y por la soledad, pero sobre todo por nuestra falta de sentimiento constante de pertenencia a una falsa realidad, especialmente de puertas para adentro.

Lástima por aquél que apunto estuvo… Nuestra propia alevosía a nuestra traición nos salvó de aquella montaña y su disimulado frío nocturno que asalta por las noches.

Ojos de aquel entonces cegados cruelmente debido a la carencia de su comprensión, así como a la presión en todas las direcciones posibles. Recordando con cada trago en la cima de la montaña mientras la música sonaba y las lágrimas nacían para sucumbir a escasos segundos después, durante la espera…

Memorias que sentían su desvanecimiento,
tristeza real y profunda sin aliento.
Confusión servida en cada sentimiento.

En aquella montaña pudimos volar, avergonzados además por la innecesaria complicación en la que introdujimos a tantos terceros. Pero no es vergüenza ya lo que sentimos, sino tristeza por el hecho de que ello hubiera sido posible y por las tantísimas probabilidades de diferentes finales que, por suerte más que por desgracia, nunca llegamos a conocer.

Parece que aquel monte nos guardaba una sorpresa inesperada. O, más bien, fuimos nosotros los que inventamos dicha sorpresa descontrolada con un final bastante diferente —así como gratificante— de lo que nosotros, en aquel equivocado día, nos propusimos. Motivo suficiente de alegría desde aquel día hasta nuestro entonces.

Saborear

Saborear la dulzura de aquel momento
cuando con piel de gallina escribimos.
Sentirnos vivos, protagonistas de este cuento;
pareciera que en su día lo escogimos.

No vernos como algo definido por completo,
por sentir cómo nos queda aún tanto.
Vistiendo junto al temporal no inquieto
que día y noche nos reprocha cuánto.

Amanezca la luna despejada,
con extraño miedo a haber vivido.
Nazca de nuevo aventurada,
en vela quede hasta su olvido.

Cuantiosa dicha persevera agraciada,
a veces angustiada por el viento.
En su sencillez junto a su mirada,
disfrutaba y esperaba en su asiento.

Degustar la amargura junto al placer;
Nos sirva de una vez como escarmiento.

Teniendo por único temor a la realidad, que en ocasiones puede comportarse como si no existieran siquiera simples reglas de conducta. Realidad donde los colores, con sus grises, pierden incluso todo el sentido que en su día pudieron haber tenido.

A aquellas manos que dibujaban y hoy escriben con tanto gusto. A aquéllas que nos recuerdan cómo es posible plasmar, reflejar, hacer realidad meras ideas sin que siquiera éstas aún existan. A aquéllas con las que crecimos y nos hicieron crecer. A aquella idea que miedosa nació y que quiso entrenar y entrenó para dejar de ser cobarde. A aquélla cuya finalidad se encontraba en su intimidad, pues era, es y será en sí misma su propósito.

A la profundidad del desconcierto, del mar y sus océanos, y del abismo infinito y su caos interior. ¿Temor? ¿A quién deberíamos temer realmente más que a nosotros mismos? Querríamos hablar desde otra perspectiva, pero se nos hace complicado a estas alturas girar la cabeza y mirar hacia otro lado; no como en su día nos hicieron en más de una ocasión, donde aún recordamos nombre y apellidos.

¿Quizá deberíamos escribir con algún orden predefinido? ¿Quién podría esperar acaso más de nosotros que nosotros mismos? Aquí nadie ha escrito nada.

El sabor de la carencia es sin duda el plato por excelencia que tanto nos enseñará y tan poco nos dejará. Plato donde la prudencia y el desorden parecen intentar lo mismo, disputándose entre ellos el timón de la sospecha.

Saborear a veces momentos cuerdos, pareciendo en ocasiones auténticos disparates…, pero sobre todo degustar la incertidumbre de las líneas que aún están por escribirse, habiéndolas agradables y no tan dulces. Momentos cuerdos donde las emociones disparan sin temor por quien puedan herir, reviviéndonos en nuestra inquietud de resoluciones.

Odio a Dios

Nuestro más sincero rechazo a la figura de ese Dios todopoderoso y omnipresente que tanta gente nos intenta persuadir. A aquella figura superior a nosotros que nos vigila o nos protege en las medidas de quién sabe qué posibilidades.

Nuestro más sincero odio y rechazo a la idea de ese Dios bondadoso, así como aniquilador, donde las contradicciones no dejan de ser constantes; constantes e interesadas por aquéllos que nos lo intentan vender.

Nuestro más sincero repudio, odio y rechazo a la putrefacta idea de aquella figura superior a nosotros. A aquel Dios y profeta que dijo en su día venir en nombre de quién sabrá quién. A aquél que dijo ser quien, cobardemente, hoy día muchos aún confían en su necedad.

Nuestro mayor asco, repudio, odio y rechazo hacia la misma, tan siquiera, idea de la existencia de Dios como algo superior a nosotros. A aquél que dice amarnos y, sin embargo, es permisivo con todo aquello que no es amor. A aquéllo que esconde los intereses egocéntricos de una idea carente de todo, especialmente de falta de humanidad.

Nuestro mayor y más sincero desprecio, asco, repudio, odio y rechazo hacia Dios y todo lo que su idea en sí misma representa siempre y cuando no seamos nosotros. Pues no existirá mayor falacia posible que la de negar haber nacido para ser nuestros propios dioses.

Nuestra más sincera lástima a aquellos cobardes que tras su falta de interés se esconden. A aquéllos que hoy en día creen tan siquiera ciegamente en alguna de las palabras nacidas de algún cuento, ya sea por tradición o por simple carencia de lógica o intelecto.

Nuestra mayor intolerancia a todo aquél que dice de predicar la verdad por su boca y por sus acciones se contradice, excusándose en que «la carne es débil» o «el demonio nos engañó». Malditos seáis vosotros también, insensatos e hipócritas. ¡El mal sois vosotros!

Incluso tener más lógica que la misma idea de Dios, que nos intentan inculcar por medio de religiones en nuestra juventud, no es para nada complicado. ¿Quién puede odiarnos más que la idea de Dios en sí misma?, una idea llena de lucros humanos, mentiras y engaños. Una idea rica en falsedades y menosprecios, pero sobre todo en incertidumbres dentro del abismo en el que puede llegar a convertirse todo esto si no somos capaces de decir «¡basta!».

Y no bastará

Y no bastará con que deseemos que todo termine, que toda esta preocupación se diluya de una vez por todas.

Hacer de un posible grano de arroz una montaña repleta de incógnitas y temeridades. Desear terminar con toda esta presión que por sorpresa nos abdujo. El temor de la incertidumbre y su desconcierto es lo que más nos abruma.

Y no bastará con creer ser, incluso siendo en ocasiones en las medidas de nuestras posibilidades. Pues hablar de la intención no es siempre lo acertado ni lo correcto, y tampoco será lo suficiente como para evitarnos ciertos temores o ayudarnos a despejar simples dudas.

Y no bastará con ser sin serlo, pues ser es y será por siempre nuestro principal cometido. Donde la misma idea del vacío y su despropósito podrá visitarnos en tantas ocasiones sin permiso.

¡Y no podremos permitir no sentirnos! Aunque extrañarnos podrá ser, en ocasiones, también algo inevitable. ¿Qué estamos haciendo ahora? ¿Y con nuestra vida? ¡«No bastará pues», os decimos! A lástimas y caídas hemos sobrevivido: basta de una vez por todas de dicha idea pobre y carente de sentido, pues sobrevivir no es vivir.

¡Y no bastará con que nos digan! ¡Seremos nosotros los que a nosotros mismos nos digamos…! Que todo está bien y que así seguirá estando.

La complejidad de la obligación

Cuando nos olvidamos de quiénes somos es cuando tendemos, en mayor grado, a la angustia nacida del desconcierto. Aquella incógnita que nos asusta y nos hace sentir incómodos. Aquello que a priori podría parecer innecesario, pero seguro debería derivar en una conclusión obligatoria: educarnos en la materia.

Cuando nos olvidamos de quiénes somos es cuando más deberíamos recordarnos. A toda prisa… En una carrera donde el tiempo se ve obligado a no detenerse ni un segundo. Donde las decisiones con mente fría se tornan complicadas, pero especialmente donde la identidad que nos debiera pertenecer se siente abrumada y escasa de esencia.

Todo gira en una repleta aura de conjeturas, vértigos y miedos ligados. Pues olvidarnos de nuestro principio, de nuestra personalidad, está inequívocamente en la dirección incorrecta de lo que realmente quisiéramos.

Cómo nos gustaría, en ciertas ocasiones, simplemente evitar aquellas situaciones o conocimientos que quisiéramos eludir, así como hacer, aprender o saber con antelación otras tantas que podríamos olvidar o no interpretar correctamente a tiempo.

¿Hasta qué punto estamos dispuestos a llegar? ¿Hasta qué punto realmente estamos dispuestos a renunciar a ciertas cosas por otras tantas? ¿Qué es esto sino un intercambio de decisiones y prioridades?

Es por ello que la inquietud nos persigue cuando erramos, con mayor o menor culpa, en nuestro compromiso porque se trata del sentimiento de proximidad de nosotros hacia nosotros. Nuestra plenitud no debería ser más que nuestro propio entendimiento con nosotros mismos.

La complejidad de la obligación reside en la responsabilidad de la misma, siendo ésta proporcional al peso que estemos dispuestos a cargar, el cual nunca debería ser impuesto, sino deseado en todo caso.

Deseando complejidades aquí nos vemos, pues no habrá complejidad mayor que no podamos solventar.

Echaremos de menos

Cuando todo pase y nada quede nos acordaremos con posible nostalgia de aquellos momentos que ocurrieron, especialmente de aquéllos que nos hicieron sentir. Echaremos en falta el deseo de escribir, pues todo acabará terminando como el fuego consumido por la falta de oxígeno.

Extrañaremos esos deseos de locura por el aprendizaje, quizá incluso de aquélla misma superación, quizá incluso de identidad… Quién sabe cuánto podremos echar de menos. Pues ya extrañamos, y no es extraño, un poco cada día. Hacernos mayores nos obliga a ser más conscientes de nuestro pulso, de nuestro respirar, así como de su propósito encadenado.

Echaremos de menos el agua correr, el sol despertándonos por las mañanas y pasar las horas reflexionando sobre qué echaremos de menos…

Pero no será hoy.

Capítulo 12: Febrero, 2016

2016-02-01T00:00:00+00:00

Viajar a nuestro encuentro

Un vacío continuo y cambiante. Repleto de todos y de nadas, y de confluencias, así como de carencias y, de vez en cuando, de esencias ordenadas.

Viajar nos ha enseñado, entre otras cosas, a comprender mejor que la vida es tan diferente a como estábamos acostumbrados a pensarla… Abrirnos nuevas puertas día tras día con apenas descansos entre medias, donde el sosiego estaba ya contado.

Los mínimos exigibles evolucionan y los máximos posibles desaparecen. No queda rastro del límite impuesto en nuestra juventud sobre lo que somos capaces o no de conseguir. ¿Límites? Qué expresión era esa…

Fronteras que no hacían más que aturdir nuestra visión, impedirnos ver más allá y no dejarnos sentir aquello que de otra forma posiblemente jamás pudiéramos haber accedido.

Viajar nos ha abierto la mente más de lo que jamás pudimos pensar. Estudiar nos ha dado la llave para abrir las puertas que soñamos y soñaremos. Ser nosotros mismos nos ha permitido estar con quienes realmente quisimos y querremos. Soñar nos ha concedido vivir y vivir nos está permitiendo soñar.

Juventud imperdonable

Aquella juventud imperdonable que nos consume junto a nuestro tiempo en un aparente sentido subjetivo que nosotros mismamente decidimos crear.

El paso de los días, de los años…, del tiempo en general. ¡Cuidado!, no nos durmamos más de lo previsto o nos pasaremos de listos, equivocándonos una vez más.

¿Cuándo es el momento? ¿Cuándo debería serlo? El problema no es que ese momento no haya llegado o que parezca no llegar; el problema es no estar despiertos y no salir a buscar aquello que queremos encontrar. Ello quiere decir no estar durmiendo, sino atentos en estas aguas que en cualquier momento nos pueden tragar. No estar dormidos significa aprender a descansar cuando estemos realmente cansados. Significa aprender a nadar, a no dejarnos llevar por la corriente sin razón aparente. Significa aprender a respirar incluso debajo del mismo mar. Significa caminar junto y contra el viento, aprendiendo de él y de su libertad de movimiento.

Una juventud que no perdona es aquélla que, cobarde, se esconde delegando sus responsabilidades al tiempo, a que éste las lleve a cabo sin mayor intención en su entendimiento de unanimidad propia. Carente de sentido, nuestra juventud no perdona. Enfrentándonos a nuestra adolescencia con real sufrimiento ligado, pues quedará en nuestra conciencia todo aquello que para nuestro futuro aún no hayamos superado. ¿Quién decidió ser mayor? ¿Acaso la misma juventud huyó desconsolada? ¿Quién decidió ser aquello o lo otro?

¿Cuándo nos hicimos mayores? ¿Cuándo dejamos de ser aquello que no recordamos? Deberíamos estar satisfechos con nuestras decisiones, especialmente si no hubieron otras intenciones que las de ser; respirando en consecuencia y, como resultado futuro, indultando nuestro pasado, efecto irreversible de nuestro presente en nuestra realidad consecuente.

Religión

Debemos entender la religión como algo natural, propio de una raza frágil que tiende a la mediocridad y donde las mentiras y los engaños pasean sin nuestro permiso, siendo, por tanto, algo intrínseco en nuestra humanidad. Podríamos pensar con todo el derecho: «Pobre aquél que quiera ser de este mundo», pero más pobre será aquél que no lo quiera.

La religión nació fruto de nuestra cobardía, de nuestra incomprensión y de nuestra falta de compromiso, pero sobre todo de nuestra falta de sentido y sentimiento como especie divina.

¿Es acaso la religión un error en sí misma? No lo creo. Creo que la religión es simplemente fruto de otro reflejo más, síntoma que aún nos queda mucho por evolucionar.

La creencia en algo superior a nosotros no es más que un reflejo de nuestra falta de fuerzas en nuestro mundo: nuestra vida. La religión no es más que la consecuencia de la grandísima carencia que existía años atrás. El simple hecho de que hoy en día aún se mantenga y se practique con siquiera algo de euforia lo dice todo: una imagen vale más que mil palabras.

La fe en una u otra religión, sin distinción, revela la falta de confianza, así como de sentido personal e individual. No estamos aquí buscando o señalando culpables. Todos somos parte de nuestro ecosistema, todos somos parte de lo mismo al fin y al cabo.

La religión no es más que una falsa e innecesaria autosugestión de la existencia de una autoridad superior. Hablamos aquí de «innecesaria» desde un punto de vista por encima de la norma: como especie que no entiende que superior a ella misma no existe nada.

¿Entender la religión de otra manera es posible? Por supuesto, no hay más que fijarse en la gente que, aún atrasada y cobarde, entiende este tema. Decimos «atrasada y cobarde» refiriéndonos a que no se atreven a ser por encima de ellos mismos. Por tanto, están atrasados en su potencial respecto a los que sí se atreven a vivir en su merecida grandeza. Muchos simplemente se excusan en que la religión es buena y ayuda; ¡maldita sea la religión! ¡No fue ella, sino nosotros!

La religión es la creencia de que nosotros ni fuimos ni somos. ¡Menudo disparate! Nosotros fuimos, somos y seremos. Fuimos nosotros los que aniquilamos en nombre de la religión. Fuimos nosotros los que ayudamos en nombre de la misma. ¡Somos nosotros y no Dios ni ningún hijo ni profeta suyo los que lo hacemos todo!

¡No seáis miedosos! El mundo puede ser tan maravilloso como nosotros decidamos con nuestra actitud ante la vida, pues no hay mayor secreto que el conocernos, así como ser conscientes de nuestro poder y sabiduría. El uso que le demos será determinante para delimitar nuestros éxitos y fracasos y, por tanto, la calidad y el sentido de nuestra existencia.

¿Cuál es la diferencia entre creer en un Dios y creernos los dioses de nuestras vidas? Es muy sencilla: la autodeterminación, así como la responsabilidad, que ello conlleva. No estamos aquí intentando desmontar ninguna falsedad ni certeza alguna. Todo está en nuestra mente; el rumbo que decidamos será el reflejo de nuestra madurez.

No existirá, por tanto, Dios ni destino alguno que nos pueda dirigir hacia la correcta conducta o verdad absoluta. Dentro de nuestras lógicas limitaciones somos seres ilimitados. Por encima de cualquier creencia estará siempre nuestra libertad, que dirigirá el rumbo de nuestro camino. Por encima de cualquier fatalidad, donde se hace presente la fugacidad de nuestras metas. Por encima de cualquier divinidad o creencia, estaremos nosotros como lo que realmente fuimos, dejando algún día de ser y descansando de tanto trastorno.

Definitivamente

Definitivamente, no somos superhombres, mas no debería ser ése problema alguno, sino nuestro sentimiento sincero hacia su tendencia. Definitivamente, no lo somos, pero creerlo por momentos nos podría acercar a ello.

Destinados de por vida a vivir hasta morir. Destinados hasta nuestros últimos días a una vida incansable de cansancios. Destinados a un destino inmaduro y carente de sentido donde ni él mismo sabría reconocerse.

Definitivamente, deberíamos aprender que el cansancio puede ser en ocasiones inevitable, que nuestra comprensión lectora de la vida puede y debe evolucionar, que podremos ser tanto como podamos imaginar pero, sobre todo, que seremos tanto como demostremos.

Definitivamente, las palabras se las llevará el viento tan y tan lejos… hasta que éstas queden en su abrigado olvido, quedando pues nulo recuerdo y abundante ausencia de las mismas.

Deberíamos decidir escribir un libro, nuestro libro. Escribirlo poco a poco, saborear cada una de sus palabras como nunca antes pudimos haber disfrutado, imaginar cada párrafo como el último que pudiéramos escribir, y llevarlo a cabo como si de ello nuestra vida dependiera.

No somos superhombres y, definitivamente, creer serlo tampoco nos convertiría en ello. Es, por tanto, de donde nace esta sencilla, lógica y absurdamente obvia sentencia: no es la creencia de que algo sea o exista, una prueba siquiera mínimamente concluyente de su veracidad. Creerlo sería ridículamente insensato.

Es cuestión de un sincero sentimiento hacia lo que realmente decimos o pensamos, es decir, de lo que somos. Pues no decir ni pensar conlleva, inequívocamente, al no ser.

Vueltas y más vueltas

Ideas que sin hostal nos inundan y nos acompañan sin percatarnos, sin tan siquiera avisarnos de su llegada. Las mismas que rondarán en nuestras mentes sin fecha advertida de su final instancia.

Sensación desmesurada de preguntas sin respuestas. Inquietud recelosa, envuelta en papel y desconfiada. Enamorada de sí misma pero, de igual modo, de su opuesta, pues no quedará al final nada.

Cálidas emociones sin aviso que infieren en nuestra mente sin permiso y alarmando nuestro ser más prudente, invadiendo así el curso y todo lo que con nosotros llevamos en mente.

Desconfiados por ideas externas que nos atraviesan y nos desvelan en un manantial de incógnitas que no dejan de voltear entre ellas mismas ni de jugar al despiste, así como invitarnos a la locura. Mundo donde los cuerdos parecen ser aquéllos que no conocen o aman el desconocer.

Donde las ideas juegan sin reglas y desordenadas, y arregladas y gobernadas por aquello que aún desconocemos. Todo un mundo de posibilidades que cada día nos sorprende. Nos inunda en su sabiduría y nos acerca a nuestra idea del ser. Nos transforma y nos compone con el molde que nosotros en antaño comenzamos a tallar.

Sospechas certeras que apuntan a más. Opiniones esbozadas que sólo desean nacer para brillar como merecen y morir como debieron.

Advertirnos de qué sucede. Tantos nervios sin nombre aparente que, por supuesto, adrede lo esconden. Debemos figurar y avisar a nuestro Yo, pues se trata de una simple alarma donde la causa se esconde tras un posible desaliento.

Reparar nuestro respirar de nuevo… Imaginar que todas estas vueltas de algún lado nacieron.

Todo está en su sitio, cada cual en su medida ordenada. Las preocupaciones aparentes no tienen por qué ser evidentes ni tan siquiera existentes más allá de nuestras mentes. Dejemos pues de creer aquello o en lo otro sin razón alarmante, pues la única urgencia es saber que en nuestro poder al final todo se encuentra.

Pero bien cierto es que la claridad puede tardar en hacerse presente y que, hasta entonces, es más que comprensible el sentirnos incomprendidos, alterados e incluso asustados. Sintámonos libres de sentirlo, de sentirnos como tales. Pero no olvidemos quiénes somos, por favor; escribamos si es preciso.

Tan fácil

Es tan fácil perderse cuando todo parece estar conseguido… Cuando todo aparenta estabilidad asegurada y nosotros así lo creemos, es cuando realmente todo tiende a la inestabilidad. ¿Dónde quedaron nuestras ganas de prosperar y mejorar cuando todo no estaba ganado? Creo que simplemente nos dormimos o, dicho de otra manera, nos dejamos dormir.

No deberíamos creer que esto es algo negativo, en absoluto. Nuestro primer cometido es el de aprender, especialmente de aquellas situaciones o momentos que no querríamos volver a experimentar. Aprender que las apariencias tienden a engañar a primera vista, pero sobre todo aprender que debemos ser más audaces con nuestra realidad.

Parece que tendemos al descuido si nos dormimos o si tan siquiera dejamos el piloto automático activado porque creemos que ya está todo hecho. No podríamos estar más equivocados. La inactividad es lo que nos acabará destruyendo y formando en aquello que tan alejado queda de la idea del superhombre.

La falta de acción por nuestra parte como personas nos desmorona y nos quita el sentido con todo el derecho. Y es que es tan fácil terminar dormidos sin ambiciones que nos desvelen… Pues tendemos a la mediocridad.

Es tan difícil, aparentemente, mantenernos despiertos en esta realidad donde el sonambulismo predomina…, donde los temas principales parecen carecer de lucidez en su perspectiva y donde la normalidad sugiere haber encontrado un sitio donde hospedarse sin verse obligada a pagar por su estancia.

Las dificultades que encontramos en nuestra realidad no podrían ser más interesantes desde el punto de vista del que las visualice o las sufra, convirtiéndose automáticamente en logros a conseguir y superar. Pues bien es cierto que existen obstáculos e inconvenientes que hacen de esta vida, en ocasiones, una continua tortura donde no podemos evitar desear la evasión hasta que todo pase.

El verdadero problema no son los problemas en sí mismos. La vida está llena de tragedias, de acertijos, de incógnitas por descubrir… El verdadero problema es no hacer frente a aquello que nos produce estas sensaciones incómodas, no encarar nuestras dificultades por miedo a desatar otro conflicto posiblemente interno contra nosotros, pues ¿quién podría contrariarse a sí mismo?

Es tan fácil dormirse deseando evadirnos de todo…, especialmente cuando la vida no parece estar con intenciones de tendernos la mano. Mantenernos vivos es, en ocasiones, tan difícil que cuesta de creer, pues allá donde miremos veremos comúnmente almas apagadas, sin rumbo, que no saben siquiera por dónde van ni hacia dónde se dirigen.

Creo, por tanto, que éstas son y deberían ser siempre nuestras principales cuestiones. Dormir es sano, por supuesto, pero «dormirnos la vida» nos costará la misma. En este contexto, deberíamos permanecer despiertos, pero no es fácil. ¿Quién dijo acaso que lo fuera a ser?

Capítulo 11: Enero, 2016

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

Ambición en un sueño

Ambición es querer más y mejor; es no rendirse, y mucho menos por cualquier cosa.

Ambición por cambiar, aprender y disfrutar creciendo, rompiendo continuos esquemas de verdades a medias. Incluso enteras. Verdades espejismo. Verdades…, ¿cuáles de ellas? ¿Somos acaso nosotros verdad? ¿Cuánto de verdad hay en nosotros?

Ambición por reír y sonreír cada día. Por todo…, por cualquier cosa. Aprendiendo a disfrutar de cada momento, sea salado o dulce, amargo o picante; todos tienen cabida. Al fin y al cabo, todo es cuestión de gustos y entendimiento. Entendimiento y razón, donde la ambición se hace más presente. Donde los versos pueden converger sin tanto miedo como a veces nosotros podríamos temer a la misma vida.

Ambición a la vida, nuestro más preciado regalo, y a nuestro sueño. Nuestra capacidad lógica que nos permite discernir la ilusión de la verdad, la vida de un sueño y los sueños de la verdadera realidad.

Ambición por vivir, por crecer, por reír, por soñar, por hacer, por unir, por crear… Ésta debería ser nuestra verdadera realidad, nuestro proyecto como mortales, pues, al fin y al cabo, sólo quedará aquello que hayamos sido.

Renuncio a Dios

¿Existe Dios? ¿Cómo puedes atreverte a afirmar la existencia de un Dios? Yo lo sé: la ilusión de la ignorancia. La ilusión del desconocimiento y del sentimiento por encima de la razón.

Sin prueba real alguna más allá de las ilusiones individuales, de la necesidad de crear un Dios «por nuestro bien» para acentuar los límites del bien y del mal, pues los cobardes no se atreven a delimitarlos por ellos mismos. Necesitan apoyarse en una idea divina superior a ellos. Se caerían de lo contrario, pues son débiles, además de miedosos, en su realidad.

¡Muéstrame una prueba real! Demuestra al mundo dónde está tu dichoso Dios, demuéstramelo a mí. No he visto más que palabrerías al respecto. No he escuchado más que creencias en vano y experiencias personales sin valor objetivo, especialmente sin posibilidad de ser demostradas. Más allá de aquél que quiera tener creencia en algo inexistente.

Tener fe es querer desconocer. No atreverse a pensar con causa y conocimiento. No atreverse a ser Dios es lo que les induce al fracaso en su creencia y al miedo a su responsabilidad, así como libertad.

Denuncio al falso único Dios y a todo aquél que lo alimente en su cobardía, pues somos nosotros los dioses de nuestra vida. La prueba es bien sencilla: abre los ojos y mira a tu alrededor. ¿Qué puedes ver? Mírate las manos. Atrévete a ser consciente de tu poder, de tu sabiduría, de tu pasado…

Piensa en tu futuro, en lo que está por venir, en todo lo que tienes por delante. Sueña estos segundos con tu tiempo, respira despacio y disfruta de ello porque estás siendo realmente Dios. Lo más grande que existe en tu vida: simplemente tú.

Renuncio al único Dios que nos venden, ya que no hay más Dios de uno que uno mismo. Mírate frente a un espejo por unos instantes, ¿qué puedes ver? ¡Ahí está Dios! ¡Necio! ¡Somos nosotros! ¡Pues nosotros existimos!

Mis propósitos

Está sobradamente generalizado que en los comienzos de cada año se presenten ciertas propuestas para realizar en este nuevo entrante. Sin ir más lejos, hoy es el octavo día de este nuevo año y, desde hace varias semanas, uno de los temas principales de los que hablar son las «propuestas» para este año nuevo.

Por supuesto que es un tema importante, donde animarnos a fijar metas a corto y medio plazo se hace más notable, pero creo que deberíamos hacer algo distinto. Creo que podríamos hacerlo diferente: mirar desde otro ángulo para resaltar el verdadero propósito de nuestras sinceras intenciones.

Nuestras principales resoluciones tienden a ser poco originales. Repetitivas, año tras año. La imaginación se aburre si no juega y no crea, pero sobre todo si no se divierte. ¿Por qué nuestras resoluciones son tan efímeras? ¿Realmente conseguimos alcanzar nuestras metas fijadas estos días del año tan tempranos?

Visualicemos esta misma situación desde otra perspectiva, juguemos con nuestra realidad. Está genial fijar nuevas metas a alcanzar en este año entrante, pero yo prefiero pensar en dónde estaremos el siguiente. Plantearme unos propósitos en un largo plazo. Pensar dónde queremos estar realmente de aquí a dos, tres o incluso cuatro años. Las resoluciones de este año que acaba de comenzar son demasiado sencillas: simplemente disfrutar de él mientras luchamos por convertirnos en nuestra mejor versión.

Nos referimos al proyectar de nuestro futuro, a hacer de cada despertar un propósito en sí mismo, a focalizarnos y mentalizarnos en aquello que realmente tanto ansiamos.

Cambiar los efímeros días a increíbles experiencias. Llenos de vitalidad, fuerza y energía en la búsqueda de nuestro verdadero Yo. A disfrutar en nuestro camino y a encontrar la forma de sentirnos correspondidos, especialmente con nosotros mismos.

A veces

A veces la vida puede parecer extraña, especialmente cuando todo ocurre de distinta forma a como teníamos planeado o pensado.

A veces podemos sentir que no seremos suficientemente fuertes, como si hubiéramos perdido toda nuestra fuerza, o que simplemente ya no queremos continuar más en este juego, el cuál parece que no tiene ningún sentido.

A veces podemos sentirnos realmente mal. Todo lo que hicimos no fue lo que realmente queríamos hacer o el futuro que nos espera parece no tener mejores opciones.

A veces podríamos preguntarnos: «Pero… ¿para qué? Cada día es lo mismo y va a peor. No puedo hacer nada. Esto no funciona, esto está mal…, yo sobro aquí. Nadie podría entenderme». Es normal. Todos hemos pensado estas cosas al menos una vez, especialmente en nuestra infancia.

A veces podemos equivocarnos. ¡Equivocarnos he dicho, por supuesto! ¡Despierta! Somos humanos, ¿qué te pensabas? Podemos llegar a ser increíbles, especialmente porque podemos llegar a demostrarlo. Y no es ciertamente complicado: lo único que necesitamos es paciencia con nosotros. El resto vendrá por sí mismo. Necesitamos simplemente tiempo.

¡Disfruta de tu vida haciéndola única!

Ojos en un recuerdo

Sentir cómo crecen y maduran nuestras ideas, con ansias de lectura y aprendizaje. Sentir el cansancio fruto de una vida activa y llena de vitalidad y energía como se merece. Sentirnos como parte vital de un conjunto, así como parte individual de un todo.

Lleno de emociones y de ideas alocadas que suspiran por nacer. De noches en vela en las que el no soñar está prohibido, donde ellas son las protagonistas de nuestra historia. Si en cualquier momento nos vemos sin ellas, es cuando deberíamos asustarnos y corregirnos rápidamente.

Extrañar un joven fugaz y soñador, pero carente de valentía. Extrañar no haber estado ahí para haberle dicho lo equivocado que estaba y lo mucho que valía. Que era importante y que por momentos lo sería aún más. Que cada día de su vida sería un antes y un después en sí mismo.

Añorar una tierra más cálida que fría, pero tampoco demasiado, y no por la tierra en sí misma, sino por lo que en ella había. Desear ver con otros ojos nuestros recuerdos, nuestra familia, nuestro pasado, nuestro hogar, a nosotros en aquella época tan disparatada…, para poder hoy afirmar estar tan satisfechos…

Viajar. Vivir alejados de todo lo que siempre teníamos a nuestro alrededor nos ha hecho más conscientes de todo aquello que hoy en día tenemos presente, de lo efímero que es todo en general y de lo valioso que pueden llegar a convertirse las pequeñas cosas en particular, y no me refiero simplemente a meros detalles: grandes amistades en la distancia, hermanos pequeños que aún necesitan ayuda para no acabar perdidos, donde la risa aún se alcanza y la esperanza en todo éxito florece en cada consuelo y experiencia.

Recuerdos en un futuro incierto pero certero. Sueños en la inmensidad de los deseos, donde cada pasaje puede brillar sin miedo alguno hasta su plena transformación, dejando por siempre de lado la ficción para convertirse en plena realidad.

Comenzar a plasmar, a crear de donde antes no había nada. Reutilizar, reinventar nuestras ideas y pensamientos, improvisar con todo aquello que no se deje. Romper con las ideas vanas de inferioridad, pero, sobre todo, con el «tú no podrás».

Hermoso detalle el que tuvieron y tuvimos con nosotros hace unos años aprendiendo a ajustar la vela de nuestro barco al viento para que no acabe rompiéndose por mucho que éste sople… Por muy difícil que algo pueda parecer, nada será imposible de guardar por nuestros ojos en un recuerdo.

Donde comienza el éxito

El éxito comienza en uno mismo, en creer haberlo alcanzado antes incluso de haberlo hecho. No por falsas esperanzas, sino porque todo debería apuntar a que así será.

Por supuesto que existen probabilidades de que aquello fijado no se alcance en su totalidad, pero no debería ser por nuestra culpa. Nosotros deberíamos haber apostado y trabajado dura y plenamente en ello.

El éxito es, en parte, matemático: cuestión de probabilidad. Como las calificaciones en un control cuando éramos jóvenes: las puntuaciones de los mismos no medían las capacidades reales respecto al resto de compañeros. Lo que medían eran las probabilidades que existían de nuestro éxito: cuanto más se estudiaba, más probabilidades teníamos de alcanzar una mayor calificación.

Con el éxito en la vida es lo mismo: que luchemos más por obtener una mayor nota, por conseguir aquello que más deseamos o por lograr alcanzar nuestras metas no quiere decir a ciencia cierta ni nos puede asegurar en su totalidad que lo alcanzaremos; pero sí que aumentaremos las probabilidades de que ello ocurra. Siendo posible incluso aprender a controlar ciertas probabilidades, haciendo que éstas tiendan al máximo.

La vida es demasiado compleja como para jugar a su juego. Es demasiado complicada como para hacerle caso. Buscar la felicidad en las dificultades de la misma sin esforzarnos es excesivamente difícil. Por ello debemos crear y aplicar nuestras normas, en su simplicidad, para alcanzar el éxito y, por tanto, nuestra felicidad.

Harto

Sin duda alguna, creo que si preguntáramos a personas cercanas a mí, todos coincidirían en un adjetivo, al menos, común para describirme: paciente. Me considero una persona con una importante paciencia. De hecho, es, sin duda, una de mis principales virtudes: saber que el tiempo no se detiene y que todo acaba siendo alcanzado por el mismo.

¿Por qué soy así? Simple. Estoy harto de escuchar lo poco que valemos o lo poco que somos. Años y años escuchando los mismos sin sentidos. Palabras y situaciones ridículas, demasiado obvias a mi parecer actual, que en su día creí como un ignorante engañando cuando aún no éramos conscientes siquiera de quiénes éramos ni dónde estábamos.

Primero en una iglesia, en unas creencias anormales más que paranormales, típicas de enfermos y carentes de sentido. Miedosos, pero sobre todo engañados a sí mismos. Donde la hipocresía, los celos y todo aquello de lo que tanto se quejan estos cobardes acaban siendo los primeros rasgos en ser desmentidos. «Por sus actos los conoceréis», dijo un personaje que a más de uno le resultará popular; y no le faltaba ahí razón alguna, pues no hace falta fe ninguna para ser feliz. En absoluto. Lo que hace falta es una buena educación donde unos buenos valores de convivencia y respeto mutuo, así como superación personal, estén presentes, y no confesionalidades estúpidas donde todo lo malo y lo incorrecto —según el libro que estemos leyendo— queda previamente establecido, como si de un juego de rol se tratase.

Y segundo en un «castillo», donde el punto anterior primero resalta, destaca y brilla tanto… que llega a abrasar más que diez soles juntos. Donde aprender a sobrevivir se convirtió en el pan de cada día. Donde los recuerdos quieren desaparecer. Donde empecé a descubrir el valor de mi verdadera familia, así como de mis vecinos y de la gente que, día a día, me rodeaba.

Acabé harto de escuchar tantas idioteces sin sentido juntas… que tuve que aprender a ser paciente por obligación impuesta a mi mismo. Como necesidad. Acabé harto de que no se valorase aquello que realmente lo merecía.

—¿Y quién o qué es aquello que realmente merece ser valorado? ¿Todo el mundo, acaso? Pero, sobre todo, ¿en qué medida?

Claro. Evidentemente, todo el mundo merece ser valorado, pero no todo el mundo por igual. Unos valen más que otros. No somos iguales. Todos somos diferentes, ahí está la gracia y parte de nuestro sentido. Es parte de nuestra historia y de nuestro futuro. La monotonía nunca fue nuestro propósito final ni tan siquiera primero.

Estoy harto de que no se valore aquello como realmente merece serlo. Y medir dicha valoración es bien sencilla, así como personal. La respuesta a la anterior pregunta la podremos obtener fácilmente, además de ser apta para todos los públicos. Lo único que necesitamos es tiempo, esfuerzo y una sincera autocrítica. El resto es simplemente paciencia.

Ironías de la vida

Morder la mano que nos da de comer.

Ironías de la vida es que, gracias a «oír, ver y callar», se aprenda a desear gritar a los cuatro vientos y a pensar con mayor claridad. Desear que todo fuera un sueño del cual querer despertar, para acabar añorando toda una infancia que jamás volverá.

Ironías de la vida es aprender a trabajar, largarse de casa y querer de nuevo comenzar. Desear cursar de cero buscando otra oportunidad mientras se extraña todo un tiempo que jamás regresará.

Pertenecer sin querer.

Ironías de la vida es obligarse a ser mayor, a despojarse de una niñez que jamás existió; desear en ocasiones no haber nacido para acabar amando aquello que tanto se odió; acabar amando la vida, demostrando al mundo lo equivocado que se vivió.

Ironías de la vida es acabar luchando a muerte, enfrentándonos sin miedo a todo aquello que pudiéramos temer; desear que todo terminase de una vez por todas; nadar contracorriente y contra todo pronóstico, malamente predispuesto por unas autoridades equívocas; no poder cuestionar sin previo permiso.

Ironías de la vida es subir unas escaleras prohibidas bajo las autoridades más malvadas, erróneas y ruines jamás encontradas. Serpiente mala, miserable y bellaca; su ironía será su condena durante su espera. Que disfrute cuanto pueda, indiferencia es lo que para ella simplemente por mi parte queda.

Ironías de la vida es nuestro arte, tanto efímero en un instante como temporal en un recuerdo. En mi reserva quedará todo aquello que no escriba. Interprétese como se quiera. Nada será para ti sino mi olvido.

Ironías fuiste tú y todo lo que fue contigo. Gracias, ahora te digo, por haber sido testigo y participado en la creación más bella que jamás pudimos realizar: a nosotros, por supuesto, me refiero, tanto a mí como a mi Yo. Pues no habrá mayor ironía en esta vida que el mero hecho de sentirnos mínimamente agradecidos por alguien tan poco merecido como pudiste en su día haber sido.

Gracias. A tu ironía, le digo.

Que no morir

Jugar con la muerte, que no morir. Somos la personificación de nuestra experiencia, de lo que nos intentaron enseñar y de lo que realmente aprendimos.

No es nuestro miedo a crear, sino a ver destruido aquello que creamos, ya sea por el simple paso del tiempo, por el transcurso de la temporada o por nuestro fin existencial como personas.

Jugar a ser nosotros mismos, que no morir. Huir de lo aburrido, ya sea simple o complejo. Tentar a la suerte en su justa medida. En nuestra naturaleza está escrito: «Nuestro tiempo no regresará. Jamás».

Somos perfectas abstracciones de nuestra única realidad. Desde nuestra más sincera complejidad hasta nuestra más absurda sencillez. Realidad donde la nada y el todo podrían converger sin recelos. Donde nadie es nada y todos somos todo al mismo tiempo.

Sería tan aburrido hablar siempre de lo mismo, hacer siempre cosas semejantes o no pensar en nada nuevo… Debemos evolucionar, mejorar nuestros pensamientos y nunca dejar de creer en nuestra persona; como Dioses de nuestra única realidad que somos.

Jugar con la muerte, que no morir. Plantar cara a la vida sin miedo a nuestra evolución, a nuestro poder, a nuestro verdadero ser: a nuestro Yo.

No seremos aptos para el mundo si no estamos predispuestos a estarlo. Somos tanto y tan poco al mismo tiempo como decidamos. En nuestra valentía se esconde nuestro verdadero poder: el poder de cambiar el mundo, nuestro mundo. La cobardía no es más que un síntoma nacido de la falta de confianza. Un síntoma que revela la ausencia de voluntad de poder cuando se debe y se tiene, y la carencia de su conocimiento en sí mismo.

Nos referimos a una cobardía personal e individual. Cobardía en no atrevernos a ser, en no decirnos la verdad por miedo a tener que afrontarla. A veces es nuestro miedo al mismo miedo lo que no nos deja vivir. ¡No podríamos estar más equivocados en nuestro temor!

¡Miedo a morir sin haber vivido, que no a morir!

Cansado

A veces estamos cansados. No es normal en nosotros, pero hay que entendernos. No es algo malo, en absoluto. Se trata simplemente de un síntoma de necesidad de pausa, de sosiego acompañado de reflexión como el que estamos teniendo ahora.

Acostémonos. Leamos un par de horas hasta que no podamos más y durmamos en un sueño profundo. De esta manera ayudaremos a nuestro cuerpo, así como a nuestra voluntad, a reponer todas las fuerzas que necesitamos para que, cuando despertemos, sonriamos como de costumbre.

Se me eriza la piel

Se me eriza la piel cuando en nosotros pienso. En la inmensidad dentro de nuestra inquietud. En ese momento único que parece inmortal cada segundo que dejamos pasar frente a nuestra mirada.

Se me eriza la piel cuando en nuestro futuro pienso. En nuestra vida por delante, en cada segundo, en cada instante que, junto a nuestra persona traviesa, dejamos reposar. Disfrutando de ese instante compartido que a nuestros ojos nace únicamente para ser vivido.

Se me eriza la piel cuando con nosotros sueño. En nuestros momentos vividos y aún esperados. En los momentos compartidos, así como dejados; que nunca son divididos aunque puedan ser anhelados.

Se me eriza la piel cuando para nosotros escribo. Con tendencias poéticas en la misma me refiero. Buscando rimas de la nada hasta que genero, y el resultado en mi mente en ocasiones concibo.

Se me eriza la piel cuando con nuestro pasado juego. A veces en nuestro idioma procuro, más no soy nadie si no maduro, aventurándome incluso con fuego.

Se me eriza la piel cuando con nuestros sueños pretendo. Sin envidiar ciertamente ser nadie, pues seré yo el único que irradie hasta que quede finalmente durmiendo.

Se me eriza la piel cuando termino, cuando empiezo o cuando adivino en cada instante de este tiempo, del que procuro no arruinar. Lo que sí es verdaderamente apasionante es que, a estas horas de la madrugada, sigamos nosotros aquí delante.

Se me eriza la piel cuando en nosotros pienso, cuando contigo sueño, cuando para ti escribo o, simplemente, a tu lado juego.

Inseguridad necesaria

Nos referimos a una inseguridad innecesaria, fruto de un árbol mal alimentado. Donde la tierra ha sido abonada con continuo desorden en un área de escasa vida y de abundantes ironías.

Donde las metáforas florecían por sí mismas sin que nada ni nadie pareciera regarlas, junto a una continua lluvia de desesperación y desconcierto. Donde el término de identidad se desvanecía día tras día y nuestras raíces deseaban ser arrancadas de cualquier forma para migrar a otro lugar.

Sin importar el modo ni la fecha, pues la noción del tiempo se perdía entre horas e incluso días, esperando a que algo cambiara implicando alguna mejora, pues peor riego y abono que el que tomábamos sería todo un reto en su dificultad.

La cosecha obtenida de un mal riego tiende a ser mal fruto.

Pero lo gracioso en este juego de palabras es precisamente que pudimos aprender a ser regados por nosotros mismos. Aprendimos, al menos, a cambiar de abono. Regarnos con distinta agua cada día, experimentar y probar; quitarnos las vendas de los ojos que tanto nos impedían ver.

Aprendimos a aprender.

No basta

La vida no basta con ser vivida. Debemos encararla y no dejar que se nos escape. Cada instante de nuestro respirar no es que no regrese, es que desaparecerá como una mota de polvo en el cosmos para no volver jamás.

Nadar contra corriente, contra nosotros mismos porque, créeme, hará falta. Esto debería ser una batalla. El mayor encuentro personal de nuestra vida, pues no habrá contienda más importante para nuestra persona que la que contra nosotros despleguemos.

Con tacto y comprensión, así como con furia y con pasión. Alcémonos con todo nuestro valor, superemos nuestra pequeñez de una vez por todas, ¡aprendamos a combatir contra nuestra inferioridad como individuos! ¡No basta con simplemente estar ni mucho menos sobrevivir!

Ninguna estrella brillará por sí sola; menos aún si no tiene nada para iluminar. La luz que irradiamos de nada serviría si no es para inspirar ni encender aquéllas que aún están apagadas.

No bastará con un «podría…» o un «quizá algún día…». No debemos permitir caer en la simplicidad de una tenue vida donde la rutina nos domine y no nos deje crear. Inventar un superhombre, empujarnos hacia el continuo éxito, elegir lo que realmente queremos y no cesar en nuestro propósito.

¡Pues no basta la vida con vivirla! Será sinónimo de no vivir si no nos modelamos porque para vivir hará falta algo más que respirar…, y eso es sentir y no dejar de perseguir hasta conseguir ser quien realmente deseamos. Y si antes nunca en nuestro futuro soñamos, es que aún no hemos nacido.

De lo que sí estoy completamente convencido es de que marchitar sin antes siquiera haber florecido será sin duda el mayor error al que nos habremos conducido.

¡No bastará, por tanto, ser sin serlo! ¡Seamos!

No soy

No soy escritor y es ése uno de los motivos por los que me encanta escribir. No me considero tampoco músico aunque pueda hacer sonar de forma agradable un instrumento. Son ya bastantes los años que con la música me comunico, especialmente porque desde siempre me hizo sentir todo tipo de emociones. Recuerdo que también tuve varias épocas en las que componía canciones, pero ello no me hacía compositor.

Precisamente el no ser escritor es una de las cosas que más me gustan: no dependo de nadie ni nadie de mí. No hay razón alguna para tenerle miedo a las palabras, dejando así mismo que jueguen libremente entre ellas, tanto juntas como separadas. Donde el único responsable es el que las lee y las disfruta en su medida y no el que las pudiera pensar o escribir. Es cierto que el autor de las mismas es culpable, ya que fue fruto propio de su cosecha, pero no le temo a nada de lo que escriba. Quizá en un tiempo futuro, cuando mire atrás y me percate de que no fui escritor. Entonces, seguramente, me entenderé.

Me encanta escribir por el simple hecho de no ser escritor, de encontrar aquí un lugar donde poder expresar, sin miedo al qué pudiera ocurrir, lo que desde hace tantísimo tiempo deseaba manifestar. Pude en un pasado experimentar una vida que nadie en su sano juicio elegiría: tantas locuras en tan poco tiempo…, tantas emociones dispares e insanas…, que al borde del caos pude verme. Estaba simplemente aprendiendo a leer y escribir al mismo tiempo. Donde el perdón y la misericordia parecían jugar al escondite cada día. Donde los juegos y sus recuerdos no dibujaban más que una infancia inexistente.

Se me hace complicado hablar en pasado utilizando la primera persona del singular, pues no fui nunca nada o así al menos lo creí; en ocasiones quizá demasiado. Es posible que, al no ser escritor, pueda temblar sin miedo al escribir. O quizá, al no ser escritor, pueda escribir sin miedo al temblor.

No soy escritor y es mismamente el no serlo lo que me da más fuerzas para demostrarme lo equivocado que aún estoy; pero, sobre todo, para demostrarme que aún me falta mucho por conocerme.

A otro nivel

A otro nivel jugamos, donde las miradas giran en torno a un claro entendimiento. Donde la tristeza quedó en una mera ilusión que no consigue hacer sombra a nuestra confianza. Entramos en este mundo sin permiso, donde la claridad no destaca por su presencia. Todo es más bien falto de esencia y tampoco estaría mal algo más de aviso.

Fruto de la memoria, del recuerdo y del olvido. Fruto de nuestra tercera persona y de aquel suceso introvertido. Inesperadamente, a otro nivel pudimos vernos, bajo un precio que se hizo imposible no pagar. Al parecer, predestinados, podríamos pensar, pero el destino es lento y, en ocasiones, realmente esperpéntico. No es siquiera cercano, pero aún así estaremos obligados a ir de por vida con él siempre de la mano.

A otro nivel frente al destino, frente al mundo, frente al camino que algunos escogen ciegamente en su atrevida ignorancia. A otro nivel frente a la misma vida que en nuestro humilde entendimiento aprendimos a discernir de su propia paradoja.

¿Qué es nuestro respirar sino un vaivén de sensaciones no rogadas y un cúmulo de todos y de nadas? ¿A qué nivel estará cada conocimiento sino al que, a nuestro juicio, le otorguemos? A otro nivel entenderemos, mas nunca agradecidos por un final no citado, pero inequívocamente destinados.

A otro nivel, simplemente. Donde las gentes y las mentes vagan en busca de consuelo. Dejó hace tiempo de ser secreto gracias a nuestra real y valerosa sospecha mientras muchos, encerrados en su cosecha, quisieron no darse cuenta de lo obsoleto. De sus errores más que de sus aciertos, donde los recuerdos con preferencias son escasos. Y las calidades de sus estancias quedaron contadas en breves momentos.

Como si nuestro objetivo fuera convertirnos, por encima de todo, en unos profesionales de la vida pasionales, así como racionales; cada cual en su justa medida. Debemos decir ahora sin miedo alguno: «A otro nivel jugamos»; pues somos fruto de la memoria frente al destino en nuestro respirar con otras mentes.

Precisamente

Hay ciertas cosas que aún están mal vistas. Especialmente, temas tabú en un entorno cercano; familiar incluso. Temas delicados a los que nos vemos obligados a tratar con pinzas si no queremos explotar una burbuja que no deja de crecer día tras día en su propia estupidez y sin sentido.

Temas que nacieron sin que, al parecer, nadie se diera cuenta y que al final serán precisamente aquéllos que nos harán cuestionar: «¿Cómo diablos hemos llegado a esto?». Siendo ya demasiado tarde como para deshacer el esperpento, el sin sentido y el caos en lo que ello ha degenerado.

Precisamente por ser un tema tabú es por lo que afecta a nuestro Yo interior. Precisamente porque no somos ni seremos hasta que nos liberemos de todo aquello de lo que queremos ser liberados. Precisamente porque somos nuestros verdaderos dioses y deberíamos amar nuestra vida, así como su continua mejora. Aprendimos a no callar cuando en la normalidad la gente calla; a procurar no limitarnos por los temas tabúes, especialmente por los más delicados.

Y es que en nuestra pasión tendemos a ser creativos, a buscar los límites de nuestras creaciones y, cómo no, a ser nosotros mismos. Es precisamente por ello por lo que escribimos no sólo sobre nuestros pensamientos, sino con ellos, dejando nuestra mente libre en su total albedrío.

Podríamos estar más o menos acertados en algún tema y, por supuesto, equivocados en otros. Como ya deberíamos saber, nuestra mente no es ninguna caja de verdades absolutas. Más bien, debería estar repleta de auténticas y sinceras realidades donde el conocimiento rebose en un mar inquieto y esté sostenido por los pilares del viento y la marea. Donde la objetividad no tenga por qué despegarse del ánimo, ni nuestra existencia del deseo. Donde nuestros argumentos sean tan amplios que cuesten de creer, pero no por falta de argumentos, sino por su increíble conexión entre ellos mismos.

Es precisamente por todo esto: porque podemos y debemos equivocarnos. Nacimos sin aviso y sin permiso. Vivamos justamente aquello que de verdad quisimos y queremos. Muramos pues sin miedo a haber vivido.

Dice mucho de ti

Quizá estéis en lo cierto, quizá estéis equivocados. Quizá todo lo que creáis sea acertado o quizá todo sea más bien falso sin distinción alguna de cuentos. Lo que sí será siempre evidente es que dirá mucho sobre vosotros todo lo que a fe ciega practiquéis.

Más allá de ser pragmático, de ser realista y de concebir nuestra realidad como algo tangible donde el disfrute y el éxito en conocernos estén ligados en la misma. Más allá de ser nosotros, de ser pensadores y de saborear nuestro sentido como lo más importante en nuestra vida, donde el placer resida principalmente en las acciones, así como en las decisiones que tomemos.

Dirá mucho de vosotros, los que, asustados por miedo a vuestra persona, os escondéis. Miedo a lo desconocido: a vosotros mismos me refiero.

¿De qué os sirve ocultaros esperando tener razón alguna en aquello que no es evidente? ¿De qué os sirve creer ciegamente en aquello que no os alza como superhombres, sino que más bien os empequeñece y os insulta en vuestra grandeza?

¡Despertad, os digo! Aquéllos que aún dormís o que dormiréis no entraréis en la grandeza de la sabiduría, no mereceréis vuestro sentido y no seréis dichosos. A aquéllos que dormisteis, pero despertasteis, yo os os doy mi enhorabuena porque vosotros conoceréis vuestro verdadero sentido y disfrutaréis de él, de ser vosotros realmente, todo cuanto merezcáis.

Quizá sea cierto, quizá no. Quizá estemos equivocados, quizá no. Las normas de nuestro juego no deben quedar dictadas más que por nosotros y nuestra experiencia.

A aquéllos que estáis despiertos, a vosotros os escribo. Nunca olvidéis que seréis lo que digáis y diréis todo cuanto seáis. ¡Sed sin miedo!

Caprichoso destino

Me encanta vestir con distintas prendas a los folios aún vírgenes, donde no hay cabida para el miedo y el coraje se vuelve todavía más atrevido. Jugando a ser nosotros mismos, a sentirnos vivos y conscientes de nuestro propio ser y de nuestro Yo, así como de nuestra sonrisa.

Disfrutar cada mañana como si fuera la última. Crecer cada minuto imaginando nuestra insistente evolución, aferrada a nuestra persona y donde los instantes se vuelven efímeras experiencias para acabar transformándose en un todo lleno de sensaciones.

Intuir en cada momento, quietos y en movimiento, lo que al azar le cuesta en ocasiones reconocer: sus instantes en el tiempo. El azar no es más que la probabilidad de que algo posible suceda, haciéndonos partícipes de ello en la medida que nosotros hayamos fijado.

Me encanta la diversidad, así como el coraje que tiene el destino inexistente de hacerse presente cuando menos lo esperamos. En nuestra inmensidad como en nuestra persona. No ser más que fugaces experiencias en el tiempo que marchitarán tarde o temprano.

En nuestra pequeñez se encuentra nuestra grandeza: el poder de nuestra evolución y de nuestro propio cambio, así como de adaptación. Eso es lo que verdaderamente nos debería apasionar de todo esto: nuestra constante en la vida junto al caprichoso e inexistente destino.

La trayectoria de nuestra suerte será en sí misma una paradoja donde el tiempo será el único juez que a todos, sin distinción, nos iguale.

No vivamos aspirando a soñar con que algún día alcanzaremos la vida que nos pertenece; vivamos la vida que en antaño soñamos, sin miedo al ausente, ocurrente e inexistente destino.

Capítulo 10: Diciembre, 2015

2015-12-01T00:00:00+00:00

El arte de la adaptación

Tener miedo a la rutina y a la repetición.

Sentado en el metro deseando llegar a casa para pensar con tranquilidad, y disfrutar de ello con una buena música de fondo. Tengo miedo de no poder terminar lo que empecé, de dejar a medias todo aquello que me gustaría completar o, al menos, relegar en una versión estable.

¿Qué es la filosofía, sino preguntas sobre preguntas o ideas sobre ideas? ¿Hasta qué punto las obviedades son obvias? ¿Quién podría regular o decidir su grado?

Si bien tuviera que escoger una palabra para definirme, sería «improvisación», como el arte de la adaptación.

¿Quién podría asegurarnos que despertaremos mañana? El mañana no existe sin nosotros. Sólo el hoy y el hacia dónde nos dirijamos sin una última meta decidida.

Pensar que el mañana es incierto nos debería obligar a vivir siendo realmente nosotros y no a desvivirnos sin hacer nada, como si nada tuviera importancia. No hay día que no piense en ello, por lo que el hacer del hoy el mejor día de nuestra vida no debería ser una opción. Hagamos del hoy el mejor día de nuestra vida.

Me siento triste con las noticias que sangran, así como alegre en compañía de aquéllos que me hacen disfrutar sintiéndome realmente vivo. Todo es tan complejo… A veces tan hermoso, a veces simplemente nostálgico y melancólico. De la noche a la mañana todo puede volverse frío o cálido en un instante de tiempo.

Estamos ligados a nuestro pasado y vamos destinados a estarlo de por vida a nuestro futuro: de ahí la importancia de nuestras decisiones y sus consecuencias. Sentir, reflejar, aprender, improvisar… Simplemente poco a poco, con mucha paciencia. Sorprenderemos al mundo, especialmente a nosotros mismos.

No sabemos cuándo será la última vez que estaremos, que soñaremos, que respiraremos o que desearemos. Hagamos que nos pertenezca cada momento sin excusas, sin posibles mañanas que nunca lleguen, sin «ya habrá otros momentos» o «no estoy seguro». Es la seguridad en uno mismo nuestra principal llave a la felicidad y a nuestra confianza, así como a su continua búsqueda.

No consiste en encontrar una felicidad intocable e infinita, sino en construirnos para acabar siendo aquello que realmente deseamos en este lugar que nadie decidió y, al parecer, todos nos encontramos, bajo la dicha de un devastador pero dulce tiempo.

No me fue posible sonreír hasta que decidí improvisar conmigo. Y ahora todo es posible.

Moriremos

Moriré. Todos moriremos.
Llantos, recuerdos y anhelo,
como efímeros sentimientos
en un olvidado consuelo.

Morirás. Será sin retorno.
Nada quedará tras tu estela
si tú así lo decidiste.
Tu pasado así lo revela.

Deberemos ser más pacientes
porque en breves no estaremos…
Dará igual si no lo sientes.
Juntos y solos lloraremos.

¿A qué precio sale todo esto?
¿Cuál es el coste de este juego?
Nadie puso normas, es cierto…
Nunca habrá otro «hasta luego».

La memoria nos podrá fallar,
el recuerdo quedará olvidado.
Y toda persona como individuo,
toda quedará a su lado.

Al lado de su olvido, junto a su muerte;
en nuestro futuro a nuestra suerte.
No podremos de nuevo verte
ni tenerte para leerte.

La muerte como verdad absoluta.
El tiempo como igualador divino.
Nosotros… como simples mortales.
Y luego yo. Es decir, tú.

Emociones repentinas

Como un juego que nunca acaba. Como un ciclo en el que nos vemos inmersos sin darnos cuenta. Como un continuo perder y ganar sin retorno.

Como un vaivén de emociones. Como un frío verano y caluroso invierno al mismo tiempo. Como un sin parar de impresiones.

Como ninguno podíamos imaginar. Como todos sospechábamos… y como ocurre al final en todos los capítulos de la vida.

Simplemente, a la espera de que algo suceda, pues nada tiene por qué estar donde nosotros, en principio, así creímos. No es ninguna estupidez pensar en ello: en nada en particular y en todo en general.

Tanto por hacer y por querer, tanto… que a veces simplemente no nos quedan fuerzas de la gran sorpresa que algunos días nos podemos llevar. Y es que no hay que rechazar aquello desconocido por el simple hecho de serlo. Especialmente, en cuanto a emociones se pudiera referir, sin referirme a ninguna en concreto. Pues son tantas y tan distintas entre sí… que para evitar olvidarnos de alguna, simplemente hablaremos desde esta perspectiva abstracta donde todos nos entendemos.

Sin motivo alguno aparente, y es que, ciertamente, no lo tiene. Pues todo está en nuestras ideas y expectativas, en una espera que nadie prometió, sumergido aquí y allá.

Como un sueño al que pudiéramos aspirar, sueño donde una imagen vale más que mil palabras, donde la pasión y la razón van cogidas de la mano, donde nosotros somos los verdaderos protagonistas más allá de innecesarios recelos.

Sintiendo escalofríos en quién sabe cuántos pensamientos que, como pájaros, simplemente desean salir de su jaula para poder volar libremente donde su instinto les guíe y el viento les deje.

Como un juego que algún día terminará. Como un continuo ciclo de toma de decisiones en el que nos veremos involucrados sin quererlo. Como todos pudimos algún día imaginar y sólo unos pocos sospechábamos. Y, como ocurre con los capítulos, todas las etapas acaban terminando. Pero no todos de la misma manera. Aquí radica la principal diferencia entre unos y otros.

Cada uno de nosotros desprenderá diferentes emociones. Hará vibrar de una u otra forma a su alrededor. Emociones que dependerán del todo, del día y la hora, del quién y el cómo.

Somos tan únicos y valiosos, especialmente en nuestra diversidad de emociones repentinas.

No es vida

No tiene por qué decidirse todo ahora. No se trata de eso, pero sí de tener una meta gratificante donde realmente nos gustaría estar. Algo que realmente nos gustaría obtener tras un esfuerzo llevado a cabo. Algo en lo que pensar que nos motive a trabajar en nuestro día a día, a levantarnos y estudiar con más ganas. A pensar más allá de una rutina, donde las cosas simplemente suceden sin que aparentemente nadie tenga por qué variarlas porque, al fin y al cabo, dan la impresión de haber sido siempre así.

Se trata de motivarnos, incentivarnos, cultivarnos y no dejarnos llevar por una vida sin respuestas ni preguntas, sin aprendizajes reales ni nuevas experiencias más allá de la monotonía de lo aburrido.

Y es que está en nuestra mano, en nuestro poder y en nuestra voluntad cambiar para bien o para mal todo esto. Somos nuestro propio Dios, nuestro guía. Somos nuestra última palabra.

De nada sirve una vida si en ella no hay pasión por ser vivida.

El problema de la Navidad

El problema de la Navidad se esconde tras sus falsos valores de perdón, amor y reunión familiar sincero. Estoy deseando que llegue el día de ver esto desde otra perspectiva, de veras, pero hoy en día me es algo imposible, al menos, en mi caso, y no es precisamente algo que dependa de mí.

El problema de la religión es, de nuevo, todos los valores simulados que tras ella se esconden. Ilusiones en bonitas palabras que humanamente luego quedan en un olvido interesado.

Máscaras que constantemente juegan sin permiso. Dobles morales no invitadas. Y tú sin querer saber qué ocurre exactamente de tanto intentarlo sin recompensa. «Oír, ver y callar».

Todo viene de mucho más atrás: años y años de error sin corrección y sin una esperanza en el futuro más allá de un exceso de confianza en una irresponsabilidad, en un inexistente y estúpido Dios. Miserable.

Pero más culpable que Dios y su inexistencia es la carencia que tienen algunos por su excesiva creencia. Más culpable que Dios son los humanos que abusan de él y lo utilizan: modifican a su antojo su significado y lo intentan inculcar como verdad absoluta a sus prójimos. Incompetentes y necios, encerrados en su maldita «fe» hipócrita y desleal. El contexto de nuestras palabras puede variar tanto nuestra intención real…

El problema no es la Navidad en sí misma ni mucho menos su festividad ni la idea de una especial reunión familiar. Es el que engaña y el que se deja engañar. El problema no son las herramientas ni lo que disponemos, sino el uso que con ello hacemos, especialmente, a todos los que nos importan.

Capítulo 09: Noviembre, 2015

2015-11-01T00:00:00+00:00

Al motivo

Siempre hubo una finalidad. Siempre la habrá. Algo que tener en mente. Causa y motivación para nuestros escritos. Nuestras acciones, así como decisiones, regidas e inspiradas en un motivo.

La motivación como base fundamental. Vital, incluso me atrevería a decir, pues sin motivación no se podría vivir, y no hablo de un simple respirar. Ella es quien nos inspira en el crear, a sonreír y a luchar contracorriente si hiciera falta. Nuestra motivación es nuestra inspiración, nuestra musa, la que nos da aliento, la que nos recuerda el valor de lo que estemos llevando a cabo, la que sueña a nuestro lado.

Ideas, ilusiones, tristezas, anhelos… Todo ello nacido de nuestra persona más emocional, que desea sentirse realizada siempre en la medida de sus posibilidades. Para el motivo y por él mismo. Causa y causante de su existencia. Por su elegancia, a ella le escribo: a la motivación.

¿Quién es, si no, la que me inspira a escribirte? Te escribo a ti, que me sugieres y me das motivos de sobra para expresar todo esto que tanto anhelo sacar. De mi motivación para ella misma. Por saber más que ninguna qué desear y en qué medida. Por ser mía. Por cuestionarme y ayudarme. Por ser yo.

Para mi motivo, mi motivación.

Mi proyecto, nuestro proyecto

Nuestro proyecto no tiene por qué ser común ni tan siquiera compartido, pero estoy seguro de que a ambos nos gustaría una misma meta: alcanzarlo. Y es que no hay nada más satisfactorio que lograr nuestros objetivos, desde los que nos propusimos en antaño hasta los que nacieron hace escasos segundos. No importa el tiempo cuando se trata de crearse a uno mismo.

Cambiemos, respiremos y evolucionemos sin perder nuestra esencia, siendo nosotros los que decidamos. No habrá rezo ni credo alguno que nos dirija. Disfrutemos de nosotros y de nuestras decisiones, así como de nuestras equivocaciones; pero sobre todo aprendamos de ellas —¡de nuestras decisiones!—. No nos detengamos, sigamos avanzando. Conseguiremos sorprendernos, no quepa la menor duda.

La madurez no se alcanza con los años, sino con la experiencia.

A la mediocridad necesaria

A la mediocridad necesaria. El antes y un después.

¿En qué medida y con qué certeza podemos jugar a desmentirnos? A pensar de forma inversa creyendo que realmente nos estamos engañando.

¿Cómo podemos no estar tristes ni deprimidos con todo nuestro pasado? Es nuestro foco el único que tendrá la última palabra sobre nuestra actitud y persona. ¿Cómo podríamos sonreír hoy? Pensando en todo lo que aprendimos y estamos llevando a cabo ahora.

El aprendizaje como anticipación. Anticiparse al error, pero sin miedo de que éste último ocurra, y de ocurrir, plantémosle cara sin miedo, pues no será más que una emoción e ilusión; y no habrá ninguna que no podamos controlar.

Tu último día

¿Quién nos puede asegurar que nos levantaremos al día siguiente? ¿Con qué certeza podemos confirmar que mañana despertaremos para continuar con nuestra rutina? ¿Quién se atrevería a ser tan inconsciente como para obviar estas cuestiones?

¿Cómo te gustaría terminar tu último día? ¿A quién querrías tener presente?

Pensemos en ese día por un instante. Miremos hacia atrás. ¿Qué podemos ver? ¿Cómo de satisfechos nos encontramos realmente? ¿Qué nos gustaría haber cambiado? ¿Qué nos gustaría haber mejorado? ¿Qué nos gustaría haber hecho realmente en vez de aquello otro que hicimos?

Sobran las palabras por la grandísima obviedad que a continuación escribiré, pero me temo que debo reflejarlo: esas preguntas deberíamos hacérnoslas todas las noches antes de dormir. Hablarnos, reírnos, expresarnos y escucharnos, pero sobre todo entendernos. Somos como somos, pero, por encima de todo, tenemos que ser quienes realmente queremos ser.

Nadie puede asegurarnos que nos levantaremos al día siguiente. Nadie puede asegurarnos un mañana, salvo nosotros, nuestro esfuerzo y nuestra voluntad de poder. Nuestro último aliento estará determinado por nuestras acciones.

Todo el mundo puede tener ideas. Más o menos geniales. Brillantes, incluso. Pero sólo los pocos que se atrevan a convertir esas ideas en realidad serán los que marcarán la diferencia.

Conocer nuestros deberes, realizarlos y entenderlos para sentirnos realizados.

¡Transcendamos!

Dejar huella

No bastará con que deseemos
y dejemos en días pasados.
Quedará solo si queremos,
así sigamos muy cansados.

Sin fecha póstuma y a la espera,
sin demora… nos mantenemos.
Todo llegará siempre a su hora.
Calma, pues nosotros seremos.

Un poco más, no te retires,
recuerda esos días soleados.
Basta tan solo con que mires:
no más recuerdos borrados.

Busca nuevos retos por hacer.
A altas horas, sin demora.
Debes buscar de nuevo nacer;
que ese momento sea ahora.

Siente, crece, muere de risa.
Vive cada día soñando.
Por favor, no tengas prisa,
con tiempo todo irá cambiando.

Es el tiempo quien nos mantiene
una cuenta atrás que perdura
hasta que nuestro día llegue.
Y nuestra palabra madura.

Concluiré como dijo un maestro:
«El futuro es algo inevitable.
Cuanto antes lo hagamos nuestro,
antes se volverá amable».

Capítulo 08: Octubre, 2015

2015-10-01T00:00:00+00:00

Por encima del bien y del mal

Por encima de todo lo posible y lo imposible.
Por encima de lo real y lo fantástico.
Por encima de los sueños, de la vida y de la muerte.
Por encima de nosotros mismos.
Por encima de tus frustraciones y recelos.
Por encima de todo aquello que un día soñaste y que soñarás.
Por encima de tus sueños y objetivos a lograr.
Por encima del bien y del mal.

Por encima de las emociones, del éxito y del fracaso.
Por encima de la tristeza y de la alegría.
Por encima del llanto y de la sonrisa.
Por encima del cansancio y de la euforia.
Por encima del tiempo, que nos consume a todos por igual.
Por encima del aprendizaje, que, ligado a la superación, 
 nos impulsa a seguir creciendo.
Por encima del bien y del mal.

Por encima de cualquier pronóstico.
Por encima de cualquier pensamiento, igual o distinto.
Por encima de cualquier diferencia.
Por encima de nosotros mismos, del bien y del mal. 
 Allí estaré yo, y tú, si quieres, conmigo.

¿Qué somos?

Déjame este momento para recordar… ¿Qué queremos ser?, ¿una mera ilusión de un recuerdo olvidado?, ¿o más bien queremos convertirnos en una realidad transcendental?

¿Qué es nuestra vida sino un recuerdo de los momentos vividos, de nuestras experiencias que, junto a nuestras expectativas, nos inducen a una constante ilusión de deseo: de desear y de ser deseados? ¿De qué sirve nuestra memoria si no podemos recordar? ¿De qué serviría nuestra mente si no pudiera procesar? Enseñémonos a pensar. ¡Creemos recuerdos!

De nada sirve una vida si no es vivida; nadie vivirá por nosotros. Deberemos aprender, por tanto, a utilizar nuestro sentido común, a vivir usando la mente y la razón.

¡Equivoquémonos! ¡Equivoquémonos mucho!, pero no en lo mismo. Tropecemos con tantas piedras como deseemos, pero no repitamos y, de repetir, hagámoslo con cabeza porque, de lo contrario, quedaremos en una ilusión. Una ilusión que un día estuvo, pero nunca más. Y no quedará anhelo alguno ni deseo por aquél que un día fue sin serlo; es más: nadie lo echará en falta.

Somos decisiones, responsabilidades, así como resultados finales. Todo importa aunque existan siempre diferentes situaciones, cada una con su distinto grado de importancia, nuestra obligación será concluir con una media por encima de sí misma. Nuestro compromiso irá ligado a nuestra experiencia; nuestro deber, sólo a nosotros. Es también cierto que le debemos todo a todos, pero, especialmente, a nosotros por nuestras decisiones, por ser quienes somos y quienes quisimos ser.

Somos el resultado final sin final… hasta que lo haya. Y entonces, ¿qué habremos sido?

Memorias de un recuerdo olvidado

Apenas tengo recuerdos de mi infancia.
Memorias que desvanecieron con el tiempo.
Mención a momentos puntuales con nostalgia.
Deseo de superar aquello llamado ego.

Empecemos por el final: estoy mejor que nunca.

No quisiera que sintiéramos lástima por aquellos días de un pasado que no perdonaba, pero ello no quita que sienta remordimientos, pena por una juventud perdida y, sobre todo, por la cantidad de deseos que perecieron durante el camino.

En aquellos días aprendí mucho. Aprendí como nadie debería aprender. Aprendí cómo no se deberían hacer las cosas. Aprendí que existen siempre distintas versiones de una misma situación. No lo llamaría puntos de vista, sino, más bien, realidades.

¿Qué es la realidad sino nuestra ilusión de entendimiento? ¿Por qué una situación debería ser más real que otra igual de verdadera? La realidad no es más que nuestra percepción. Nuestra verdad, sí, la que creemos única y real, no es más que otra concepción del mundo.

Y es que fueron unos años que, por suerte, desaparecieron. Se desvanecieron en la medida de lo posible, dando paso a un nuevo hoy en el que ahora me asiento, pues mi mente es más sabia que yo y aprendió a olvidar todo eso sin mi permiso. Es gracioso, ya que, en parte, me siento cuidado por mí mismo, y eso me alegra y me alivia.

Después de mis once vino una tragedia que no supe entender, pero tampoco podía prever. Y para cuando quise darme cuenta, ya estaba en mis trece en un sótano donde todo era demasiado tarde: unos pestillos que impedían nuestro movimiento y unas escaleras que no hacían más que bajar… hacia la desesperación. Un día tras otro lleno de incertidumbres, desconsuelo y añoranza. Añoranza por una realidad más allá de promesas y tiempo en vano. Nada parecía real. Las apariencias engañaban.

Un vacío constante y diario. Esperando a que todo cambiara, a ver algún brote verde, daba igual dónde… Todo era insignificante y así consiguió hacerme sentir.

«Las personas no cambian», así como otras poco agradables sentencias que aún, «por suerte», recuerdo.

El mundo está lleno de personas de todo tipo. En aquel momento no podía sonreír, pues con tanta presión a las espaldas a veces es difícil discernir. Tengamos en cuenta que hablamos del periodo entre mis catorce y mis diecisiete años, aproximadamente. No recuerdo apenas nada. Como ya dije, mi mente es más sabia que yo. Ojalá no tuviéramos que leer esto jamás.

Terminemos por el principio: hoy estoy mejor que nunca.

Creo que pienso demasiado

Pienso a cada momento. Creo, incluso, pensar a veces demasiado. Entiendo tantas obviedades como naturales que me extraño cuando percibo que no todos tenemos el mismo entendimiento de lo que es natural.

Pienso tanto que creo no haber pensado nada. No al menos lo suficiente como para decir haber pensado algo, pues aún me queda mucho que pensar. Ejemplificar, razonar, demostrar, enseñar. Todo en lo poco puede ser mucho.

No serás tú el último en leerme ni el primero, pero habrás tenido la suerte de haberlo hecho, y eso es lo que verdaderamente importa. ¿Quién soy yo para escribirte y tú para leerme?

No existe nada eterno, especialmente cuando aquello no es más que un fruto de nuestra ilusión, como nuestros sueños o esperanzas, así como anhelos en nuestros deseos.

Desde temprana edad quise conocer alguna verdad que no se pudiera desmentir ni desmontar. Harto de tanta palabrería… Ahora simplemente sonrío en mi felicidad por haber encontrado una de las verdades más bellas.

Pienso disfrutar de esta verdad absoluta: la inexistencia de lo eterno. Así como disfrutar de todo aquello que exista, pues no hay nada más placentero que el aprender a disfrutar con todo, así como con nada.

No creo en nada por encima del hombre, no creo en nada ni nadie por encima de nosotros. Que nadie tenga miedo a su libertad. Somos individuales y, a la vez, colectivos. Podemos ser todo y, con más facilidad incluso, ser nada. Todo queda a nuestra última elección y yo tengo claro cuál es la mía.

Adoro el anochecer temprano
y su amanecer tardío,
exaltado en sueño sin memoria
como un recuerdo vacío.

Me gustaría mucho ser leído, ¿por qué, si no, escribiría? Quizá por el simple disfrute del pensar. Quizá por la dicha propia en uno mismo.

Con nuestros sueños y en un sueño. Pensador como ninguno, mortal como todos.

Capítulo 07: Septiembre, 2015

2015-09-01T00:00:00+00:00

Dios existe: soy yo, y tú también

Yo soy un no muerto. Soy un vivo —y vaya si vivo: ¡más vivo que nunca!—. Soy una persona que le gusta tener las cosas claras. Carácter, justo.

Soy una persona amante de la vida, del momento y del tiempo, así como de mis circunstancias. No querría jamás ser una persona idolatrada por masas que no son capaces de ver más allá de su realidad.

No entraré en detalles de si es más o menos correcto ser fiel a una u otra creencia. Cada uno que haga lo que quiera —de ahí nuestra libertad—, pero la libertad va ligada a la responsabilidad. Cada uno pasa a ser responsable de sí mismo; cada cual, que vele por sus creencias, que yo velaré por las mías. Y por las mías significa no callarme cuando algo me moleste, cuando algo no sea correcto a mis ojos ni cuando crea que algo no tiene sentido. Entonces hablaré para intentar corregirlo.

Nada de maldad, aquí nadie ha venido a hablar del bien y del mal. Eso ya… que se lo traiga cada uno de casa. Estoy en contra de toda religión que no defienda el valor humano individual por encima de todo, por encima de cualquier entidad divina.

Defiendo que somos lo más grande. Pero ¡atención!, esto no es válido para todo aquél que reniega de su poder, de su voluntad y de su grandeza como humano: de su libertad. A todo aquél, simplemente desearle una estancia amena, pero nada más.

Sin embargo, a toda persona que conozca o quiera conocer su grandeza real, a todos sin excepción, mi ánimo. Porque es la actitud que escogemos ante la vida la que realmente juega en nuestra vanguardia, y es precisamente aquí donde quería llegar: la actitud de cualquier Dios es la del seguimiento a la mediocridad, rechazando nuestro real valor y potencial humano.

Para alcanzar el éxito debemos tener una actitud de superación personal, no de alzamiento en vida para, después de la muerte, tener un encuentro con un supuesto Dios.

Dios existe: soy yo, y tú también lo serás si tu actitud así lo predispone. Porque Dios no es más que una idea, una filosofía, una actitud ante la vida. Creer en un Dios dice mucho de ti, dice mucho al mundo y dice mucho de tu actitud.

Mis ánimos a toda aquella persona que quiera superarse. A toda aquella alma que quiera algún día superarse porque será todo vuestro, seréis Dios y la vida os pertenecerá realmente.

Necesitaba soñar

Porque nada es para siempre, excepto aquello que nos propongamos que así sea. No será cuestión entonces de tener o no razón, de nada sirve aquí. Se trata de proponernos metas por encima de nuestras posibilidades. Es impresionante la capacidad de superación que podemos llegar a demostrarnos aparentemente de la nada. Así como trabajar otra actitud, cuanto más ejercitemos nuestra voluntad, mayor y más precisa será ésta.

¿Qué es la normalidad sino aquello previamente establecido por nuestro entorno y aceptado por la mayoría como norma? ¿Qué es la normalidad sino aquello que nos predispone a lo aún no acontecido? ¿Qué es la normalidad sino aquello que nos encasilla y nos limita como seres libres de voluntad?

Necesitaba soñar… y soñé, así como sigo soñando cada día, esperando seguir haciéndolo hasta mi último aliento. Tuve un sueño: ser yo.

Haremos un antes y un después. Quién sabe a quién le puede llegar esto. Lo mejor del sentido de la vida es que tendrá el sentido que tú elijas.

El arte del pensamiento

La filosofía podríamos entenderla como la más pura y abstracta ciencia en base al subjetivismo que trata de, por encima de dar respuestas, encontrar las preguntas adecuadas. Filosofar es cuestionar.

La finalidad de este arte no debe concluir en ser leída. La filosofía debería buscar ser escéptica y pragmática. Leer filosofía es saludable. Estudiarla incluso, si nos gusta o apasiona, puede llegar a aportarnos un rico nivel cultural, pero ése nunca debió ser su último fin. El arte del pensar no debió nacer para ser leído ni tampoco para ser escrito. Escribir filosofía es inútil si no aportamos ninguna cuestión. Leer filosofía es inútil si no nos hemos dispuesto de herramientas —nuevas o no— para seguir construyéndonos, pues la filosofía es inútil en sí misma: somos nosotros los que le daremos el valor que consideremos.

No existe una verdad absoluta que regule la importancia y el valor de la misma, pues algo tan abstracto, ¿cómo podríamos cuantificarlo? El valor de la duda. ¡Ahí está su verdadero valor!: ¡es ella misma!

Me atreveré a decir que, así como otras ramas fueron concebidas con el fin último de ser leídas, escritas y estudiadas, como, por ejemplo, ingenierías, la filosofía no nació para este mismo fin. La filosofía nació sobre todo para aprender y poner en práctica preguntas, para aprender a cuestionarnos si de verdad estamos haciendo las preguntas correctas.

No nació la filosofía para quedar grabada en un papel o ser leída por otro. Nació de las necesidades básicas de nuestro ser más racional, de nuestra necesidad del saber. La filosofía no nació precisamente para ser contada, sino para ser vivida. ¡Sé tú el que la viva para después contarla!

Tener la razón

Tener la razón es tener argumentos que defiendan y demuestren nuestras convicciones y pensamientos. Tener la razón es ser capaz de acallar, de dejar sin palabras al orgullo por más que éste insista alzando la voz. Tener argumentos sólidos es sinónimo de mente clara, de mente ordenada en sus ideas firmes y sólidas.

Pues la sinrazón tiene sus días contados. Una casa sin buenos cimientos está destinada a ser destruida por ella misma. Estar en lo correcto debe ir más allá de simples palabras o creencias, pues de nada sirven éstas si actuamos de otra manera.

La complejidad del todo debe ser entendida desde la simplicidad para, poco a poco, aprender a entenderlo todo.

Existen tantas variantes y parámetros posibles… que por más que conozcamos, nunca serán suficientes. De ahí la importancia de la demostración, de la razón más allá de simples conjeturas.

Defendamos nuestros intereses, pero siempre con argumentos, y el día que éstos no sean verdaderos cimientos yo os propongo: destruirlos y volver a empezar. Pues edificar sobre algo podrido…, así quedará establecido.

Una mente cerrada donde las ideas no pueden confluir es sinónimo de fracaso. Un lugar cerrado en el que las ideas no pueden converger está destinado al olvido.

Capítulo 06: Agosto, 2015

2015-08-01T00:00:00+00:00

Todo son etapas

Somos etapas y momentos, con sus altos y sus bajos, como todo en esta vida. Somos etapas y momentos. Dependerá de nuestro contexto entendernos para saber si pisar fuerte o delicadamente.

Somos momentos. Sin ellos no podríamos ser, directamente. Somos nuestra descripción personificada. El cómo encaremos nuestras etapas, distintas entre sí, será lo que nos definirá no sólo para el hoy, sino para el mañana, quedando grabado en el ayer.

Somos etapas en constante evolución cuyo principal deber es definir nuestra propia dirección. Nuestro sentido favorable al viento debemos elegirlo nosotros en este viaje tan lleno de sorpresas. En este viaje que da tanto que pensar. En este viaje que, al fin y al cabo, nos da tanto continuamente.

Momentos y etapas tan distintas. Experiencias que merecerían ser plasmadas en una canción, un dibujo o una imagen para su recuerdo. Somos un viaje continuo en un mar donde la marea arbitraria ni perdona ni tiene preferencias. Ser creativos, flexibles, pasionales y racionales serán nuestros deberes.

No podemos asegurar con total certeza con qué etapas podremos encontrarnos, pero sí podremos definir nuestro modo de entenderlas, empezando por nosotros mismos.

Nuevas amistades por conocer, nuevos lugares por visitar, nuevas experiencias por vivir…, nuevos momentos por contar.

¿De quién es el mundo?

¿A quién le pertenece el mundo? El mundo debería pertenecer solamente a aquéllos que lo reclaman, a aquéllos que luchan por él, a aquéllos que lo quieren realmente. Hay quienes están simplemente de paso. Que no esperan un futuro mejor porque piensan que no lo necesitan. Que no saben qué hacer con sus vidas o que no quieren saberlo. No les interesa el mundo, simplemente están. Tiene que haber de todo, pero el mundo no es de ellos, no mientras piensen de esta manera.

El mundo debería ser para los luchadores, para los que no se dan por vencidos, para los que sueñan y no cesan hasta conseguir sus propósitos, y para los que, aún cansados, siguen en la arena por su superación. Debería ser para ellos por mejorarse a ellos mismos, así como a su entorno.

¿Para quién es el mundo? Para los que tienen como objetivo buscar nuevos objetivos. Para las almas inquietas. Para los que consiguen encontrar una razón de éxito en su vida. Para los que, frente a todas las adversidades, consiguen salir hacia adelante. Para los que, a pesar de todas las dificultades, consiguen aprovechar cualquier momento para aprender algo nuevo. Para los que, en vez de pasarse todo el día quejándose, lo pasan buscando soluciones. Para los que no se dan por vencidos.

Para aquellos que buscan cambiar el mundo. A ellos les pertenece. De todos ellos es el mundo.

Tu sentido

«Seamos honestos: no somos nada. Somos lo más insignificante jamás existido. Somos mediocres por naturaleza. Simples humanos. A veces, incluso, crueles, a veces antinaturales.

Seamos honestos, no somos nada. Perdemos el tiempo constantemente. No somos productivos ni queremos serlo. No hacemos nada por solucionar nuestros problemas, así como para evitar los futuros que nos puedan llegar.

Viendo pasar el tiempo, siendo consumidos por él, y nosotros dejándolo pasar. Perdiendo día tras día sin hacer nada realmente productivo, tirando por la borda toda una vida, y nosotros tan tranquilos. Tenemos a nuestro alcance todo. Tenemos realmente de todo. Y nosotros, necios y estúpidos, no queremos cambiar. No nos atrevemos a actuar, a pensar ni a mejorar realmente como especie.

Somos cobardes y, como tales, no llegaremos a ningún sitio el día de mañana. Nadie se acordará de nuestra existencia, de nuestro paso, así como de nuestro nombre. Seremos lo que hemos decidido: nada. Porque así lo hemos querido. En nuestra mano estaba cambiar nuestro destino día tras día, de forma progresiva, y ahora tenemos lo que merecemos.

Somos nada y en nada nos quedaremos».

Si te sentiste identificado por cualquiera de las anteriores afirmaciones, por favor, plantéate de nuevo el sentido, así como el motivo y el propósito, de tu vida; pues no hay nada más triste que la falta de sentido y nada más urgente que encontrarlo.

Al intento le digo

Cobarde, embustero, mediocre.

¿Cómo esperas obtener resultados distintos si siempre utilizas las mismas pautas? ¿A quién pretendes engañar con tu intención? No engañas a nadie más que a ti. Deja de huír de ti mismo y enfréntate, deja de ser un mediocre más.

Deja de engañarte haciéndote creer que lo intentaste y que no pudiste más, pues es falso y tú eres el primero en saberlo. Siempre pudiste, así como hasta tu último día podrás hacer más. Deja de lamentarte entre las sombras. ¡Sal y da la cara de una vez! Deja de culpar al mundo de tus problemas. ¡Sal y resuélvelos!

Deja de esconderte entre lamentos, deja de vivir en la mediocridad. Sal de una vez de tu escondite, donde entraste hace tiempo y ahora no te atreves a salir. «¡Atrévete!», te digo. Pues eres tú el único que podrá hacerlo. Mis palabras quedarán escritas; tu vida quedará en el olvido.

¡Sal! ¡Ahora! Levanta y deja de lamentarte. Conoces alternativas, ¡utilízalas y deja de ser un necio! ¡Insisto!

A ti, a ti te estoy hablando. ¡Levántate y aprende a vivir de una maldita vez! No quiero más intenciones. ¡Quiero actos y demostraciones!

A ti, que me estás leyendo. A ti te digo. A ti, que vienes con intenciones.

Capítulo 05: Julio, 2015

2015-07-01T00:00:00+00:00

Actos y palabras

Me atrevería a pensar que no existe mayor orden que el obrar de acuerdo con el propio y sincero pensamiento. Como si de una joven utopía para la sociedad se tratara. Lo que todos deseamos y sólo unos pocos conseguimos.

Somos lo que hacemos y al final seremos quienes queramos ser. ¿Hay algo más hermoso que vivir la vida que soñamos? Sí, perseguirla.

Estar de acuerdo consigo mismo en el camino, en esta aventura llamada vida, en este trascurso, al fin y al cabo, de etapas tan distintas. Seamos viento, seamos agua, seamos fuego… porque cuando seamos tierra no quedará más que polvo y todo aquello que hayamos marcado a nuestro paso, y será entonces cuando el cómo y el cuándo sonará más que nunca. Aquel cómo y aquel cuándo serán todo lo que quede de nosotros.

Seamos viento: aprendamos a volar y a no limitar nuestra imaginación. Seamos agua: aprendamos a integrarnos, a amoldarnos a nuestro entorno, a estudiar nuestro ecosistema y su funcionamiento. Seamos fuego: ningún obstáculo podrá evitar que alcancemos nuestras metas. Seamos porque cuando dejemos de ser, seremos sólo tierra y recuerdos, y ya estará todo hecho por nuestra parte.

La vida debería medirse en instantes. Hagamos pues que éstos pasen a formar parte de los recuerdos de aquéllos con los que compartimos esos momentos.

Escuchar desapercibido

A veces lo único que necesitamos es escuchar. Pararnos, meditar y observar. Al igual que necesitamos que nos escuchen, necesitamos escuchar al mundo para poder comprenderlo y para demostrarle que estamos con él y él con nosotros.

Me gusta de igual manera pasar desapercibido, pero sólo para el mundo, no para mí. No me gusta la idea de ser famoso o popular. Prefiero los héroes anónimos, así como aquéllos a los que tomaban en su época por locos equivocados por el simple hecho de ir en direcciones distintas.

Me gusta la calma y la tranquilidad. Me gusta disfrutar de mis momentos de soledad, de reflexión, de orden interior. Me gusta entenderme cuando sólo me tengo a mí, pues estoy obligado a escucharme.

Lo que está claro

Todos tenemos momentos de lucidez de vez en cuando. Me gustaría grabar éste para, cuando se me olvide, poder recordarlo o leerlo al menos, para nunca así perderlo de vista.

Hay muchas cosas que aún no están claras, que aún deben madurar o que, simplemente, necesitan tiempo, pero hay una de ellas que tengo bastante clara: no querría trabajar nunca obligado.

No me gusta la idea de un trabajo forzado, en el que por obligación me levante día tras día para hacer algo que no quiero hacer, hacer algo que no me motive ni me ilusione, que no me llene ni me aporte; algo que se quedará obsoleto de aquí a poco, algo que yo no elegí ni querré elegir.

No quiero trabajar, no quiero un trabajo; quiero retos, quiero continuar una formación sin pausa. Quiero desarrollarme como arquitecto y artista en mi profesión. Quiero que cada mañana sea un nuevo reto. Quiero que cada línea que escriba sea inmejorable, así como querré mejorarla al día siguiente porque si otra cosa no, lo que se debería acabar aprendiendo con el tiempo es que, por muy bien que hagas algo, siempre se podrá hacer mejor. Y no es para nada algo negativo, todo lo contrario, ¡ahí está la verdadera mejora!

No me gusta la monotonía, el conformismo ni mucho menos ambas juntas. Estoy enamorado del tiempo. Siempre que puedo intento estar con él. Procuro sacar un rato para disfrutar e innovar junto a él: crear proyectos, llevarlos a cabo, mejorarlos, darles una vuelta completamente, no dejar de pensar en ellos y utilizar un pensamiento lateral que, en ocasiones, los lleva a un éxito rotundo.

Todo es cuestión de propuestas. Aprender tres cosas distintas cada día hará que sean veintiuna a la semana y unas noventa al mes. ¿No crees que merecería la pena intentarlo?

La cuestión está clara: si alguien anterior a ti ha podido, ¿acaso tú no podrías? No te quepa la menor duda. Subiré la apuesta, ¿acaso el que nadie lo haya hecho aún significa que tú no podrás ser el primero en hacerlo?

¿Acaso está todo inventado ya? Nosotros aún estamos en ello, ¿qué crees que hacemos cada día sino inventarnos? Reinventarnos, aclarar las ideas y ordenar el pensamiento. Si otra cosa no, lo que está claro es que quiero ser. Y voy a ser.

Capítulo 04: Junio, 2015

2015-06-01T00:00:00+00:00

Hermano mayor

Tenemos que querer ser el hermano mayor que nos gustaría haber tenido. Tenemos que ser todo aquello que quisiéramos ayer haber sido para que el día de mañana podamos serlo. Necesitamos referencias; más aún cuando se trata de hacer camino. Quisiera haber tenido un hermano mayor para fijarme en él, para aprender de él, para ayudarme con él.

Fue complicado…, pero de nada servía vivir escondido día tras día. Me vi obligado a salir, a observar, a crecer, a luchar. Me hubiera gustado mucho haberlo tenido, especialmente en esos momentos tan complejos y duros como pudieron llegar a ser. Éste es uno de mis principales motivos: ser aquello que tanto anhelé para que aquéllos que lo extrañen no se sientan insignificantes ni vacíos ni engañados ni faltos de vida.

Querría llegar a ser algún día ese hermano mayor que me hubiera gustado haber tenido, ese ejemplo que quisiera seguir, ese al que admirar; sobre todo en tiempos complejos, ayudando así a evitar que ninguno de los míos sienta lo mismo, pues no sólo se trata de nosotros, sino de los que nos hacen ser. Ayudar a hacer camino, aprender a tender la mano.

Terminando los 22

Hoy es mi último día en mis veintidós; mañana comenzaré los veintitrés. Y es que hoy cumplo veintidós, veintidós años completos; a partir de mañana empezaré a vivir en mis veintitrés.

La gente celebra en el día de su cumpleaños que empieza la etapa que justo acaba de terminar. En términos normales, debería celebrar que ya alcancé los veintidós, pero prefiero la idea de celebrar que llegué a la etapa siguiente y que aún la tengo toda para disfrutar. No mis veintidós, sino mis veintitrés. Mis veintidós ya han sido vividos. Ahora quiero más.

Bien es cierto que ahora estaré viviendo con veintidós completos, motivo suficiente de alegría, pero me motiva más la idea del pensar que estoy aún, y eso es lo importante.

Nunca me sentí tan vivo y tan joven como hasta ahora y espero que con el tiempo vaya a más. Más joven y más vivo. Siento que cumplir años es rejuvenecedor. Cumplir años es más que la idea y es todo lo que lleva consigo.

Sea como fuere, hoy cumplo veintidós completos y mañana comenzaré mis veintitrés. Si estás leyendo esto, te agradezco de antemano y con una sonrisa la felicitación. Lo único que te pido a cambio será tu sonrisa de vuelta, así que hazlo porque nunca es tarde para sonreír.

Solitario

Disfruto de la compañía como el que más, pero también de su ausencia. Me encanta estar rodeado, pero también necesito un momento para mí. Cuando estoy siempre ocupado, incluso llego a echarme de menos. Esos momentos de soledad en los que dialogo conmigo sin darle explicaciones a nadie más que a mí. Esos momentos de orden, de reflexión, de escucha y de silencio. Normalmente, con música que me acompaña de fondo. Sonriente ella, como yo.

Notas, así como ideas que gritan sin cesar, al ritmo de recuerdos, de anhelos, de deseos y de futuro. Esos momentos de análisis, de recreación y de incertidumbres, así como de inspiración. De ganas por hacerlo todo y ansias por llevarlo a cabo.

Sueños y emociones que aún deben esperar. Disfrutar de una canción, así como de su significado. Sin letra; la letra la crearán todos esos pensamientos que ella nos hará recordar. Perder la noción del tiempo. Olvidarse de todo y acordarse de nada. Enfocar toda nuestra atención al ritmo de la música, evadiéndonos de todo aquello que podría preocuparnos.

Jugar a escribir, desconectar y conectar de nuevo. Preocuparse y despreocuparse. Es nuestro minuto, démonos un respiro. Paciencia. Nada ocurrirá por sí solo, pero tampoco es un misterio de otro mundo. Simplemente hay que hacer que suceda. Esperar de brazos cruzados de nada sirve. Nunca sirvió. Por eso no se trata de querer ni de soñar, sino de hacer. Aquí estamos para hacer todo lo que esté en nuestra mano y, siempre, un poco más.

Solitario… a veces, que no solo.

Los hay

Los hay quienes se lamentan y quienes viven.

Los hay quienes viven en un miedo constante a la vida y quienes tienen el valor de encararla.

Los hay quienes solamente consumen su tiempo y quienes luchan en su realidad.

Los hay quienes no se dan cuenta del verdadero valor que están tirando por la borda y quienes disfrutan de los pequeños detalles.

Los hay quienes no se atreven a soñar y quienes sueñan.

Los hay faltos de todo y los hay valerosos, sin complejos y llenos de vida.

Los hay carentes de sentido, y no precisamente por culpa de aquéllos que sí lo tienen.

Los hay que desperdician su potencial en excusas que ni ellos mismos llegan a creerse y los que, con voluntad de poder, aprovechan su potencial para cambiarse a sí mismos y cambiar así el mundo.

Los hay y los habrá, pues deberá haber siempre de todo: así está en nuestra naturaleza. La única diferencia será: ¿quiénes seremos nosotros? ¿Quiénes querremos ser?

Los hay a quienes les es imposible sonreír al despertar, así como quienes se acuestan con la sonrisa.

Los hay a quienes deseamos no ver en todo el día y a quienes necesitamos tener al lado constantemente.

Los hay quienes transmiten energía negativa simplemente con su mirada y quienes, al mirar, no puedes evitar sonreír inocentemente por la alegría que transmiten.

Los hay y los habrá, pues está en nuestra naturaleza. Habrá siempre de todo, pero la cuestión será entonces; ¿quién serás tú?

Crear

Una de las razones por las que más adoro mi trabajo es por el simple hecho de poder crear de la nada, y creo que será un sentimiento compartido en muchas otras profesiones.

Me gusta lo que hago, sentirme libre en ello. Sentirse realizado es lo fundamental en nuestro día a día. Crear soluciones, resolver problemas, plantear nuevos retos y alcanzar nuestras metas: ése debería ser nuestro principal trabajo.

Levantarse cada día con la ilusión de crear, de anotar cada idea, cada locura, cada posible solución…, cada intento, al fin y al cabo. Progresar creando y soñando despierto. Hacer realidad todas esas ideas que un día nacieron fruto de la ilusión.

Proponernos nuevos retos, crear más y más. Demostrarnos el «sin límite» de nuestra imaginación, probando así nuestro enorme poder, como su responsabilidad. Aportar al mundo innovando, demostrando y no sólo hablando. Revelar todo lo que podemos llegar a crear. Prosperar en el mundo creando. Progresar nosotros en y con él. Éstas son las razones por las que deberíamos amar nuestro trabajo.

Capítulo 03: Mayo, 2015

2015-05-01T00:00:00+00:00

Al tiempo

¿Hay algo más relativo que el tiempo? Un segundo, un minuto, una hora, un día, una pausa.

Aquel momento… Como nuestra primera vez en aquello que tanto soñábamos, como aquel reencuentro después de tanto tiempo, como aquel resultado que, con tanta satisfacción, vemos florecer fruto de nuestro esfuerzo.

¿Qué es el tiempo? Veo el tiempo como nuestro examinador. El determinante. El que enseña y corrige, aquel que nos involucra directamente en la vida. Podríamos verlo con frecuencia como enemigo o como embustero por su ausencia, pero prefiero verlo como regalo y como fruto de nuestra paciencia. No tendríamos por qué tenerlo y, sin embargo, ahí está, esperándonos.

A veces deseamos que, simplemente, pase. Seamos nosotros los que encaremos al tiempo. En su contra y a su favor. Aprendamos, adaptemos nuestra vela a su viento.

¿Cuánto tiempo nos llevará aprender a vivir? La respuesta es bien sencilla: toda una vida. Por eso no tengamos miedo de equivocarnos, de saborear cada pausa, cada momento, cada instante, cada recuerdo, cada palabra, cada segundo en el que seamos verdaderamente nosotros mismos; de luchar contra nuestro tiempo.

De la preocupación

Un nuevo día, una nueva reflexión. Para ella mis días, pero sobre todo mis noches.

De nuevo, cansado, ¿acaso no deberíamos? Debemos, por supuesto. A veces se avecinan tormentas o, al menos, eso es lo que creemos. Nos acostumbramos a anticiparnos a los problemas creyendo que ya están aquí y, sin darnos cuenta, nos vemos con ellos antes de tiempo sin que realmente existan aún. Es entonces cuando empieza el juego que no debería comenzar.

Anticiparse a la vida está bien, pero abusar de ello puede llevarnos al error, a una incorrecta interpretación de lo que está por venir porque, simplemente, de esto último nunca podremos estar absolutamente seguros. Debemos acercarnos, prepararnos para el porvenir, pero nunca poner la mano en el fuego por ello por el simple hecho de tener la certeza de que algo posible ocurrirá «inevitablemente». Menuda estupidez, ¡pueden ocurrir miles de situaciones hasta entonces! Eso sólo era algo posible, no lo olvidemos.

Las vueltas que dio y dará la vida. La cantidad de variables que rigen nuestro entorno. La cantidad de parámetros, posibilidades, oportunidades… ¡Estas cantidades sí que son incontables!

Existen y deben existir preocupaciones, por supuesto. Debemos aprender a tener responsabilidades y a preocuparnos por ellas. Por eso os digo: «¡No dejemos que unas ideas inexistentes nos arruinen ni un segundo!». Anticipémonos cuanto queramos, pero no nos dejemos llevar por nuestras emociones negativas, fruto de una preocupación por algo que aún no existe y que quizá ni llegue a existir. Ni un segundo malgastado en preocupaciones innecesarias. Suficiente tenemos ya con el trabajo que conlleva la vida, como para estar preocupándonos por situaciones o resultados posibles.

Levanta y enfréntate; puedes ir a por todas. No permitas que un día se vea dañado por una falsa y triste ilusión. No tengamos prisa cuando no sea necesaria. La paciencia es una de las virtudes con más sabor, con más sabores. No nos preocupemos. Sólo necesitamos darnos un pequeño tiempo de reflexión. Todo saldrá bien.

Cada camino distinto

Crea, disfruta, imagina, piensa, sueña y llora de felicidad si es preciso. Exprésate y sé tú. Aprende a ser; eso es lo más hermoso: cada camino distinto, improvisar en y con la vida.

¿Cuál es nuestra pasión? ¿A qué esperamos para hacer realidad nuestro día a día? ¿Hay algo más real que nosotros? No lo creo. ¿Cuántas alternativas tenemos?, ¿cuántas elecciones?, ¿cuántos caminos posibles? ¿Qué camino escogeremos para hoy? ¿Por qué te recordarán hoy? Hoy toca elegir. Salir y respirar todo lo que merecemos. Respirar como si no hubiera un mañana, disfrutar de cada aliento, de cada suspiro.

Cada camino distinto está ahí como si fuera el último. Esa es una de las máximas de nuestra vida: la capacidad de elección. Crear y disfrutar creando nuestro camino. Andando hacia el todo. Hasta donde haga falta. Sin detenernos en nuestra travesía. ¡No te pierdas nada!

Sueña y lucha por ello. Pensemos que el tiempo está en nuestra imaginación, como si se tratara de una ilusión… Esto es lo más hermoso. Escribir para uno mismo, escribir para nosotros. Estamos yendo a buen puerto, estoy seguro.

Estamos aquí para demostrarnos lo que valemos. Ese es nuestro mayor deber: superarnos. Creemos nuestro propio camino, algo único que nadie jamás hubiera podido imaginar. ¿Puedes sentirlo? ¡Eres tú!

A la muerte

Si murieras mañana, ¿qué harías hoy? ¿Y si nadie lo supiera más que tú? ¿Acudirías a alguien? ¿A quién acudirías? ¿Qué harías el último día de tu vida? ¿De verdad crees que podrías hacer algo significante? ¿Escribir? ¿Salir? ¿Pensar? ¿Dormir hasta que todo pase?

¿Y si el día de mañana nos encontráramos con un cáncer? ¿Cambiaría nuestra vida por completo? ¿Y si el día de mañana nos encontráramos sin madre? ¿Acaso no cambiaría igual?

Solo temo a aquello que se nos escapa de las manos, a aquello que no depende de nosotros. No deberíamos temer a la muerte en sí misma, sino al hecho de no haber vivido la vida que quisimos vivir. Temamos lo necesario. No vivamos con temor, pero no olvidemos tampoco que ella siempre está al acecho.

¿Qué hemos hecho en nuestra vida? ¿Por qué seremos recordados? ¿Seremos acaso recordados? Si muriéramos mañana, ¿crees realmente que hoy podríamos hacer algo significante? Estúpidos y necios si no hicimos nada en nuestra vida. Dejemos de lamentarnos por nuestra falta de voluntad, ¡salgamos y busquemos nuestra voluntad de poder! ¡Combatamos a la muerte si es preciso! Dejemos la necedad de una vez por todas, ¡dejemos de no creer en nosotros! Somos los únicos que podemos luchar contra nosotros mismos, ¡venzámonos! Tenemos todas las de ganar a nuestro favor, ¡no nos rindamos!

Vamos a ganar, para eso estamos aquí. Todo saldrá bien, como no puede ser de otra manera. Haremos una vida sublime para que lo que menos nos preocupe sea nuestro último día. Y para cuando llegue ese día —y estemos seguros de que llegará—, será el menor de nuestros problemas. Ese día no deberá importar nada comparado con todos nuestros anteriores. Ese día será, simplemente, el fin de nuestra grandísima etapa como superhombres, de todo lo que hemos sido. Más allá de la simple mortalidad. Más que una idea o concepto. Habremos sido nosotros. Y será entonces cuando seremos más felices porque habremos vivido.

Sintámonos orgullosos cuando, llegado el día, miremos atrás y veamos todo lo que hemos creado, pues no todo el mundo podrá decir lo mismo. Formemos parte de nuestra grandeza, de nosotros mismos y luchemos contra todo pronóstico por algún día llegar a ser superhombres.

Capítulo 02: Abril, 2015

2015-04-01T00:00:00+00:00

El arte de escribir

Me gusta escribir sin pensar en nada. Escribir simplemente. Con el único fin de que, cuando termine, quiera volver a leerlo de nuevo. Me gustaría algún día volver a leerme: quizá me ayude a entenderme mejor…

Escribo para leerme. ¿Puede haber algo más emocionante?, ¿más emocionante que hablar con uno mismo y estar de acuerdo? Estar de acuerdo no solo en lo bueno, sino en lo malo. Estar de acuerdo al fin y al cabo.

La escritura como arte, como libertad absoluta, donde los únicos límites se podrían encontrar en nuestro propio idioma. ¿Y lo hermoso que sería poder escribir en otros idiomas? Espero poder hacerlo en algún año próximo. Todos estos años aprendiendo lenguajes para máquinas y jamás me planteé el hecho de estudiar otras lenguas para personas…, nunca fue mi punto fuerte. Y, sin embargo, ahora en otro país puedo asegurar que es una de las experiencias más maravillosas que le puede pasar a alguien. Empezar desde el principio a estudiar una nueva lengua, un nuevo idioma: entenderlo desde su raíz, disfrutarlo, saborearlo poco a poco: cada nueva palabra, cada nueva expresión.

Complicado y emocionante. Como si se tratara de un juego para niños. La escritura forma parte de un idioma, la escritura es arte.

Quiero leerme. Querría poder leerme con los ojos cerrados, así como puedo soñar con los ojos abiertos. Me gustaría entenderme mejor…, sólo necesito un poco más de tiempo.

De un sueño

Echo de menos a mi familia. Aunque los veré en menos de 30 días, estoy empezando a hacerme la idea de verlos dos veces al año. Y, la verdad, se hace complicado. Ser el mayor de toda una tropa hace que, sin pretenderlo, uno tenga que ser responsable. Necesitamos ser ejemplos.

Tras un pasado tan turbio, me siento afortunado de no haber acabado en ningún otro camino que no sea éste: el mío. No es cuestión de qué habría sido más fácil. No importa aquí nada más que lo que hay: un joven alegre y soñador, nostálgico y apasionado.

Aún espero con ansias ver más lluvia. Aquí, en el norte de Alemania, lo tengo más fácil… Quiero ver más agua correr.

Cada día me despierto con ganas de seguir soñando, de vivir con pasión y de sonreír junto a mi nostalgia, esperando volver algún día y abrazar a mi familia, sin dejar de lado el sueño por el que estoy luchando.

Deseo lograr mis propósitos: quiero seguir adelante. «Lo vamos a conseguir» es la frase que más me repito y con la que esbozo una sonrisa cada día. Soñar no lo es todo, pero es el principio de toda una vida. Aferrarnos a nuestros sueños es la clave del éxito. Siempre con los pies en la tierra.

Tenemos que aprender a movernos, a pedir ayuda cuando sea necesario y a no dejar de intentarlo hasta conseguirlo. La vida nos debe enseñar a ser autodidactas. Debemos ser nuestros propios maestros; fijémonos sólo en los buenos ejemplos.

Dudas

Hay que crear dudas, preguntas e incertezas, pues sólo así se conseguirán respuestas. Debemos querer conocer, querer descubrir nuevos horizontes, retos, aventuras, metas, sueños… Como queramos llamarlo. No importa el nombre, sino lo que hagamos. Con o sin ayuda, pero hagámoslo. Preguntémonos cada día. No dejemos de hacerlo.

No tengamos fe en nada más que en nosotros mismos. Por encima de un posible Dios y de cualquier otra forma de vida, está la nuestra propia. Por suerte o por desgracia, y hasta que no se demuestre lo contrario, nuestra vida es sólo una: ésta. No la desperdiciemos viviendo en una incerteza constante ni una vida en la que no encontremos alegrías suficientes.

Cada duda está para ser resuelta. De la duda nace el verdadero conocimiento y la seguridad. De la duda naceremos nosotros. Dudémoslo todo, pero no vivamos en una duda constante. Dudar como filosofía, donde debemos aprender a cuestionar antes de afirmar. Dudar como método: no infalible, pero sí productivo.

Duda para despejar disfrutando de nuestras elecciones. Equivoquémonos, ¡escojamos! Preguntemos al mundo, a nuestra familia…, a quien queramos, pero sobre todo a nosotros mismos. ¡Nunca dejemos de hacerlo! Cuestionémonos cada día como si nos fuera la vida en ello porque así será. Y seguido a la cuestión, démonos respuestas. Barajemos distintas alternativas, así como sus motivos. Todos los parámetros son importantes. Estudiemos el origen de cada una.

Disfruta porque estarás aprendiendo a vivir. Equivócate, aprende, ¡vive!

En la vanguardia

Deberíamos vivir más en la vanguardia y no tanto en retaguardia. Reinventarnos, imaginarnos siendo aquello que imaginamos. Querernos como aquello que somos y que seremos.

¿Quién dijo miedo? Miedo sólo deberíamos tener a la muerte, no a la vida. Temer a la muerte porque es algo que a todos nos llegará, por suerte o por desgracia. Será algo a lo que tarde o temprano tendremos que enfrentarnos una, dos y tantas veces… hasta que nos toque. Hasta entonces, ¿quién dijo miedo?

«No somos nada», «somos algo insignificante»: qué frases tan equívocas. Somos lo más grande. Es nuestro deber serlo. Vivir en la vanguardia, en primera línea, descubriéndonos a nosotros mismos, así como lo que nos rodea, tan distinto de nosotros. Como si viviéramos en diferentes realidades.

Somos lo más real jamás conocido. Somos únicos y reales. Somos la realidad en su máximo explendor. Cada unidad, así como su conjunto, hacen de uno mismo una obra de arte, una realidad única. Somos y eso es lo importante.

Interpretar nuestra realidad, aprender a luchar en la vanguardia, querer progresar cada día más. Éste es nuestro fin: brillar. Basta con que escuchemos una canción, leamos un libro, estudiemos algo que nos apasione, salgamos a correr, pensemos en aquello que nos motive…, pero no vivamos tanto en la retaguardia.

Riamos y crezcamos. Podemos dar mucho más de nosotros mismos y cada día es una nueva oportunidad para demostrarlo. ¡Vivamos en la vanguardia!

Demostrémonos lo tan equivocados que estábamos no hace tantos años y luchemos en nuestra realidad por brillar cada día más. Brillar para el mundo. Brillar para nosotros.

A aquello inesperado y necesario

Parece complicado. Y podrá así ser hasta que deje de serlo, para darnos cuenta de que aquello fue, simplemente, algo inesperado. Un hermoso viaje de experiencias y de emociones, de completos estrenos y no tan estrenos.

Al principio puede parecer todo tan caótico, extraño y confuso… Pero no es más que algo inesperado. Realmente ha sido una rica experiencia. No nos quedemos solos en casa, la soledad no nos ayudará; salgamos a pasear, el aire fresco despejará nuestras mentes.

El mundo está lleno de oportunidades inesperadas. Deberíamos contar la vida por momentos, por aquellos momentos repentinos que acaban siendo necesarios. La vida vale lo que sus momentos esperados, así como inesperados. Ambos tan necesarios.

El solo hecho de pensar en ello me produce una sensación de dulzura, como si de un regalo se tratase sin motivo aparente. Merezcamos este regalo pues. Luchemos por merecer esto inesperado y necesario en nuestra vida. Hagámonos merecedores de cada regalo. Tomémonos nuestro tiempo, siempre. Pero no olvidemos que estos inesperados nunca dejarán de estar.

Leámonos cuando no sepamos qué decirnos. Seamos nosotros: seamos aquello necesario.

Capítulo 01: Marzo, 2015

2015-03-01T00:00:00+00:00

De un trago

Es curioso ir con el tiempo de la mano sintiendo tantas cosas, tantas emociones distintas concentradas en un instante, y en dos…, sin referirme al mismo tipo de emociones.

Procuro no caer, pero es imposible: antes o después, uno mismo acaba precipitándose; de una u otra forma, todos debemos caernos. Y no hablaré de levantarse. No esta vez. Hablaré de entender, entender los motivos; entendernos.

Más allá de la superación está el entendimiento del motivo. ¿Qué es lo que ha podido fallar? No es cuestión de buscar culpables, sino soluciones. Y antes de buscarlas, buscar su razón de ser. ¿Crees que no la tiene?

No creo en el destino. No creo en nada más que en el valor de cada persona.

Es imposible conocerlo todo, mas no debemos quererlo. Debemos aprender a delegar responsabilidades sin olvidar nunca las nuestras. Debemos comprendernos, entendernos, ser realistas, no perdernos nunca de vista y no abusar del soñar. No abusar de nada al fin y al cabo.

«No te pierdas nada. Disfruta. Pero no te bebas la vida de un trago». Fue este uno de los más valiosos consejos que me dieron mis tíos antes de partir en este viaje.

Entendimiento, búsqueda, comprensión. Nunca viene mal hablar con uno mismo para ordenar las ideas y no dejar que éstas se deterioren.

Todo debería nacer de la pasión y la cordura. Porque toda pasión tiene un mínimo de sinceridad, y la cordura es la que permite mantener viva la pasión.

Todo debería nacer de la sinceridad y de la pasión del querer.

Para la música

Frío… un poco, pero no el suficiente como para dejar de pensar.

Reformas constantes, agitadas y divertidas. Como si se tratara de un juego, el más real que pudiéramos jugar. Subo el volumen, respiro y me dirijo la mirada. No me veo. Me busco, pero no soy yo quién me encuentra, sino ella. Subo el volumen.

No me reconozco, ¿cuánto tiempo ha pasado?, ¿cuándo fue la última vez que jugamos en la calle sin preocupaciones? Ya no lo recuerdo…

Para ella, la música, que me acompañó en los días de lluvia, de sol, de llanto y de alegrías. La banda sonora de la vida, de nuestra vida. ¿Cuándo fue la última vez que le agradecimos su compañía?

Aquella que nos escucha y nos arropa, incluso en las noches más frías. Desnuda o vestida. En la cama o en un paseo. Toda ella. Escúchala y no podrás escapar de sus encantos. Hay que aprender a sonreír y a vivir enamorado, pero, sobre todo, tenemos que aprender a escuchar.

Ella es quien escribe. Profunda, rebelde, furiosa, relajada… Todo es ella. En constante evolución, con afán incluso de superación. Podemos encontrarla ordenada, caótica, con una sonrisa, con los brazos extendidos y con la intención de abrazarnos y no dejarnos ir.

Aprender a escuchar; aprender de ella y con ella.

El arte de aprender

Soñando despierto. Recordando. Pensando en todo lo que ha cambiado, lo que cambiará y lo que se despierta cada día; en cada propuesta que nos hacemos, en cada suspiro.

Enfermar y enfermar de vida. Pensar a escondidas. Imaginar un futuro de ensueño. Un futuro que incluso en nuestra infancia temíamos por el hecho de ser demasiado bueno, un futuro imposible.

Sólo habla. Inténtalo lo mejor que puedas; nadie nace sabiendo hablar. Aprende a hablar. Conquístate. Levántate cada día como si fuera el último. Algunos días simplemente pasan y, cuando ocurren, no nos damos cuenta de que sucedieron. No lo permitas. Enamórate de tu vida: de tu futuro; mientras aprendes a discernir tu realidad, a ver y entender tu entorno y tu ecosistema.

Escucha al sol, es motivo de alegría. Múdate, regálate unos minutos al día para ti. Juega con la vida. Disfruta en tu superación más y más. Rétate como nunca y demuéstrate lo tantísimo equivocado que estabas no hace muchos años. Compárate, contigo el primero, siempre. A todo di que sí, que sí puedes y podrás, pero sin olvidar a decir que no.

¡Anímate! Anímate como nunca lo has hecho. Crece, sueña, vive, sé. Eres todo arte y tu forma de vida dependerá sólo de ti. Es tu actitud la que determina tu calidad de vida.

Escribe si es necesario; si no, simplemente escucha tus pensamientos. Debemos organizarlos a menudo o se acabarán oxidando. Disfruta de ello. Disfruta de ti. Eres todo y lo más grande que tienes. Cuídalo como jamás te hubieras imaginado años atrás… Eres todo arte. Date forma, ten paciencia y, en cuanto menos te lo esperes, estarás hablando.

¡Anímate como nunca lo has hecho! Atrévete a sonreír aprendiendo.

Somos un reflejo

¿Quiénes somos realmente? ¿Qué hacemos cada día? ¿Dónde está el eco de nuestros actos? ¿De qué sirve cada instante? De las más emocionantes preguntas que podemos hacernos a nosotros mismos y que en su día casi me hicieron perder la cabeza…

Me siento afortunado. De todo lo que tengo y de lo que no. Porque aún podré disfrutar del tenerlo cuando de verdad lo necesite. Somos un reflejo de nosotros mismos. No podríamos ser más. Cada día es una nueva oportunidad para hacer todo aquello que aún no hicimos y para repetir todo aquello con lo que nos sentimos completos: nuestras ideas, locuras, metas: nuestro propio camino.

Debemos transmitir al mundo todo aquello que queremos sentir de la vida. Somos nuestra esperanza y nuestra oportunidad. Lo que hacemos tendrá su eco no en la eternidad, sino en nuestro mañana. Cuando nos levantemos cada día y miremos al mundo a los ojos, con una mirada esperanzadora él nos responderá. Él será nuestro reflejo, pues nosotros somos el mundo.

Cada instante es vital. Cada decisión tomada, cada mirada. Para nuestra vida. Para entender el sentido último. Para entendernos.

De nada sirve sonreír sin motivo alguno, pero ¿acaso no tenemos motivos de sobra? Preocupémonos de ser nuestro propio motivo. Es nuestra más importante tarea: sonreír con motivos. Alcémonos alto como nunca, aprendamos a volar, a soñar, a no conformarnos.

Regalémonos un reflejo, una mirada, un aliento, un «¡ánimo!».

Reflejemos lo que queremos ser. Seamos únicos e imprescindibles para nosotros mismos. Diferentes, originales, imprevisibles. Seamos brillantes y nunca dejemos de brillar. Enamorémonos de nuestra imagen, pues somos su reflejo.

Prólogo

2015-01-03T00:00:00+00:00

Del Autor

Este libro es una recopilación de algunas de las breves reflexiones personales que conmigo comparto y que han estado siendo recopiladas durante el transcurso del comienzo de, podríamos decir sin miedo alguno, mi nueva vida emigrando al extranjero, concretamente a Alemania, sin conocer ni hablar en absoluto el idioma y con un nivel bastante limitado del inglés. Afortunadamente, las cosas han cambiado bastante desde entonces.

Este libro nació por sí solo, no es un diario ni tampoco un manual. Es un recopilatorio donde experimentaremos juntos la mente de alguien inconformista que luchó por superarse.

El orden de las reflexiones es por su fecha de escritura; por tanto, podremos apreciar la evolución de las mismas, así como de su prosa y sus distintas expresiones. Abordando diferentes y amplios temas. Es un libro con ideas personales en las que terceras personas ajenas al autor, el cual escribe estas líneas, no tienen por qué sentirse identificadas en modo alguno con el viaje que están a punto de concebir.

Todo este camino no se ha hecho para agradar al lector, sino más bien al escritor. Siéntete, por tanto, invitado a, simplemente, conocerme más de cerca.

De Jesús Valera Reales

El libro que tiene en sus manos es el trabajo de dos años de una de las personas más capacitadas que he conocido y a la que pretendo aspirar más pronto que tarde: mi hermano José María. El motivo real de haber tomado la decisión de escribir este prólogo no es otro que el de poner al lector en situación para que, cuando lea el libro, entienda el contexto de ciertos capítulos.

En el año 2004 y a la edad de treinta y siete años, nuestra madre falleció debido a un derrame cerebral, viéndose mi padre envuelto a cargo de ocho personas —la mayor tenía trece años, José María once y la menor apenas dos meses de edad—. Todos tuvimos que cambiar de colegio y rehacer nuestras vidas.

Tres años más tarde se casó con otra mujer, la cual nos hizo la vida imposible y, tras varias disputas contra nuestra hermana mayor por ver quién era la «mujer de la casa», la mandó a realizar sus estudios universitarios a otra provincia pudiendo haberlos realizado perfectamente en la nuestra. Por orden de edad, su siguiente «objetivo» fue José María.

Con mi padre desbordado por lo que estaba ocurriendo, los enfrentamientos entre ella y nosotros eran cada vez mayores y acabamos relegados —los siete— al garaje del dúplex en el que «vivíamos», cual patio trasero de un castillo. Además, teníamos prohibido por orden y cerrojo subir a donde estaban las habitaciones principales (cocina, salón, baños y dormitorios), salvo cuando fuera la hora de comer o dormir, con todas las «necesidades humanas» que ello implica.

Las discrepancias con ella fueron creciendo a medida que pasaba el tiempo hasta el punto en el que mi padre se vió forzado a tomar la decisión de volver al piso donde nos habíamos criado con nuestra madre: nuestra casa

Tales fueron las secuelas en José María que poco tiempo después intentó sin éxito quitarse la vida en una montaña. Ese fue un punto de inflexión del que salió adelante para, con el paso del tiempo, ser aún más nuestro hermano mayor. Le debo mucho a él, ya que, aunque no pudimos aprender muchas cosas de nuestra madre, los hermanos siempre estuvimos juntos —con él a la cabeza— para apoyarnos y superar las dificultades.

De Francisco Javier

Fue a comienzos de 2016 cuando conocí la idea de la publicación de este libro y cuando me vi en la «obligación» de poner de mi parte para que tal idea pasara a ser una realidad. En todo este tiempo, he intentado aportar todo lo que buenamente he podido ofreciendo sugerencias y correcciones a nivel gramatical y ortográfico.

Han sido muchas horas de búsqueda, reflexión y conversación (con risas de cuando en cuando) por querer ayudar al autor a expresar sus ideas de una mejor forma. Y todo esto bajo el desinterés que hay detrás de estos dieciséis años de amistad.

Complementando el prólogo anterior, una pregunta tan sencilla como impactante que me hizo José María una mañana de clase a los pocos días de regresar al lugar donde los ocho hermanos se criaron: —¿Sabes qué es despertarte un fin de semana, ver que es de día y que está lloviendo, y poder quedarte en la cama?

Índice

2015-01-02T00:00:00+00:00

Prólogo
- Del Autor
- De Jesús Valera Reales
- De Francisco Javier

2015

Capítulo 1: Marzo
- De un trago
- Para la música
- El arte de aprender
- Somos un reflejo
Capítulo 2: Abril
- El arte de escribir
- De un sueño
- Dudas
- En la vanguardia
- A aquello inesperado y necesario
Capítulo 3: Mayo
- Al tiempo
- De la preocupación
- Cada camino distinto
- A la muerte
Capítulo 4: Junio
- Hermano mayor
- Terminando los 22
- Solitario
- Los hay
- Crear
Capítulo 5: Julio
- Actos y palabras
- Escuchar desapercibido
- Lo que está claro
Capítulo 6: Agosto
- Todo son etapas
- ¿De quién es el mundo?
- Tu sentido
- Al intento le digo
Capítulo 7: Septiembre
- Dios existe: soy yo, y tú también
- Necesitaba soñar
- El arte del pensamiento
- Tener la razón
Capítulo 8: Octubre
- Por encima del bien y del mal
- ¿Qué somos?
- Memorias de un recuerdo olvidado
- Creo que pienso demasiado
Capítulo 9: Noviembre
- Al motivo
- Mi proyecto, nuestro proyecto
- A la mediocridad necesaria
- Tu último día
- Dejar huella
Capítulo 10: Diciembre
- El arte de la adaptación
- Moriremos
- Emociones repentinas
- No es vida
- El problema de la Navidad

2016

Capítulo 11: Enero
- Ambición en un sueño
- Renuncio a Dios
- Mis propósitos
- A veces
- Ojos en un recuerdo
- Donde comienza el éxito
- Harto
- Ironías de la vida
- Que no morir
- Cansado
- Se me eriza la piel
- Inseguridad necesaria
- No basta
- No soy
- A otro nivel
- Precisamente
- Dice mucho de ti
- Caprichoso destino
Capítulo 12: Febrero
- Viajar a nuestro encuentro
- Juventud imperdonable
- Religión
- Definitivamente
- Vueltas y más vueltas
- Tan fácil
Capítulo 13: Marzo
- Se hace más notorio
- Es cuando
- En la montaña
- Saborear
- Odio a Dios
- Y no bastará
- La complejidad de la obligación
- Echaremos de menos
Capítulo 14: Abril
- Aparentar o ser
- Tantas
- Constantes
- Hablemos de nuevo
- Es tiempo de
- ¿Qué podría ser?
Capítulo 15: Mayo
- Al final
- Haber perdido
- ¿Somos realmente?
- La historia
- Números
- Tratando de entendernos
Capítulo 16: Junio
- ¿Y si…?
- ¿Quién nos recordará?
- Cuestión de tiempo
- Comenzando los 23
Capítulo 17: Julio
- Entendimiento
- Eterno retorno
- Disposición
- Mientras pasa el tiempo
- Algunos
- Lo más difícil
Capítulo 18: Agosto
- Vuelvo a ser yo
- Con otros ojos
Capítulo 19: Septiembre
- Sólo se vive una vez
- Jóvenes e inocentes
- Terminando para comenzar
- El día de mañana
Capítulo 20: Octubre
- Entropía
- El futuro
Capítulo 21: Noviembre
- Dulces recuerdos
- Incluso
- Nuestro mayor error
Capítulo 22: Diciembre
- Esclavo de la muerte
- Singularidades
- La educación

2017

Capítulo 23: Enero
- Falsa libertad
- Vivir ocupados
- La importancia
Capítulo 24: Febrero
- Nuestra vida
- Hábitos
Capítulo 25: Marzo
- La verdad
- Sin final
Capítulo 26: Abril
- El valor
Capítulo 27: Mayo
- Mediocridad enmascarada
- Tendencia
Capítulo 28: Junio
- Percepciones
Capítulo 29: Julio
- No hablo de autoayuda

2025

Capítulo 30: Diciembre
- Nueve Ramas

Acerca de este libro

2015-01-01T00:00:00+00:00