Gua PragmaticProgrammer 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 automtico y toma el control. Critica y evala constantemente tu trabajo. Proporciona opciones, no excusas. En vez de excusas, propn opciones. No digas que no se puede hacer algo, explica mejor lo que s puedes hacer. No vivas con ventanas rotas. Corrige malos diseos, decisiones equivocadas y el cdigo mal escrito cuando lo veas. S un catalizador para cambios. No puedes forzar que la gente cambie. En vez de eso, muestra cmo podra ser el futuro y aydalos a participar en tu creacin. 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 hbito Analiza de forma crtica lo que lees y escuchas. No te dejes convencer por vendedores, dogma o medios. Analiza la informacin en tus trminos 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 inequvoca representacin dentro de un sistema. Hazlo fcil de reutilizar. Si es fcil de reutilizar, la gente lo har reutilizable. Crea un entorno que apoye la reutilizacin. Elimina los efectos entre cosas no relacionadas. Los componentes de un diseo son autnomos, independientes y tienen un nico propsito bien definido. No hay decisiones finales. Las decisiones no se deben grabar en una piedra, sino en la arena de la playa. Cualquier decisin debe ser susceptible a cambio. Tracea para llegar a to objetivo. Haz distintas pruebas y tracea los resultados para ver cmo 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 cdigo generado, sino en las lecciones que aprendes al crearlo. Programa cerca del dominio..Disea y programa usando el mismo lenguaje usado por el usuario. Haz estimaciones para evitar sorpresas. Haz una estimacin antes de empezar. Podrs adelantarte a los posibles problemas futuros. Sincroniza tu agenda con el cdigo. 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 depuracin as como las pruebas. Usa el poder de la lnea (Shell) de comandos. Usa la lnea de comandos (Shell) para resultados seguros que no sean interferidos por las interfaces grficas. Utiliza un nico buen editor. El editor debe de ser una extensin de tu mano. Asegrate que es configurable, ampliable (plugins) y programable. Siempre controla el cdigo fuente. El control del cdigo fuente es una mquina del tiempo, siempre puedes volver atrs. Arregla el problema, no la culpa. No importa de quin o de qu es la culpa, sigue siendo un problema de todas formas y todava 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 libreras de terceros. El error (bug) siempre es ms probable que est en la aplicacin. No asumes nada, prubalo. Prueba tu hiptesis en el entorno actual que tengas, con datos reales y condiciones lmites. Aprende un lenguaje para manipular texto. Gastas una gran parte del da peleando con texto. Por qu no hacer que el ordenador haga el trabajo por ti? Escribe cdigo que escriba cdigo. Los generadores de cdigo aumentan la productividad y evitan la duplicacin. No se puede escribir el software perfecto. El software no puede ser perfecto. Protege el cdigo y a los usuarios de errores inevitables.

Disea con contratos. Recurre a los contratos para documentar y comprobar que el cdigo hace realmente lo que tiene que hacer. Error tempranero. Un error cuanto antes sea detectado mejor, har menos dao que aquel que se detecte tarde, har que creemos que la aplicacin funciona. Usa afirmaciones para prevenir lo imposible. Las afirmaciones validan tu hiptesis. salas para proteger el cdigo de un mundo desconocido. Usa excepciones para los problemas excepcionales. El abuso del uso de excepciones pueden convertir tu aplicacin 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 mdulos. Evita el acoplamiento debido al cdigo tmido y aplica la Ley de Demeter. Configura, no integres. Implementa las opciones para una tecnologa usando opciones de configuracin, no a travs de integracin ingeniera. Coloca abstracciones en cdigo, detalles en metadatos. Programa para el caso general, y coloca las especificaciones fuera del cdigo base compilado. Analiza el flujo de trabajo para mejorar la concurrencia. Aprovecha la concurrencia en el flujo de trabajo del usuario. Disea servicios de uso. Disea en trminos de servicios independientes, detrs de objetos concurrentes bien definidos, interfaces consitentes. Siempre disea para la concurrencia. Permite la concurrencia, y disears interfaces ms limpias. Separa las vistas desde los modelos. Gana flexibilidad a bajo coste diseando tu aplicacin en trminos 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. Confe slo en las cosas confiables. Ten cuidado con la complejidad accidental, y no confundas una feliz coincidencia con un plan organizado. Haz una estimacin del orden de tus algoritmos. Ten una idea de la longitud de las cosas antes de empezar a escribir cdigo.

Prueba tus estimaciones. El anlisis matemtico no te lo dice todo. Prueba el tiempo consumido por tu cdigo en su entorno final. Refactoriza pronto, refactoriza a menudo. As como quitas las malas hierbas de un jardn y lo reorganizas, reescribe, haz de nuevo y redisea el cdigo cuando sea necesario. Arregla la raz del problema. Diseo a prueba. Empieza a pensar en las pruebas antes de escribir una lnea de cdigo. Prueba tu software, o lo harn tus usuarios. Prueba sin piedad. No hagas que los usuarios encuentren los errores por ti. No uses asistentes de cdigo que no comprendas. Los asistentes pueden generar montones de cdigo. Asegrate de entender todo antes de incorporarlo a tu proyecto. No reunasrequisistos, bscalos. Los requisitos rara vez estn en la superficie. Estn enterrados bajo capas de supuestos, conceptos errneos y poltica. Trabaja como un usuario para pensar como un usuario. Esta es la mejor forma de conocer cmo funciona el sistema que utilizarn realmente. Las abstracciones viven ms que los detalles. Invertir en abstraccin, no en la implementacin. Las abstracciones pueden sobrevivir. Usa un glosario del proyecto. Crea y mantn una nica fuente de todos los trminos y vocabulario especfico 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 ests 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 algn momento tenemos que empezar a programar. No seas un esclavo de los mtodos formales. No adoptes ciegamente cualquier tcnica sin suponerla en el contexto de tus prcticas de desarrollo y capacidades. Las herramientas costosas no producen mejores diseos. Ten cuidado con las exageraciones de los proveedores, el dogma de la industria, y el precio. Juzga las herramientas en funcin a sus mritos.

Organiza los equipos alrededor de la funcionalidad. No separes diseadores de programadores ni los probadores (testers) de los modeladores de datos. Construye equipos en funcin de tu manera de construir cdigo. 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 automtica. Las pruebas que se ejecutan cada vez que compilas son ms efectivas que los planes de pruebas tericos. La programacin no est terminada hasta que todos los tests hayan pasado. Queda todo dicho. Usa saboteadores para probar tu prueba. Introducir bugs a propsito 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 cdigo. Identifica y pon a prueba los estados de los programas. Probar slo lneas de cdigo 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 automticas las que comprueben los errores. El ingls es un lenguaje de programacin. escribir documentos igual que escribes cdigo: respeta el principio DRY (No Te Repitas, DontRepeatYourself), usa metadatos, MVC, generacin automtica, as sucesivamente. Crea la documentacin con el cdigo. No la metas con calzador. La documentacin creada separadamente del cdigo 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 ms. Firma tu trabajo. Los artesanos de la Edad Media se sentan orgullosos de firmar su trabajo. Tu tambin deberas.

Five books every Java developer must own

Update: Welcome, Javalobby readers! You might be interested in the followup to this post. Thanksforthegreatfeedback and suggestions.
y

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