Dotnetero Reloaded

Hacer lo "duh"

Estaba leyendo este artículo hoy de Kathy Sierra y me llamó especialmente la atención uno de los últimos párrafos:

When people ask for the secret sauce guaranteed recipe for success, we say that it's quite simple: just do the "duh" thing. The Big Secret is not about knowing what magical thing to do--it's about taking the "duh" things seriously enough and actually doing them. If you could pick just one "duh" thing to work on, what would it be?

¿Qué demonios tiene que ver con el desarrollo de software?

Muchos de nosotros hemos oído de prácticas que son buenas para mejorar la calidad del software que producimos--metodologías de desarrollo ágil, técnicas para modelación y orientación a objetos, patrones de diseño o herramientas que nos pueden ayudar a automatizar y ser más pragmáticos. Para mi estos son "DUH!".

Pero ¿cuántos en realidad las ponemos en práctica? ¿Por qué no lo hacemos?

En el grupo de estudio me he estado topando con muchas personas que quieren aprender, o que quieren hacerse "expertos" en .NET y obtener su certificación. Pero pocos de ellos están dispuestos a invertir el tiempo necesario para practicar. Me parece increíble, pero es cierto. Muchos de ellos creen que el escuchar un mono hablarles de cierto tema o que con leer un libro , que ya con eso saben. Pero si los comienzas a poner a prueba, o si les haces preguntas recién que cerraron la portada del libro patinan de volada.

Creo que no que es suficiente con ser blog-junkie o podcast-junkie. No es suficiente que te chutes 1 o 2 libros al mes para aprender algo y llegar al siguiente nivel de expertise. Todo esto ciertamente ayuda--sobretodo a ampliar tu campo de visión y conocer cosas nuevas--pero al final del día, si quieres incrementar tu nivel en cierto lenguaje o tecnología pues no te queda más que sentarte un rato y tirar código o jugar con la tecnología que te interesa.

A menos que seas superdotado, no creo que puedas aprender a andar en bicicleta con leer un libro, no importa qué tan bueno sea.

Así que propongo el siguiente modelo que voy a tomar prestado de Mastery With Women de David DeAngelo, pero traducido para la raza que programa:


Bueno, al final de todo creo que a mi también me salió un artículo "duh".

Pensándolo bien...

OK, quizá escribir software no sea como escribir ficción. Quizá es más parecido a escribir un ensayo o un editorial, en donde quieres lograr algo específico y concreto, en lugar de postear sin sentido en tu blog como un lunático.

Pero los principios son los mismos:

1. Al inicio solo tienes una idea abstracta o peor aún, solo un feeling de lo que quieres decir y/o cómo lograrlo.
2. Hasta que no te sientas a escribirlo, no desarrollas en realidad la idea de lo que quieres decir.
3. Deberías emplear 2 modos mentales: el creativo y el censor. A veces se nos olvida el segundo y algunos programillas no son mas que “primeros borradores” de lo que pudieron ser.
4. Alguien siempre debería revisar las idioteces que se te ocurren antes de publicarlas. Luego escribes 2 páginas de cosas en tu blog cuando las pudiste decir en media. Lo mismo pasa con el código.
   

Siguiendo con la idea del desarrollador como artista, creo que la bronca es porque es demasiado común que caigamos en consultingware cuando quizá nos convendría más enfocarnos a desarrollar algo pre-empaquetado.

Imaginen que Miguel Ángel hubiera tenido al Papa ahí enseguida diciéndole cómo quería que se viera la Capilla Sixtina. Claro que para eso Miguel Ángel seguramente era una chucha cuerera que conocía perfectamente el negocio de su cliente, y por eso lo dejaron hacerlo a su antojo.

De cualquier forma, es un camino escabroso, porque, como dijo ayer Gabriel Bravo: “lo difícil es hacerle entender a tu cliente que estás ahí para satisfacer sus necesidades, no para satisfacer sus necedades”.

Recuerden: entre necesidad y necedad sólo hay un “si” de diferencia. Así que cuando les pidan sus clientes algo, tengan cuidado de decir “sí” a las cosas correctas.