Chemaclass - productivity

Recorta la Factura de Tokens

2026-06-26T00:00:00+00:00

Toda sesión agéntica quema tokens en dos direcciones a la vez. El agent te responde, y la terminal escupe su output. Las dos cosas pasan por el mismo context window, y las dos tienen fugas.

Estira la sesión lo suficiente y chocas con el muro. Las respuestas empeoran y la factura sube.

Mismo modelo. Mismos prompts. Factura más ligera.

Abre cualquier transcripción de sesión y los bloques más grandes no son tus prompts:

Respuestas del agent: cháchara, vacilaciones, repeticiones, “Sure! Happy to help…”.
Output de herramientas: logs de npm install, muros de texto de git status, volcados de grep con rutas completas.

Las dos herramientas de abajo atacan una de esas cosas cada una. Caveman se ocupa de lo que el agent responde. RTK se ocupa de lo que la shell manda de vuelta.

Caveman recorta la salida #

Caveman es un Agent Skill. Ejecuta /caveman full una vez y el agent deja de rellenar sus respuestas: sin artículos, sin relleno, sin cháchara. Los fragmentos están bien, y los términos técnicos se mantienen exactos.

Instalación:

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

Lo que muere:

Artículos: a, an, the.
Rellenos: just, really, basically, actually, simply.
Cháchara: sure, of course, happy to.
Vacilaciones: might, perhaps, it depends.

Lo que sobrevive:

Bloques de código, errores exactos, rutas de archivo, comandos.
Avisos de seguridad y operaciones destructivas (el skill se aclara solo).

Modo normal:

Sure! I’d be happy to help you with that. The issue you’re experiencing is likely caused by an off-by-one error in your token expiry check. The middleware compares the current time using < when it should really be using <=. Here’s the fix:

Modo caveman:

Bug in auth middleware. Token expiry check use < not <=. Fix:

Mismo fix, y el bloque de código que viene después es idéntico. Lo único que encoge es la prosa de alrededor, hasta más o menos un cuarto.

Hay tres niveles: lite, full y ultra. Empieza en full, porque ultra se lee como un telegrama. Si una respuesta te queda demasiado seca, escribe normal mode y se relaja.

El agent no pierde inteligencia cuando le quitas la cháchara.

RTK recorta la entrada #

RTK (Rust Token Killer) envuelve los comandos que ejecuta tu agent. Un hook reescribe git status como rtk git status por detrás, así que no hay nada extra que teclear ni overhead que notar.

Instalación:

brew install rtk
rtk init -g # instala el hook que reescribe los comandos

Si más tarde rtk gain da error, se ha colado otra herramienta con el mismo nombre; instala desde el repo.

La versión envuelta quita el ruido antes de que llegue al agent: códigos de color, separadores repetidos, banners de npm install, timestamps verbosos.

Aquí tienes el mismo git status, en crudo y luego envuelto:

$ rtk proxy git status
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
 (use "git add <file>..." to include in what will be committed)
 content/blog/new-draft.md

nothing added to commit but untracked files present (use "git add" to track)

$ rtk git status
* main...origin/main
? Untracked: 1 file
 content/blog/new-draft.md

La misma información en la mitad de líneas. En un repo con movimiento la diferencia solo crece, porque decenas de untracked files, pistas de rama y líneas de instrucciones colapsan en un solo bloque pequeño.

rtk gain # ver cuántos tokens te ha ahorrado
rtk gain --history # desglose por comando
rtk discover # escanea tu historial de agente buscando ganancias

RTK reporta 60-90% menos tokens en los comandos de desarrollo habituales. Ejecuta rtk gain tras un uso real para ver tu propio número.

Nunca toca el payload, solo el ruido a su alrededor, así que los errores y los stack traces salen exactamente como son. Si algún filtro alguna vez se come algo que de verdad necesitas, sáltatelo en esa llamada con rtk proxy <cmd>.

El output que tú no lees sigue siendo output que el modelo tiene que leer.

Por qué la combinación suma #

Por separado, cada herramienta ayuda un poco. Júntalas y el efecto se multiplica, porque atacan mitades distintas del mismo bucle. Un turno va así: tú escribes el prompt, el agent piensa, ejecuta un comando, la terminal responde, el agent lo lee y luego te contesta. RTK encoge la mitad de la terminal y Caveman encoge la respuesta, así que cada turno sale más barato y caben más en una misma ventana.

Aquí está la prueba real, en un plan de 100 $/mes. Antes de añadirlas llegaba al límite semanal continuamente, a veces con un solo proyecto. Ahora corro varios proyectos en paralelo y el límite casi no aparece. El plan no se hizo más grande; las sesiones se hicieron más pequeñas.

Instálalas una vez y olvídate #

Las dos instalaciones son globales, y las haces una sola vez. A partir de ahí sigues escribiendo git status, grep y npm install igual que siempre. El hook los reescribe por ti y Caveman se activa solo, así que no hay hábitos nuevos que aprender.

¿No sabes por dónde empezar? Elige la fuga que más te duela ahora mismo. Si el problema son las respuestas largas en cada arreglo, empieza por Caveman. Si son las inundaciones de output de grep y npm install, empieza por RTK. Añade la otra cuando te apetezca, que no se estorban entre sí.

No mejoraste el modelo. Dejaste de malgastar su atención.

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.

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.

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, 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 #

Trata 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. Es trabajar con la puerta del garaje abierta, aplicado al código.

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 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. Construye una cultura de claridad, responsabilidad y confianza, donde los desarrolladores se mueven rápido sin dejar de ser reflexivos.

Si estás cansado de colas lentas de PR y aprobaciones sobre-ingeniadas, pruébalo en tu próximo cambio. ¿Quieres profundizar? Lee el post original de Rouan Wilsenach.

Ajusta la revisión al riesgo. Sé dueño de lo que mergeas.

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 #

¿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 #

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 #

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 #

Bucle sin Fin

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

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

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

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

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

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

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

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

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

Indefensión Aprendida

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

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

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

Experimentos #

Un aula con diferentes evaluaciones #

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

Original: Descargas eléctricas y arneses #

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

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

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

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

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

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

Optimismo aprendido #

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

¿Cómo lo practicas? #

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

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

English #

Español #

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 #

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?”

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/.

¿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.

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 #

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 #

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 #

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

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

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

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

¿Qué es OSS? #

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

OSS es software público, abierto al mundo.

Beneficios #

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

Para empresas #

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

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

Para contribuidores individuales #

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

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

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

Contribuyendo a OSS #

Empezando con GitHub #

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

Proyectos personales #

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

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

Mis proyectos personales #

Activos:

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

Inactivos:

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

Abandonados:

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

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

Mis contribuciones a organizaciones OSS #

Activas:

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

Abandonadas:

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

Compartir Conocimiento e Impacto #

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

Posts del blog #

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

La belleza del OSS #

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

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

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

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

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

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.

¿Quién se ha llevado mi queso?

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

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

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

Mis lecciones favoritas del libro #

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

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

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

El Proceso en Sí Es la Meta

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

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

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

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

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

¿Cómo me mantengo enfocado? #

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

Auto-reflexión #

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

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

Deportes #

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

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

Libros #

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

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

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

Trucos personales #

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

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

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

Cómo mejorar tus hábitos #

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

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

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

Enlaces interesantes #

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.

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:

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

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

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

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

Estructura de la charla #

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

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

Considera tu audiencia #

Cuando prepares tu presentación, pregúntate:

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

Introduce el tema #

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

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

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

Crea una línea argumental #

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

Construye una conclusión #

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

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

Diseño y maquetación #

Escribe menos, habla más #

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

Fuentes grandes #

Si tienes código que presentar, considera:

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

Rol de la audiencia #

Responsabilidades del asistente #

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

Preguntas internas #

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

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

Hábitos Atómicos

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

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

Aprendizajes #

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

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

El poder de los hábitos

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

Aprendizajes #

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

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.

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.