viernes, 10 de julio de 2009

Jueguitos de viernes: Orbitz

En Orbitz tenemos que guiar a nuestro personaje hacia la salida saltando a de planeta en planeta y recogiendo estrellas… uno de plataformas, bah.

Pero la cuestión se complica: los diferentes tamaños, fuerzas de atracción y superficies (tierra, hielo) y algunos bichos en cada planeta nos mantendrán entretenidos toda la tarde.

orbitz

jueves, 9 de julio de 2009

Evitando la claustrofobia.

En LLeva a tus monitos de paseo divagaba sobre la importancia de “sacar” a los programadores al mundo real en cada oportunidad que se presente, llevarlos (no a todos juntos como a un grupo de jardín de infantes al zoológico, se entiende) a las oficinas de los clientes, a las reuniones, a los relevamientos, a las charlas de capacitación, etcétera.

En aquel post justificaba la actividad mencionando los beneficios de conocer las particularidades del negocio para el cual programan y diseñan, su entorno, los clientes, los usuarios: una transmisión más precisa de ese otro paradigma a los sistemas en los que se materializa, más sentido común en la interfaz del usuario, la posibilidad de encontrar nuevas ideas o herramientas… Beneficios, en definitiva, para el producto, para la empresa proveedora de software y para el cliente.

Ayer @rgil, que viene del lado de la consultoría, publicó El "arturo" y los estereotipos, cuya (breve) lectura recomiendo y de donde cito:

Hace unos días vino un consultor de una de estas grandes a una entrevista de trabajo. Le entrevistaban dos personas que, casualmente, habían trabajado en empresas de ese tipo [una de las Big Four]. Precisamente por eso, no podían dejar de reírse al comentar la entrevista y los términos que utilizaba "el arturo": "quiero pasar a cliente final", "¿cual es la denominación exacta del puesto?", "¿a quién debo "reportar"?", "¿cuales son las funciones y necesidades del puesto?", "¿cual será la estructura de mi equipo?"...

El consultor empleado de la gran empresa multinacional, tan empapado de esa cultura que ya no la reconoce como propia de un entorno particular, que la ha internalizado tan profundamente que choca al salir de ese entorno (aunque sea de esta forma que describe el artículo, más bien simpática, resultando ligeramente extravagante) es comparable al programador rodeado de programadores, algoritmos, patrones de diseño, clases, herramientas, e incapaz de sustraerse de ello.

sheldon-green-lantern Si cuando vemos una factura sólo vemos una relación cabecera-detalle, si cuando vemos una hoja de ruta sólo pensamos P=NP… tenemos un problema. El aislamiento profesional nos convierte en el estereotipo de nuestra profesión, de una manera que puede resultar desde simpática a patológica.

Salir, conocer otros ambientes, otros profesionales, otras personas, nos entrena no sólo para construir mejores sistemas (si sólo pensamos en función de eso, es el mismo problema), sino también para ser un poco más normales.

En LLeva a tus monitos de paseo los beneficios y la responsabilidad de establecer esa buena práctica estaban del lado de la empresa u organización. Aquí, ya que hablamos de beneficios (casi diría de necesidades) personales, tenemos que ubicar la responsabilidad de nuestro lado. En principio, responsabilidad de detectar el problema, de darnos cuenta de que estamos trabajando aislados profesional o personalmente para luego hacer algo al respecto.

Un equipo debe tener una fuerte cohesión, eso es indiscutible. Pero que la unanimidad sea la norma para todas las decisiones, que todos a nuestro alrededor adopten naturalmente el mismo punto de vista sobre temas controversiales o tiendan hacia las mismas soluciones o tengan los mismos gustos, pasatiempos y distracciones (¿son realmente distracciones?) debería, cruzada cierta frontera (difícil de establecer, pero desde el afuera se reconoce claramente), encender una alarma. Sentirse cómodo en el ambiente laboral es indispensable, pero demasiado cómodo ya es un poco preocupante… e incómodo fuera de éste es clara señal del problema.

La solución es tan simple y difícil como salir de vez en cuando. Si puede proponerse dentro de lo laboral, tomando responsabilidades o tareas que impliquen interacción con el afuera, mejor. Pero si esto no es posible habrá que buscar esas actividades y encontrar el tiempo para llevarlas a cabo. Es para nuestro propio beneficio, por lo que no debemos esperar a que un jefe o una oportunidad laboral nos lo sirva en bandeja.

Por suerte internet nos deja sin excusas para no conocer, aunque sea virtualmente, el exterior. Con tanto blog personal y profesional y conversación y web 2.0 las herramientas para la comunicación están ahí, al alcance de la mano. Es sólo cuestión de utilizarlas.

Más allá de eso, cursos, seminarios, ponencias, congresos… son buenas oportunidades para relacionarse con otros profesionales de nuestra área (pero de distintos entornos laborales). También podríamos participar de eventos no están relacionados con la informática o el desarrollo sino con el negocio para el cual servimos en un momento determinado.

Y creo que, si bien no es indispensable, es bueno tener alguna verdadera distracción, un verdadero hobby no tan relacionado a la vida profesional. Una actividad en la que refugiarse en momentos de saturación y que nos desconecte de vez en cuando.

5 errores no técnicos que usualmente cometemos los programadores.

Un muy buen artículo de Making Good Software en el que se detallan y comentan 5 errores no técnicos que usualmente cometemos los programadores:

  1. Falta de disciplina.
  2. Orgullo (“big ego”).
  3. Ser un mal comunicador.
  4. Olvidarse del cliente.
  5. No priorizar el trabajo apropiadamente.

¿Se sienten identificados con alguno? Me declaro culpable del 1 y del 5 (aunque espero que al ser consciente de ello esté logrando mitigarlo un poco)… A leer el artículo completo (en inglés). Me llegó twiteado por @programmingjoy.

martes, 7 de julio de 2009

Resistencia al cambio.

Por cierto que la entrada Sistemas administrativos, software y poder, y sobre todo la referencia a la resistencia al cambio me ha hecho acordar de este video, que no por harto conocido es menos gracioso.

Y hasta tengo como un déjà vu de haberlo posteado, pero si así lo hice no logro encontrarlo, así que ahí va de vuelta.

lunes, 6 de julio de 2009

La carrera.

Otro gran aporte de @Cerebrado, que esta vez ubicó en Izismile una serie de ilustraciones que recorren una conocida historia desmotivacional: The Management Rowing Race.

domingo, 5 de julio de 2009

Criterios para diferenciar entre programadores Junior, Semisenior y Senior.

Saltando y revolviendo entre cosas viejas me encontré con Diferencias entre programadores Junior, Semi Senior y Senior en Casi un buen blog, de Diego Salama. Es un artículo muy completo y prolijo que resume los criterios que ayudan a definir el nivel de seniority de un programador. En él se detallan, con una breve descripción general y para cada categoría:

  • Conocimientos técnicos.
  • Conocimientos funcionales.
  • Proactividad.
  • Seguimiento requerido.
  • Indicadores de productividad.
  • Cumplimiento de fechas.
  • Respuesta bajo presión.
  • Relación interpersonal.

Al fondo hay una encuesta. Interesante porque no coincido del todo con la opinión de la mayoría... será tema para otro post.