Diario de un Dotnetero

Continuando con el tema del post anterior...

Me puse a reflexionar un poco sobre algunas experiencias propias, y creo que no estuve consciente del aplanamiento del mundo porque desde el principio estuve inmerso en él:

• A los 15 años (circa 1993), siendo un lepe de preparatoria, llegué a tirarle rollo a una morrita que estaba en Francia por BitNET. Ese mismo año hice una presentación de la escuela sobre las expediciones del Viking a Marte usando imágenes bajadas por FTP de la NASA (esto fue en la era pre-Web, apunta de comandos de UNIX).
• En el primer proyecto de desarrollo que trabajé después de salir de la carrera al "mundo real", nuestro cliente estaba en Phoenix, Washington y Nueva York. Nosotros en Juárez. Los sysadmins en Colorado Springs. El DBA desde algún rancho de esa misma región en medio de la nada; durante una teleconferencia de pronto oimos un ruido extraño y él tuvo que disculparse diciendo "perdonen, mi caballo acaba de meter la cabeza por la ventana".
• Cuando ocurrió el ataque de las torres gemelas, me enteré porque una de las gerentes del lado del cliente con la que me llevaba bien me lo contó por AOL Instant Messenger. Los teléfonos estaban saturados.
• En la época en la que se me ocurrió andar de Project Manager, me encargué de administrar proyectos de infraestructura de redes en donde los ingenieros que hacían el diseño técnico estaban en Canadá, yo en Cd. Juárez, y los que hacían la instalación del equipo en Plano, TX o donde el cliente estuviera--Argentina, Brasil etc.
• Durante un proyecto bastante grande, que involucraba mover el call center de soporte técnico de Dell (el cliente) para Latinoamérica de algún otro país a la Cd. de México, yo estaba en la línea durante la llamada que se organizó para la implementación ya que mi parte era el proyecto del firewall. Acabé de traductor (y tutor casi) porque los ingenieros en la Cd. de México estaban teniendo mucha dificultad para entender las instrucciones del cliente para echar a jalar la aplicación Web que se necesitaba. Todo esto mientras Dell y otra tercer de EE.UU. que participó en el trato, estaban en la llamada monitoreando la situación.
• Cuando anduve probando suerte en Nueva York, conocí en Manhattan a un chavo que resultó ser el presidente de Adelantus, Inc. Ellos están basados allá, pero tienen un centro de desarrollo en la Cd. de México. Después de regresar, me aventé una que otra liebre para sus clientes pequeños de NY, estando yo acá en Juárez.
• Actualmente estoy en un equipo de desarrollo en donde algunos miembros del equipo están en Michigan, otros en Vancouver (Washington). Yo estoy en El Paso/Juárez. Mi Project Manager está en Austin (Texas) y mi lider técnico y cliente están en Salem (Oregon). Tres de ellos son hindúes y uno es chino, así que nuestras juntas telefónicas grupales siempre son entretenidas (a veces me pregunto ¿en realidad estamos hablando todos inglés?). Algunos de los apellidos de mis compañeros no puedo ni pronunciarlos.
• Mis planes actuales incluyen el mudarme de nuevo a Nueva York y trabajar desde mi casita. A final de cuentas, el cliente nunca me ve cara a cara, y no le importa en realidad de qué ciudad hago check-in de mi código. Mientras esté disponible y me pueda llamar por teléfono cuando se le ofrezca... ¿cuál es el problema?

¿Y tú? ¿Cuáles son tus experiencias en un mundo plano?

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:

private void SerMaster()

{

    while (true)

    {

        EscogeLoQueQuieresAprender();

        Practicalo();

        AprendeDeLoQueHiciste();

        DecideCualEsElSiguientePasoEnTuEvolucion();

    }

}

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

Sí, ya sé que este es mi tercer post del día de hoy que menciona los wikis, y no nomás es porque me gusta la palabra (wiki-wiki-wiki-wiki-wiki-wiki), pero es que mientras más masticaba la idea, más me fue cayendo el veinte de la importante diferencia de escribir, por ejemplo un blog o una página "normal" y escribir en un wiki.

Yo, como alguien que se dá dotes de escritor wannabe, no me gusta que editen lo que escribo. Mis escritos son míos. Me costaron imaginación, tiempo y esfuerzo, y en un wiki cualquiera puede venir y desmadr, ejem, mejorar lo que yo escribí, al menos en la teoría.

Es decir si yo hago una página con un artículo bien padriuris llamado "Cómo ligar teiboleras en 3 sencillos pasos", puede llegar otro wey X y arruinar mi artículo poniendo una foto suya--me pasó esta semana... no lo del artículo de teiboleras, sino que alguien se confundió y editó una página accidentalmente con algo nada que ver. O peor aún, tu hermoso artículo puede ser la víctima de wiki vandalismo, según el tema y los permisos que hayas especificado. Pasa hasta en Wikipedia.

En fin, esto es el precio de la escritura colaborativa. Es un cambio de mentalidad al que apenas me estoy acostumbrando, pero siento que tengo que hacerlo, porque prefiero que "mis" cosas lleguen a ser lo mejor posible, en vez de que sean a mi manera. Aunque esto implique tener que aplacar mi ego un poco.

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.