The Pragmatic Programmer .

Consiste en pensar más allá del problema inmediato, siempre intentando situar el
problema en su contexto global, siempre intentando ser conscientes del todo (bigger
picture).

Aquel que sólo corta simples piedras debe siempre tener las visiones de las catedrales.
--Credo de los trabajadores de Quarry.

Un programador pragmático se equivoca, como todos los programadores, pero

reconoce sus errores sin excusas. No tiene miedo ni vergüenza de admitir los errores o
el desconocimiento. Las cosas siempre terminan, en algún momento, por ir mal. Las
entregas se retrasan, aparecen problemas técnicos inesperados, … y en ese momento,
aparece la grandeza del programador pragmático que de una manera honesta y
directa, reconoce su parte de culpa.

La comunicación es un aspecto muy importante para nosotros, ya que tenemos que

saber comunicar varios niveles con los miembros del equipo, algo que se dificulta en
una idea, por eso es de vital importancia que tengamos en claro primeramente lo que
queremos hacer y después lo que tenemos que decir.

1. ¿Cómo es un programador pragmático?.

◦ Early adopter/Fast adapter: Tiene un gusto por la tecnología, le gusta entender

las cosas. Ante algo nuevo, lo aprehenden, lo atrapan, lo entienden, rápidamente, y
lo integran al resto de su conocimiento. Tienen confianza, nacida de la experiencia.

◦ Inquisitivo: Tendés a hacer preguntas. Eso está bueno, ¿cómo lo hiciste? ¿Tuviste
problemas con esa biblioteca? ¿Qué es eso de BeOS? que escuche hablar? ¿Cómo
están implementados los enlaces simbólicos? Sos un baúl de conocimientos
diminutos, cada uno de los cuales puede afectar decisiones incluso dentro de años.

◦ Pensador crítico: Raramente tomás las cosas como te las dan, sin buscar primero
los hechos. Cuando los colegas dicen: «ésa es la manera en que se hacen las
cosas», o un vendedor promete la solución de todos tus problemas, vos te olés un
desafío. No hace algo sólo porque sea “la forma de hacerlo”.

◦ Realista: Tratás de entender la naturaleza subyacente de cada problema con el

cual te enfrentás. Este realismo te da una buena sensación de cuán difíciles son las
cosas, y cuánto tiempo van a tomar. El entender por vos mismo que un proceso
debiera ser difícil o que tomará un tiempo para resolverse, te da la energía para
mantenerte resolviéndolo.

◦ Jack of all trades: Se esfuerza para familiarizarse con un amplio rango de

tecnologías y ambientes, sistemas operativos y lenguajes, utilitarios y
metodologías. Aunque su trabajo actual sea el de un especialista, siempre busca
moverse y aprender nuevas cosas.
 2. Consejos para ser pragmaticos.

(Primer Apartado)

◦ (1) Cuida de tu arte (Care about your craft): Se toman el trabajo de

interesarse en lo que hacen, en esmerarse en la obra que están creando.

◦ (2) Piensa! Sobre tu trabajo (Think! About your work). Pensar, siempre
pensar, en especial sobre el trabajo que hacemos. Siempre tratar de meditar,
entender, ver más allá de la técnica, buscar las razones, discutirlas, exponerlas
a la luz y a la crítica. Si esto te suena como mucho trabajo, entonces estás
exhibiendo la característica de realista. Esta actividad va a tomar parte de tu
valioso tiempo, tiempo que ya está seguramente bajo una tremenda presión. La
recompensa es un mayor involucramiento con el trabajo que más apreciás, una
sensación de dominio y maestría sobre un creciente rango de temas y el placer
de sentir un mejoramiento continuo. En el largo plazo, tu inversión de tiempo se
pagará a medida que vos y tu equipo sean más eficientes, escriban código que
es más fácil de mantener, y ocupen menos tiempo en reuniones.

◦ (3) Ofrece soluciones, no des excusas baratas (Provide options, don’t

make lame excuses). Y antes de dar excusas, mírate a un espejo, y date a
ti mismo las mismas excusas ¿tienen algún sentido? ¿te sirven de algo?
¿van a arreglar o mejorar algo? Pues entonces ahórratelas, y busca
soluciones. Quizás el uso de prototipos, la refactorización, una mayor
cobertura de pruebas, etc .. habrían evitado el problema.

El Gato Se Comió El Código Fuente: Parece la excusa de un niño de primaria

cuando le piden los deberes en clase.

Entropía del Software (Segundo Apartado)

La entropía se relaciona con el orden dentro del caos, y más directamente, se

define como la cantidad de desorden de un sistema.
Para evitar que nuestro código huela mal y se deteriore poco a poco, requiere
de un cuidado continuo para evitar la tendencia al desorden.

Es un proceso continuo.

Un turista visitaba el Colegio Eton en Inglaterra y le preguntó al jardinero

cómo hacía para mantener el césped tan perfecto. «Es fácil», le respondió,
«Sólo tiene que cepillar el rocío cada mañana, recortarlo día
por medio y pasarle el rodillo una vez a la semana.»

-¿Eso es todo?, preguntó el turista.

«Seguro», replicó el jardinero. «Haga eso durante 500 años y también tendrá
un hermoso césped.»

El césped excelente necesita de pequeños cuidados diarios, y así pasa con

los excelentes programadores. A los consultores de gestión les
gusta usar el término kaizen en sus conversaciones. «Kaizen» es un término
japonés que captura el concepto de realizar continuamente pequeñas
mejoras. Se lo consideró una de las razones más importantes para las
dramáticas ganancias en productividad y calidad de las fabricaciones
japonesas y fue copiado ampliamente a lo largo del mundo. Kaizen se aplica
a los individuos también.

◦ (4) No vivas con ventanas rotas (Don’t live with broken windows).

Mediante esta moraleja, los autores comparan una aplicación con un edificio, en
tanto que cuando un edificio, estando deshabitado pero manteniendo una
apariencia visual agradable, se mantiene en buen estado. En cuanto se rompe
una ventana, y aparecen pintadas, en poco tiempo, todo el edificio se deteriora,
se rompen todas las ventanas, y pasa de estar deshabitado a abandonado.

¿Qué tenemos que hacer nosotros como programadores pragmáticos? Cuando

se rompe una ventana (una funcionalidad) de nuestra aplicación, tenemos que
arreglarla. Seguro que alguna vez has visto algún bug en la aplicación que estás
desarrollando, pero por no tocar, o no perder el tiempo, o porque no lo has
provocado tú, no te has parado a arreglarlo. Mal. Muy mal. No hay nada peor
que mirar hacia el otro lado. Ese no es el camino.

Puedes pensar que ya vendrá alguien y lo arreglará, pero si todos pensamos así,
el fallo estará ahí siempre. ¿Y qué decir de una aplicación que constantemente
falla? No apetece nada ponerse a arreglarla, más cuando todo el código es un
caos, no hay dos lineas iguales, diferente nomenclatura, sin convenciones de
código. Para evitar una aplicación con todas la ventanas rotas, hay que
mantenerlas limpias desde el principio. Lo que no se ensucia, no hace falta
limpiarlo. Dicho de otro, quien no mancha, no tiene que limpiar. ¿Está claro?
Pues entonces desde un principio, vamos a ser limpios y cuidadosos con nuestro
código. Sin chapuzas ni trozos de código para salir al paso (Si es necesario haslo
orientado a objeto, bien encapsulado). Siempre con la mejor solución. Al menos,
la mejor solución que nosotros conocemos.

Sopa de Piedras y Sapos Hervidos (Tercer Apartado)

Comienza con un cuento muy bonito sobre unos soldados hambrientos que llegan a
un poblado donde los aldeanos también pasan hambre y son reacios a abrirles
la puerta para darles de comer, pero los soldados son muy listos, y se
aprovechan de la curiosidad de los aldeanos para obtener a
partir de una sopa de piedras un poco de su preciado alimento. A partir
de lo que aporta cada aldeano, consiguen crear una sopa “rica, rica”.

Los aldeanos no sabían que si unían sus recursos a los de sus vecinos, iban a
mejorar, tanto ellos mismos como personas cómo sus recursos (el
producto final).

◦ (5) Sé el catalizador del cambio (Be a catalyst for change).

Nosotros como pragmáticos que somos, tenemos que ver la necesidad de

dar ese empujón a nuestros compañeros para mejorar. ¿Cuantas veces te
has dicho “que mal se hacen las cosas en esta empresa”, y no has hecho
 nada para arreglarlo? Pues si has sido capaz de darte cuenta que había
algo mal, también serás capaz de encontrar la solución. Y una vez tengas
la solución, difúndela, propágala dentro de la empresa, haz participe a
todos los que te rodean, para que la solución se haga realidad.
La segunda mitad de la moraleja se centra en como los soldados engañan
a los aldeanos. El truco de las piedras hace que los aldeanos se centren
en lo que están haciendo los soldados, y no en lo que éstos quieres
conseguir.

◦ (6) Recuerda el todo (Remeber the big picture).

Si solo nos fijamos en lo que hacemos ahora, en nuestra pequeña parcela,
el todo, la aplicación entera, va a ir creciendo y deteriorándose poco a
poco, normalmente en los puntos de unión de nuestras parcelas con las de
nuestros vecinos más cercanos.
Mediante la historia del sapo hervido se transmite la idea de que cuando
los cambios llegan poco a poco, nadie se da cuenta, y al final, un gran cúmulo de
pequeños fallos hace un gran fallo irreversible. No seas sapo, y ten un
ojo siempre en lo que sucede a tu alrededor.

Software Suficientemente Bueno (Cuarto Apartado)

Comienza con la utopía de los chips. Ojala al desarrollar software

pudiésemos saber de antemano los errores que tiene una aplicación. Como
no somos capaces, lo único que podemos hacer es un software lo
suficientemente bueno, desde el punto de vista del cliente, algo que
resuelva los requisitos y que sea mantenible. Por esto, cuando se definen
los requisitos de un proyecto, además de los requisitos funcionales, se
debe definir la calidad y el alcance del proyecto.

◦ (7) Haz de la calidad un requisito (Make quality a requirements issue).

Y este no es un tip, pero qué gran frase: “Un buen software hoy es mejor que
un software perfecto mañana”.
La temprana retroalimentación del software mejora nuestra aplicación, y
por esto, es mejor que vayamos haciendo entregas desde el principio,
entregas evolutivas que van a implementar de forma creciente los
requisitos del proyecto, y permitirá pulir los requisitos ya implementados.
Continuando con lo de suficientemente bueno, no hay que quedarse corto,
ni pasarse de largo. Ni mucho ni poco. El software es suficientemente bueno
cuando no tenemos que hacer nada más y no nos falta nada por
hacer. Hay que saber cuando parar, porque la sobreingeniería cuesta,
recursos temporales y económicos
 Tu Portafolio de Conocimiento (Quinto Apartado).

La frase de Benjamin Franklin, que dice así: “Una inversión en

conocimiento siempre devenga los mejores intereses”. Aquello que nos
define como profesionales es nuestro conocimiento y nuestra
experiencia.
El problema con el conocimiento, aparte de lo que cuesta adquirirlo, es que
caduca. Las tecnologías avanzan a ritmos vertiginosos. No paran de
aparecer nuevos l enguajes, nuevas librerías, APIs, sistemas de
comunicación, etc… Tenemos que adquirir conocimiento y renovar el
que tenemos de una forma constante.

◦ (8) Invierte regularmente en tu portafolio de conocimiento (Invest regularly in your

knowledge portfolio).

Para invertir en nuestro portafolio (símil financiero) de conocimiento,

debemos invertir regularmente (coger un hábito de estudio, lectura), diversificar
(cuantas más cosas diferentes sepamos, más valiosos somos),
gestionar los riesgos (si solo centramos nuestro conocimiento en una
sola tecnología, si ésta se va a pique, nosotros seguiremos su
camino), comprar barato y vender caro (aprender tecnologías
emergentes puede darnos gran ventaja competitiva) y revisar y hacer balance
(mirar la vista atrás, revisar lo que sabemos , preguntarnos si
deberíamos reciclarnos, …).

Comprar barato y vender caro. ¿Qué crees que deberías aprender ahora
para poder ser más competitivo en el mercado, es decir, optar a un
puesto de trabajo bien remunerado? ¿JavaEE? ¿Algún lenguaje de
scripting (Ruby/Groovy) con su framework web (Rails/Grails)?
¿Quizás .Net?

Lo que está claro, es que no tenemos que parar de aprender, de

reciclarnos. Una vez nos veamos cómodos en un campo, saltar. Otra
tecnología, otro lenguaje, …
 Y que hay de las oportunidades de aprender. El libro comenta el reto que
supone cuando alguien recurre a ti, porque se supone que eres
experto (o tienes un nivel aceptable) sobre alguna tecnología, y te
hace una pregunta que nos sabes responder. Acaba de lanzarte
un reto que no debes rechazar. Busca la respuesta, apoyate en tu guru
personal (ese compañero de trabajo, algún ex-compañero de otra empresa,
amigo de estudios, etc..), busca en la biblioteca, Internet, haz lo que sea,
pero encuentra la respuesta. Así conseguimos que nuestro portafolio crezca.

◦ (9) Analiza críticamente lo que lees y escuchas (Critically analyze what you read
and hear).

Conforme uno adquiere más conocimiento, tenemos mayor capacidad de

análisis, y sabremos si lo que leemos y escuchamos es verdad o una
verdad a medias. Además, el hecho de dudar de lo que estamos
leyendo, buscarle las tres patas al gato, esa pregunta “puñetera” que
nadie se atreve a hacer pero a ti se te ocurre, … todo esto mejora la
calidad de nuestro conocimiento.

Comunícate (Sexto Apartado).

Se plantea la idea de que como todo el idea nos estamos comunicando, via
email, foros, documentos, código fuente, etc… hemos de hacerlo bien. Para ello
tenemos que saber que es lo que queremos decir (¿porque no hacerse un guion de lo
que vamos a decir?), conocer a nuestra audiencia (no seamos demasiado técnicos
cuando no debemos serlo, ni viceversa), elegir el momento (seguro que cuando erais
pequeño no le pediais dinero a vuestro padre cuando estaba cansado o con
hambre, ¿verdad?), elegir un estilo (a veces hay que enrollarse, otras veces,
cuando más escueto es uno, mejor), darle una buena apariencia (una buena comida
mal presentada no es una buena comida, y que hay de esas delicatessen tan bonitas
que luego no saben a nada, …. cuidado con la ortografia), involucra a la audiencia
(mediante borradores), escucha (escucha para ser escuchado, pide consejos,
pregunta por la opinión sobre lo que has comunicado), contesta (si no
contestamos a los que nos preguntan/piden, luego nosotros seremos los ignorados). Y
de cosecha propia, hay que predicar con el ejemplo, nada de “a Dios rogando, y con
el mazo dando”.

◦ (10) Es tan importante lo que dices como la manera en que lo dices (It’s both what
you say and the way you say it)
Cuanto mejor nos comuniquemos, más influyentes seremos.
Comunícate (Sexto Apartado).

Otros (… Apartados).

◦ (11) No te repitas.
 Cada pieza de conocimiento debe de tener una única e inequívoca representación dentro
de un sistema.

◦ (12) Hazlo fácil de reutilizar.

Si es fácil de reutilizar, la gente lo hará reutilizable. Crea un entorno que apoye la
reutilización.

◦ (13) Elimina los efectos entre cosas no relacionadas.

Los componentes de un diseño son autónomos, independientes y tienen un único
propósito bien definido.

◦ (14) No hay decisiones finales .

Las decisiones no se deben grabar en una piedra, sino en laarena de la playa. Cualquier
decisión debe ser susceptible a cambio.

◦ (15) Tracea para llegar a to objetivo

Haz distintas pruebas y tracea los resultados para ver cómo se van compenetrando para
llegar a nuestro objetivo.

◦ (16) Usa prototipos para aprender.

Crear prototipos es un experiencia para el aprendizaje. Su valor no reside en el código
generado, si no en las lecciones que aprendes al crearlo.

◦ (17) Programa cerca del dominio

Diseña y programa usando el mismo lenguaje usado por el usuario.

◦ (18) Haz estimaciones para evitar sorpresas

Haz una estimación antes de empezar. Podrás adelantarte a los posibles problemas
futuros.

◦ (19) Sincroniza tu agenda con el código

Usa la experiencia que vayas ganando para refinar las escalas temporales de entrega del
proyecto.

◦ (20) Guarda tu conocimiento en texto plano.

El texto plano nunca será obsoleto. Ayuda a aprovechar tu trabajo y simplifica la
depuración así como las pruebas.

◦ (21) Usa el poder de la línea (Shell) de comandos.

Usa la línea de comandos (Shell) para resultados seguros que no sean interferidos por las
interfaces gráficas.
◦ (22) Utiliza un único buen editor .
El editor debe de ser una extensión de tu mano. Asegúrate que es configurable,
ampliable (plugins) y programable.

◦ (24) Siempre (Versiona, commit pequeños) el código fuente .

El control del código fuente es una máquina del tiempo, siempre puedes volver atrás.

◦ (25) Arregla el problema, no la culpa.

No importa de quién o de qué es la culpa, sigue siendo un problema de todas formas y
todavía necesita ser reparado.

◦ (26) No te asustes de depurar (debugging) .

Respira profundamente y PIENSA en la causa delerror.

◦ (27) El error no es de la "x" .

Es raro encontrar un error en el Sistema Operativo o en el compilador, o incluso en
librerías de terceros. El error (bug) siempre es más probable que esté en la aplicación.

◦ (28) No asumes nada, pruébalo.

Prueba tu hipótesis en el entorno actual que tengas, con datos reales y condiciones
límites.

◦ (29) Aprende un lenguaje para manipular texto (Notepad++, Regular expresion,

Replace).
Gastas una gran parte del día peleando con texto. ¿Por qué no hacer que el ordenador
haga el trabajo por ti?

◦ (30) Escribe código que escriba código .

Los generadores de código aumentan la productividad y evitan la duplicación.

◦ (31) No se puede escribir el software perfecto.

El software no puede ser perfecto. Protege elcódigo ya los usuarios de errores
inevitables.

◦ (32) Diseña con contratos.

Recurre a los contratos para documentar y comprobar que el código hace realmente lo
que tiene que hacer. (Bertrand Meyer).

◦ (33) Error tempranero (Principio de falla rapida).

Un error cuanto antes sea detectado mejor, hará menos daño que aquel que se detecte
 tarde, hará que creemos que la aplicación funciona.

◦ (34) Usa afirmaciones para prevenir lo imposible (Guard Clauses)

Las afirmaciones validan tu hipótesis. Úsalas para proteger el código de un mundo
desconocido.

◦ (35) Usa excepciones para los problemas excepcionales.

El abuso del uso de excepciones pueden convertir tu aplicación en poco legible y
sotenible. Usa las excepciones para casos excepcionales.

◦ (36) Acaba lo que empiezas.

Siempre que sea posible, la rutina o el objeto asignado a un recurso debe de ser borrado
cuando ya no sea necesario.

◦ (37) Minimiza el acoplamiento entre módulos.

Evita el acoplamiento debido al código "tímido" y aplica la Ley de Demeter .

◦ (38) Configura, no integres

Implementa las opciones para una tecnología usando opciones de configuración, no a
través de integración ó ingeniería.

◦ (39) Coloca abstracciones en código, detalles en metadatos.

Programa para el caso general, y coloca las especificaciones fuera del código base
compilado.

◦ (40) Analiza el flujo de trabajo para mejorar la concurrencia .

Aprovecha la concurrencia en el flujo de trabajo del usuario.

◦ (41) Diseña servicios de uso.

Diseña en términos de servicios independientes, detrás de objetos concurrentes bien
definidos, interfaces consitentes.

◦ (42) Siempre diseña para la concurrencia.

Permite la concurrencia, y diseñarás interfaces más limpias.

◦ (43) Separa las vistas desde los modelos .

Gana flexibilidad a bajo coste diseñando tu aplicación en términos de modelos y vistas.

◦ (44) Usa pizarras para coordinar el flujo de trabajo.

 Usa las pizarras para coordinar agentes y hechos dispares, manteniendo la
independencia y el aislamiento entre los participantes.

◦ (45) No programes por coincidencia.

Confíe sólo en las cosas confiables. Ten cuidado con la complejidad accidental, y no
confundas una feliz coincidencia con un plan organizado.

◦ (46) Haz una estimación del orden de tus algoritmos.

Ten una idea de la longitud de las cosas antes de empezar a escribir código.

◦ (47) Prueba tus estimaciones.

El análisis matemático no te lo dice todo. Prueba el tiempo consumido por tu código en
su entorno final.

◦ (48) Refactoriza pronto, refactoriza a menudo.

Así como quitas las malas hierbas de un jardín y lo reorganizas, reescribe, haz de nuevo
y rediseña el código cuando sea necesario. Arreglala raíz del problema.

◦ (50) Diseño a prueba (TDD).

Empieza a pensar en las pruebas antes de escribir una línea de código.

◦ (51) Prueba tu software, o lo harán tus usuarios.

Prueba sin piedad. No hagas que los usuarios encuentren los errores por ti.

◦ (52) No uses asistentes de código que no comprendas.

Los asistentes pueden generar montones de código. Asegúrate de entender todo antes de
incorporarlo a tu proyecto.

◦ (53) No reúnas requisistos, búscalos.

Los requisitos rara vez están en la superficie. Están enterrados bajo capas de supuestos,
conceptos erróneos y política.

◦ (54) Trabaja como un usuario para pensar como un usuario.

Esta es la mejor forma deconocer cómo funciona el sistema que utilizarán realmente.

◦ (55) Las abstracciones viven más que los detalles.

Invertir en abstracción, no en la implementación. Las abstracciones pueden sobrevivir.

◦ (56) Usa un glosario del proyecto.

Crea y mantén una única fuente de todos los términos y vocabulario específico de un
 proyecto.

◦ (57) No pienses fuera de la caja, encuentra la caja.

Cuando nos enfrentamos a un problema imposible, identifica las limitaciones reales.
Tienes que preguntarte ¿Se tiene que hacer de esta manera? ¿Hay que hacerlo en todos?

◦ (58) Empieza cuando estés listo.

Has ido adquiriendo experiencia toda tu vida. No ignores las dudas que te puedan surgir.

◦ (59) Algunas cosas son mejores cuando las acabas que cuando se describen.
No caigas en la espiral de las especificaciones, en algún momento tenemos que empezar
a programar.

◦ (60) No seas un esclavo de los métodos formales.

No adoptes ciegamente cualquier técnica sin suponerla en el contexto de tus prácticas de
desarrollo y capacidades.

◦ (61) Las herramientas costosas no producen mejores diseños.

No adoptes ciegamente cualquier técnica sin suponerla en el contexto de tus prácticas de
desarrollo y capacidades.

◦ (62) Las herramientas costosas no producen mejores diseños.

Ten cuidado con las exageraciones de los proveedores, el dogma de la industria, y el
precio. Juzga las herramientas en función a sus méritos.

◦ (63) Organiza los equipos alrededor de la funcionalidad.

No separes diseñadores de programadores ni los probadores (testers) de los modeladores
de datos.
Construye equipos en función de tu manera de construir código.

◦ (64) No uses el procedimientos de manual.

Un Shell script o fichero por lotes se ejecutará las mismas instrucciones, en el mismo
orden, una y otra vez.

◦ (65) Prueba pronto, prueba a menudo, prueba de forma automática.

Las pruebas que se ejecutan cada vez que compilas son más efectivas que los planes de
pruebas teóricos.

◦ (66) La programación no está terminada hasta que todos los tests hayan pasado.
 Queda todo dicho.

◦ (67) Usa saboteadores para probar tu prueba.

Introducir "bugs" a propósito en una copia separada de la fuente para verificar que las
pruebas detectan dicho error.

◦ (68) Prueba la cobertura de un estado, no la cobertura del código.

Identifica y pon a pruebalos estados de los programas. Probar sólo líneas de código no
es suficiente.

◦ (69) Encuentra errores una sola vez

Una vez que los probadores (humanos) encuentran un error, esta debe de ser la última
vez que se encuentra. A partir de ahora tienen que ser las pruebas automáticas las que
comprueben los errores.

◦ (70) El inglés es un lenguaje de programación

Escribir documentos igual que escribes código:respeta el principio DRY(No Te Repitas,
Don't Repeat Yourself), usa metadatos, MVC, generación automática, así sucesivamente.

◦ (71) Crea la documentación con el código, no la metas con calzador

La documentación creada separadamente del código acaba siendo poco precisa y
actualizada.

◦ (72) De forma gradual, aumenta las expectativas de los usuarios

Cuando comprendas las expectativas de los usuarios, entonces es el momento de ofrecer
un poco más.

◦ (73) Firma tu trabajo

Los artesanos de la Edad Media se sentían orgullosos de firmar su trabajo. Tu también
deberías.