Barrapunto

The Pragmatic Programmer: From Journeyman to Master [pragprog.com]

Hubo un tiempo en que leí varios de ese estilo como por ejemplo Code Complete. Muy útil, pero terriblemente extenso para lo que sacas. Pragmatic Programmer lo empecé y terminé por leer sólo la conclusión del capítulo.

La decepción del título viene de que todo lo que ha venido después "no necesariamente de una tecnología concreta" ha sido decepcionante, por no decir directamente dañino.

Por un lado está la gente que tiene algo útil que decir, que viene de una larga experiencia y haber experimentado distintas formas de atacar un problema y que lo puede articular en un libro.

Cada vez menos y a menudo cada vez más específico. O sea "necesariamente de una tecnología concreta".

Por otro lado tenemos a la gente que piensa que debería escribir un libro, que tiene experiencia la justita y que considera que su forma de hacer las cosas es la mejor y la única.

Cada vez más.

Hace años lei un articulo que venia a decir algo asi como:

"Si lees esto, estas entre el 10% de los mejores programadores"

No recuerdo donde lo lei o de que trataba aparte de eso, la idea que se me quedo es la que explicaba esa frase.

Segun el autor, el 90% de programadores no sienten ningun interes por aprender y reciclarse mas alla de lo que les toque hacer el curro y que es precisamente la gente que lee publicaciones, blogs y libros tecnicos los que suelen estar en el top de programadores simplemente por ese deseo de saber mas y aprender.

En aquel momento me parecio impensable, en mi circulo de amigos, los que nos dedicamos a esto siempre estamos hablando de tal o cual articulo, libro o tecnologia. Hoy en dia, despues de haberme movido mas (y por varios paises), aun tengo dudas en ese 10% (yo creo que es mas), pero si que es cierto que un gran porcentaje de gente que se dedica a esto se niega a aprender nada por su cuenta y menos aun si no es un curso pagado por el trabajo (y en aun en ese caso, a regañadientes).

En mi caso y asi en frio, se me ocurre que los que mas han influido en mi han sido (aparte de "pragmatic programmer", ya mencionado):

- "The mythical man-month" [wikipedia.org] (y los otros escritos)
- "The art of computer programming" [wikipedia.org]
- "Refactoring" [martinfowler.com]
- "J2EE Development without EJB" [wiley.com] (este es menos importante/interesante hoy en dia, pero se publico antes de Spring, cuando hacer aplicaciones empresariales en java con EJBs era, no solo la norma, sino un infierno... Es la primera vez que vi la inyeccion de dependencias, inversion de control y demas patrones)
- "Structure and interpretation of computer programs" [mit.edu]
- "The Career Programmer: Guerilla Tactics for an Imperfect World" [amazon.com]
- "Java Power Tools" [oreilly.com]

Este ultimo es sobre todo orientado a Java, pero introduce un monton de herramientas de analisis estatico de codigo, integracion continua, documentacion y demas que ayudan mucho en la gestion de un proyecto.

Algorithms, de Cormen y otros. Creo que conviene ir a las bases, para luego pasar a las esecificidades.

Pues vaya SPAM mas sutil y mas bonito...

Me he tomado la molestia de bajarme y leerme en diagonal el primer capítulo y en fin... que decir. Hay veinte o treinta reglas de lo que es publicar un primer capítulo que enganche que están incumplidas.

No hay nada en este primer capítulo que me haga querer leer mas, no hay "chicha" por ninguna parte.

Y un consejo: Una introducción de un libro no es un artículo de revista. Si lo comienzas por "Estamos viviendo interesantes momentos..." (o similar) lo que estás haciendo es abrir una puerta a la obsolescencia más absoluta...
¿Estamos viviendo cuándo?... ¿Quién?...¿DÓNDE?
Ya en la propia introducción se ve mucho pastiche... ¿Redes desplegadas inimaginables?, ¿managers incompetentes?, ¿querer mejorar el currículum del autor?, ¿disciplina de trabajo y desacoplamiento de módulos?...
¿De cuántas de estas cosas vas a hablar y a qué nivel vas a profundizar?... ¿SOA, Big Data, extreme, hotfixes, community manager en una misma página?...
¿Es un libro de metodología, de nueva economía, de buenas prácticas de codificación o de qué exactamente?.
No se... Yo le daría una vuelta.

En todos Los proyectos que he trabajado, siempre he tenido que entrar cuando el proyecto ya estaba casi terminado. Yo hacia mantenimiento y arreglar bugs. ?Algun libro Para esto?

En las montañas de la locura, de H.P. Lovecraft: es el libro que más me ha ayudado en mi trabajo como desarrollador. No se centra en una tecnología concreta, sino que habla de horrores abstractos y antiguos que pueden yacer en cualquier parte.

Cuando he estado mas estresado de lo normal que no me viene "la creatividad angelical o la productividad zombie", necesito una pausa....y relajarme

En mis tiempos mozos, con el Spectrum y el basic...pues me apañaba con productos ibéricos y casposos como la Interviu.

Pero según fueron mis manos alcanzando metas mayores y lenguajes mas complejos tuve que recurrir a bibliografía de mas calidad, Playboy, Kiss Comics...

Ahora con el mundo en la nube....pues Tumblr...

Para mí, sin duda los mejores, aunque quizás no sean los más accesibles (salvo el primero)

• Bruce Eckel - "Thinking in Java"
• Joshua Bloch - "Effective Java - 2nd Edition"
• Martin Fowler - "Refactoring: Improving the Design of Existing Code"
• Martin Fowler - "Patterns of Enterprise Application Architecture"
• Eric Evans - "Domain-driven Design: Tackling Complexity in the Heart of Software"

Al ver toda la rabia contenida en tu comentario, da la sensación, de que el que hace LA TIRA que no folla eres tu. Por otro lado, no todo el mundo nace sabiendo. Saludos