sábado
mar312007
Como ser un Gurú Java sin conocer Java (Al menos e
sábado, marzo 31, 2007 at 1:13AM
Hola a todos, encontré en un blog que acostumbro leer un post muy cómico, me tomé la molestia de traducirlo para publicarlo aquí, cualquier parecido con la realidad es pura casualidad.
Disfrútenlo.
Como ser un Gurú Java sin conocer Java (Al menos en reuniones):
Escribí algunas estrategias para "expertos" y las llamé VooDoo Consulting Style. Las estrategias fueron consejos comunes e independientes del lenguaje para consultores "high end".
En el espacio java, es aún mas fácil ser un gurú reconocido - casi sin esfuerzo adicional.
Escribiendo código, o siendo productivo es peligroso (algo puede salir mal). A veces es más fácil ser un
gurú sin codificar:
1. Antes del proyecto inicial pasa por jcp.org. Revisa todas las JSR's, aprende algunos números y títulos (5 bastan en general). Si tienes que reunirte con desarrolladores más avanzados - además lee el resumen. Menciona los JSRs durante la reunión y disfruta del impacto.
2. Si el proyecto va a ser realizado con Java EE: Enfatiza la amplitud de Java. Apunta a lenguajes elegantes como Python o Ruby.
No es necesario conocer estos lenguajes. Es poco probable que éstos sean usados en un ambiente Java EE. Si éstos lenguajes van a ser elegidos ir al punto 6.
3. Mencionar JDK 1.7 (esta estrategia es muy útil -> La mayorïa de las compañías están pensando ahora actualizar a Java5) y closures.
En general es suficiente con sólo mencionar el término "closure" en el contexto de Java.
4. Espera una cantidad aleatoria de tiempo. Elige algún tema y trata de iniciar una discusión; SOA vs. ROA, (Ruby on Rails vs. Java EE), Thin vs. Rich, Ajax vs. Rich, (Swing vs. SWT), Netbeans vs. Eclipse, Java EE vs .NET, (SOAP vs. REST) y OSGI y JSR-277. Los que
están entre () son mas graciosos y alargan la conversación.
5. Utiliza todos los términos relacionados con Web 2.0, SOA, etc. No te preocupes del significado: nadie es capaz de definirlos.
6. Sugiere lenguajes más esotéricos como Haskell, Scala o Fortress pero no Malbolge para la realización del proyecto. En general no hay razón para hacer eso (Java funciona bien), pero por qué no?
7. No olvides la generación de código. A veces es suficiente con iniciar una discusión acerca de MDA vs. MDSD. Si nada ocurre pregunta a los desarrolladores acerca de PIM, PSM y transformación de código
etc.
8. Muy importante: menciona cosas como velocidad de equipo, programación de pares, pregunta acerca de Xtreme-programming, Agile, Scrum, Crystal, Test First, Mocking (cuanto más mejor).
Contrariamente al estilo de consultoría Voodoo, estas estrategias (o tópicos) cambian con el tiempo.
De modo que tu tienes que actualizar la lista de tanto en tanto.
A pesar de que tales "gurus" sobreviven varios proyectos, es relativamente fácil encontrarlos.
Sólo pregunta acerca de las razones de la decisión.
Disfrútenlo.
Como ser un Gurú Java sin conocer Java (Al menos en reuniones):
Escribí algunas estrategias para "expertos" y las llamé VooDoo Consulting Style. Las estrategias fueron consejos comunes e independientes del lenguaje para consultores "high end".
En el espacio java, es aún mas fácil ser un gurú reconocido - casi sin esfuerzo adicional.
Escribiendo código, o siendo productivo es peligroso (algo puede salir mal). A veces es más fácil ser un
gurú sin codificar:
1. Antes del proyecto inicial pasa por jcp.org. Revisa todas las JSR's, aprende algunos números y títulos (5 bastan en general). Si tienes que reunirte con desarrolladores más avanzados - además lee el resumen. Menciona los JSRs durante la reunión y disfruta del impacto.
2. Si el proyecto va a ser realizado con Java EE: Enfatiza la amplitud de Java. Apunta a lenguajes elegantes como Python o Ruby.
No es necesario conocer estos lenguajes. Es poco probable que éstos sean usados en un ambiente Java EE. Si éstos lenguajes van a ser elegidos ir al punto 6.
3. Mencionar JDK 1.7 (esta estrategia es muy útil -> La mayorïa de las compañías están pensando ahora actualizar a Java5) y closures.
En general es suficiente con sólo mencionar el término "closure" en el contexto de Java.
4. Espera una cantidad aleatoria de tiempo. Elige algún tema y trata de iniciar una discusión; SOA vs. ROA, (Ruby on Rails vs. Java EE), Thin vs. Rich, Ajax vs. Rich, (Swing vs. SWT), Netbeans vs. Eclipse, Java EE vs .NET, (SOAP vs. REST) y OSGI y JSR-277. Los que
están entre () son mas graciosos y alargan la conversación.
5. Utiliza todos los términos relacionados con Web 2.0, SOA, etc. No te preocupes del significado: nadie es capaz de definirlos.
6. Sugiere lenguajes más esotéricos como Haskell, Scala o Fortress pero no Malbolge para la realización del proyecto. En general no hay razón para hacer eso (Java funciona bien), pero por qué no?
7. No olvides la generación de código. A veces es suficiente con iniciar una discusión acerca de MDA vs. MDSD. Si nada ocurre pregunta a los desarrolladores acerca de PIM, PSM y transformación de código
etc.
8. Muy importante: menciona cosas como velocidad de equipo, programación de pares, pregunta acerca de Xtreme-programming, Agile, Scrum, Crystal, Test First, Mocking (cuanto más mejor).
Contrariamente al estilo de consultoría Voodoo, estas estrategias (o tópicos) cambian con el tiempo.
De modo que tu tienes que actualizar la lista de tanto en tanto.
A pesar de que tales "gurus" sobreviven varios proyectos, es relativamente fácil encontrarlos.
Sólo pregunta acerca de las razones de la decisión.