Tip 12: Make It Easy to Reuse - Hazlo fácil de reutilizar.

Para evitar la duplicación hay que facilitar la búsqueda y uso de la información. Si es fácil de encontrar y usar, se usará y no se duplicará.

Tip 11: DRY—Don't Repeat Yourself - No te repitas

Un programador reune, organiza, mantiene y utiliza conocimientos. Se documentan en las especificaciones, cobran vida al ejecutar el código y se usan durante los test al comprobar los resultados.
Estos conocimientos no son estables y cambian durante el desarrollo de la aplicación.

Una buena costumbre es no duplicar el conocimiento. Debe ser expresado en un sólo lugar, así, si este conocimiento cambia, sólo habrá que modificarlo en dicho lugar.

La mayoría de las duplicaciones se pueden encontrar dentro de las siguientes categorías:

• Duplicación impuesta. Parece que no hay elección, el sistema parece que requiere de duplicación. Con un poco ingenio puede que se evite la duplicación. Al documentar el código se está duplicando información, para evitarla, el propio código debe ser la documentación de bajo nivel, mientras que los comentarios sería la explicación de de alto nivel.
  
• Duplicación inadvertida. A veces se está duplicando la información por errores en el diseño. Por ejemplo, una linea esta compuesta por 2 puntos o por un punto y un ángulo y una distancia. Una clase que define la linea tiene información duplicada si tiene 2 puntos y una longitud.
  
• Duplicación impaciente. Se duplica porque parece más fácil copiar y pegar y modificar un poco. En ese momento puede resultar beneficioso, pero a la larga requerirá más tiempo.
  
• Duplicación multiprogramador.Varios programadores duplican información. Para evitarlo lo mejor es una buena comunicación entre programadores.
  

Tip 10: It's Both What You Say and the Way You Say It - Es tanto lo que se dice como la manera en que se dice.

Un programador se comunica de muchas formas diferentes, en el grupo de trabajo, con el usuario final, con el ordenador,... por lo tanto debe hacerlo bien. Algunas ideas para llevarlo a cabo son:

Saber lo que se quiere comunicar. Hay que planear lo que se quiere comunicar y refinarlo para comunicar lo que realmente queremos.

Conocer a la audiencia. Para eso algunas preguntas que podemos hacernos son:
¿Qué quieres que aprendan?
¿Qué interés tienen en lo que pretendes comunicar?
¿Cuantos detalles quieren?
¿Cómo pueden motivarse para que escuchen?

Elegir el momento. La última hora de un viernes generalmente es un mal momento para realizar cualquier comunicación. También se pueden presentar ocaciones en las que una propuesta sea aceptada por algún acontecimiento que haya sucedido.

Elegir el estilo. En algunos casos puede valer con unas lineas, un correo. En otros se puede necesitar un documento detallado. Si hay dudas, lo mejor es preguntar.

Hay que hacerlo bonito. No sólo el contenido es importante, el formato, el tipo de letra, las faltas de ortografía,...

Implicar a los destinatarios para que nos comenten que les parece el documento.

Escuchar. Si escuchamos seremos escuchados. Hay que animar a hacer preguntas para hacer de la presentación un dialogo.

Siempre responder en el momento, aunque la respuesta sea que lo vas a mirar. Hay que mantener a las personas informadas para que no sientan que nos hemos olvidado del asunto.

Tip 9: Critically Analyze What You Read and Hear - Analiza criticamente lo que leas y oigas

No hay que creer todo lo que se lee, hay que analizarlo.
No sabemos los intereses que puede haber detrás de ese artículo que estamos leyendo.

Tip 8: Invest Regularly in Your Knowledge Portfolio - Ampliar conocimientos regularmente.

El Knownledge Porfolio de un programador es como una cartera de inversiones y por lo tanto hay que:

- Invertir regularmente: Aunque sea una pequeña cantidad, la suma es lo importante.
- Diversificar: Cuantos más conocimientos diferentes se tengan mas valor tiene el programador.
- Administrar el riesgo: No hay que especializarse demasiado en una tecnología.
- Compra barato, vende caro: Aprender alguna tecnología que está empezando puede ser duro, pero la ventaja de ser de los primeros en usarla puede tener grandes recompensas.
- Revisa y reequilibra: Esta es una industria muy dinámica, lo que hoy es última tecnología mañana puede estar anticuada.

Los consejos que nos dan para conseguirlo son:

- Aprender al menos un lenguaje cada año.
- Leer un libro técnico cada trimestre.
- Leer libros no técnicos también, porque no hay que olvidar que los ordenadores los usan personas.
- Asistir a clases.
- Participar en grupos locales.
- Experimentar con distintos entornos, si en el trabajo usas Windows en casa usa Linux por ejemplo.
- Estar actualizado, subscribiendose a listas de noticias sobre tecnología,...
- Conéctate, navega por Internet para encontrar información que te puede ser útil.

Todo esto necesita tiempo, y no se dispone de mucho, por lo que hay que tener preparado algo para leer en los tiempos muertos.

Tip 7: Make Quality a Requirements Issue - Haz la calidad un requerimiento.

El alcance y la calidad de un sistema debería estar especificado en la tabla de requisitos.

Los usuarios finales deberían probar el software e indicar si es lo suficientemente bueno para sus necesidades. Luego se podrá añadir más funcionalidad o no. Un software bueno hoy es preferible a un software perfecto mañana.

Hay que saber cuando parar, se puede echar a perder el código si se intenta refinar en exceso. Puede no ser perfecto, pero no hay que preocuparse, podría no ser perfecto nunca. Hay que dejar un tiempo que haga su trabajo.

Tip 6: Remember the Big Picture

Se debe revisar continuamente lo que pasa alrededor, no sólo lo que estás haciendo tu.

Puede ser que se estén haciendo cambios pequeños que pasan desapercibidos, pero muchos cambios pequeños al final es un cambio muy grande.

Tip 5: Be a Catalyst for Change - Se un catalizador para el cambio.

Hay ocasiones en las que un programador sabe lo que quiere hacer, pero no encuentra apoyo (ya sea de sus superiores o de compañeros) para llevarlo acabo.

En estos casos lo que hay que hacer es trabajar en ello, hacerlo bien y cuando se tengan algunos resultados enseñarlos. Si es interesante te propondrán mejoras, e incluso se unirán al proyecto.

Es más sencillo unirse a algo que ya está en marcha que empezar desde cero.

Tip 4: Don't Live with Broken Windows - No vivas con ventanas rotas.

Las ventanas rotas son en éste caso: un mal diseño, decisiones o código erróneo,... Hay que arreglarlo tan pronto como se descubra. Si no hay tiempo se puede comentar el código, mostrar un mensaje,... lo que sea para evitar un posible problema e indicar que la situación está bajo control.

En general las leyes físicas no afectan al desarrollo de software, aunque la entropía ataca duro. La entropía es un termino de la física que hace referencia a la cantidad de desorden de un sistema. Desafortunadamente las leyes de la termodinámica nos dicen que la entropía en el universo tiende a incrementar.

Un coche abandonado puede pasar meses en perfecto estado, pero como se rompa una sola ventana, en horas estará desguazado.

Si te encuentras trabajado en un proyecto con algunas "ventanas rotas" es muy fácil pensar que todo el proyecto está en el mismo estado y no te molestarás en hacer buenos aportes al proyecto. Por la misma regla, si te encuentras en un proyecto donde el código está bien comentado, ordenado, limpio, elegante,... tendrás mucho cuidado para no desordenarlo.

Tip 3: Provide Options, Don't Make Lame Excuses - Proporciona opciones, No pongas malas excusas.

Un programador no tiene que tener miedo de admitir su ignorancia o un error cometido. Los errores los comete cualquiera, pero hay que tratarlos de manera profesional. Esto significa ser honesto y directo.

Cuando se comete un error hay que admitirlo honestamente y buscar soluciones. No hay que culpar a alguien o algo o poner excusas. En vez de buscar excusas hay que buscar soluciones.

Tip 2: Think! About Your Work - Piensa en tu trabajo.

Un programador debe pensar en lo que está haciendo mientras lo está haciendo. Tiene que hacer una evaluación de cada decisión que tome. Pensar constantemente en su trabajo y criticarlo en tiempo real.

Esto quitará algo de tiempo, pero la recompensa es una implicación activa en el trabajo que le gusta, el sentimiento de dominio sobre un creciente número de materias y el placer de sentir un continuo perfeccionamiento.

A la larga, el tiempo invertido se recompensará convirtiéndolo en un eficiente programador, escribiendo código más sencillo de mantener y pasando menos tiempo en reuniones.

Tip 1: Care About Your Craft - Preocupate de tu oficio

Cada programador es único, con sus puntos fuertes y sus puntos débiles, pero los programadores pragmáticos comparten las siguientes características:

Se adapta rápidamente a nuevas técnicas y tecnologías. Le gusta intentar cosas nuevas.

Es curioso. Se pregunta qué son y como estarán hechas las cosas.

Es un pensador critico, no toma las cosas sin antes cuestionarlas.

Es realista, intenta comprender el fondo de cada problema para así conocer su dificultad.

Es un manitas, intenta familiarizarse y mantenerse al día con un amplio rango de entornos y tecnologías aunque en su trabajo sea un especialista en alguna materia.

Pragmatic Programmer, The: From Journeyman to Master

Este es el título de un libro que dice que me ayudará a ser un mejor programador, a hacer mejor mi trabajo. A ver si ses verdad.

Se basa en la experiencia de 2 programadores, Dave and Andy, que a lo largo de su carrera han recopilado información de como hacer las cosas para hacer mejor su trabajo, la han usado para superarse ellos mismos y han desechado lo que no funcionaba.
No es una teoría del desarrollo del software. Nos cuentan como programan ellos.
Programar es un trabajo lleno de detalles, no es sólo teclear comandos en un lenguaje de programación, es un arte.

A lo largo del libro va dando una serie de consejos para convertirse en un buen programador. Cada consejo está basado en su experiencia.

Aquí intentaré ir haciendo un resumen de cada uno de ellos.