Guía Pragmatic Programmer en castellano:

Cuida tu obra de arte. ¿Por qué desperdiciar tu vida desarrollando software sino te
preocupas en hacerlo bien?

¡Piensa!, sobre tu trabajo. Desconecta el piloto automático y toma el control. Critica y

evalúa constantemente tu trabajo.

Proporciona opciones, no excusas. En vez de excusas, propón opciones. No digas que no

se puede hacer algo, explica mejor lo que sí puedes hacer.

No vivas con ventanas rotas. Corrige malos diseños, decisiones equivocadas y el código
mal escrito cuando lo veas.

Sé un catalizador para cambios. No puedes forzar que la gente cambie. En vez de eso,
muestra cómo podría ser el futuro y ayúdalos a participar en tu creación.

Recuerda el “Gran Cuadro”. No te obsesiones con los detalles porque hacen olvidarte de
lo que ocurre alrededor.

Hacer de la calidad un requisito imprescindible. Involucra a los usuarios para determinar

las necesidades de calidad reales del proyecto.

Invertir regularmente en conocimiento. Haz de aprender un hábito

Analiza de forma crítica lo que lees y escuchas. No te dejes convencer por vendedores,
dogma o medios. Analiza la información en tus términos y en basada en tu proyecto.

Importa tanto lo que dices como la forma de decirlo. No tiene sentido tener buenas ideas
sino las transmitimos con eficacia.

No te repitas. Cada pieza de conocimiento debe de tener una única e inequívoca

representación dentro de un sistema.

Hazlo fácil de reutilizar. Si es fácil de reutilizar, la gente lo hará reutilizable. Crea un

entorno que apoye la reutilización.

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.

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

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.
Usa prototipos para aprender. Crear prototipos es un experiencia para el aprendizaje. Su
valor no reside en el código generado, sino en las lecciones que aprendes al crearlo.

Programa cerca del dominio.. Diseña y programa usando el mismo lenguaje usado por el
usuario.

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

Sincroniza tu agenda con el código. Usa la experiencia que vayas ganando para refinar las
escalas temporales de entrega del proyecto.

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.

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.

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.

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

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.

No te asustes de depurar (debugging). Respira profundamente y PIENSA en la causa del

error.

El error no es de la “select”. 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.

No asumes nada, pruébalo. Prueba tu hipótesis en el entorno actual que tengas, con datos
reales y condiciones límites.

Aprende un lenguaje para manipular texto. Gastas una gran parte del día peleando con
texto. ¿Por qué no hacer que el ordenador haga el trabajo por ti?

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

No se puede escribir el software perfecto. El software no puede ser perfecto. Protege el

código y a los usuarios de errores inevitables.
Diseña con contratos. Recurre a los contratos para documentar y comprobar que el código
hace realmente lo que tiene que hacer.

Error tempranero. 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.

Usa afirmaciones para prevenir lo imposible. Las afirmaciones validan tu hipótesis.

Úsalas para proteger el código de un mundo desconocido.

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.

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.

Minimiza el acoplamiento entre módulos. Evita el acoplamiento debido al código

“tímido” y aplica la Ley de Demeter.

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

Coloca abstracciones en código, detalles en metadatos. Programa para el caso general, y

coloca las especificaciones fuera del código base compilado.

Analiza el flujo de trabajo para mejorar la concurrencia. Aprovecha la concurrencia en

el flujo de trabajo del usuario.

Diseña servicios de uso. Diseña en términos de servicios independientes, detrás de objetos

concurrentes bien definidos, interfaces consitentes.

Siempre diseña para la concurrencia. Permite la concurrencia, y diseñarás interfaces más

limpias.

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

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.

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.

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

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. Arregla
la raíz del problema.

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

Prueba tu software, o lo harán tus usuarios. Prueba sin piedad. No hagas que los
usuarios encuentren los errores por ti.

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.

No reunas 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.

Trabaja como un usuario para pensar como un usuario. Esta es la mejor forma de
conocer cómo funciona el sistema que utilizarán realmente.

Las abstracciones viven más que los detalles. Invertir en abstracción, no en la

implementación. Las abstracciones pueden sobrevivir.

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

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?

Empieza cuando estés listo. Has ido adquiriendo experiencia toda tu vida. No ignores las
dudas que te puedan surgir.

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.

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.

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

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.

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.

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

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.

Prueba la cobertura de un estado, no la cobertura del código. Identifica y pon a prueba

los estados de los programas. Probar sólo líneas de código no es suficiente.

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.

El inglés es un lenguaje de programación. escribir documentos igual que escribes código:

respeta el principio DRY (No Te Repitas, Dont Repeat Yourself), usa metadatos, MVC,
generación automática, así sucesivamente.

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.

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.

Firma tu trabajo. Los artesanos de la Edad Media se sentían orgullosos de firmar su

trabajo. Tu también deberías.
Five books every Java developer must own

Update: Welcome, Javalobby readers! You might be interested in the followup to this post.
Thanks for the great feedback and suggestions.

 Pragmatic Programmer by Andrew Hunt and David Thomas

This is absolutely required reading for any software developer, regardless of language. If
you are lost when people are talking about "keeping it DRY" or the danger of broken
windows, you need this book.
 Effective Java by Joshua Bloch Effective Java is absolutely crucial if you create any APIs,
and if you ever see public class... you are writing APIs, whether its for a team of one

or one thousand. Bloch covers issues like immutability, properly

implementing equals and hashCode, the benefits of composition over inheritance, and the
value of static factory methods. He talks about all sort of common beginner mistakes such
as using interfaces for constants, using float or double when you need absolute precision,
overuse of Strings, and crappy singleton implementations. After you've read this, listen to
the JavaPosse interview with Bloch to hear how about a possible second edition and take a
look at Java Puzzlers for fun gotchas found in Java.

 Design Patterns by the GoF Design Patterns is by the Gang of Four

(GOF) is often lauded as a classic read for anyone doing OO development, whether the
language be Smalltalk, C++, or Java. If you aren't familiar with Design Patterns but have
been doing OO for awhile, you have already been using some of the patterns without
knowing it. Having a common vocabularily to share with others is very powerful, so know
the 26 classic patterns is important for any Java developer today.
  Extreme Programming Explained: Embrace Change

by Kent Beck and Cynthia Andres When I first read XP: Explained, so many of the concepts
made me nod my head in agreement and wonder how typical software development goes
against so many of its principles. XP and agile isn't rocket science or a silver bullet, its just
good common sense. "Take small steps, one at a time. Communication is vital. Feedback is
important. Change is constant, so work with it instead of fighting it." It sounds like advice
your mom or grandpa gave you when you were eight years old, so why does it take a
"revolution" or a "movement" to put these things into practice for software development?
That might be a topic for another essay, so for now just get this book. Its essential for
understanding the ideas behind XP and agility. Note that the second edition is quite
different from the first - it has a broader, less technical apporach. They are both worth
reading, the first moreso for programmers and the second for customers and managers.

 Programming Ruby by Dave Thomas et al, or Practical Common Lisp, or

Learning Python or... The fifth book in this list really isn't a specific book at all, but a more
general recommendation to get a book about a language very different from the Java/C#
family. Learn one of the hot dynamically typed languages all the kdis love these days, like
Ruby or Python. If those are old hat, pick up the The Haskell School of Expression if the
online tutorial seems interesting. Or maybe Graham's On Lisp, which recently put online
for free. Just learn a language that forces you think in a different way from Java. Even if
your day job continues to be Java, knowing how you would solve a problem in Ruby or Lisp
will only make you a better programmer.

Note what isn't on the list: any of the Java 5 reference books or any of the tens (hundreds?)
of J2EE books. Its important to keep up with the language and the platform, but I think
thats better done through programming with the JDK and examples as reference. The
reference books can be helpful for getting up to speed for day to day work, but I don't think
they are essential for furthering your knowledge or your craft. Long after your J2EE
1.4.x.niner book is collecting dust on the shelf, Effective Java will still be a reference you
consult regularly.