LUA. No te olvides de la memoria

Si desarrollas una aplicación en LUA no olvides siempre monitorizar la memoria ya que si no lo haces tu programa (que parece que funciona correctamente) te bloqueara el modulo al cabo de unas cuantas ejecuciones.

La forma de mirar la memoria es:

 print(collectgarbage("count")*1024);

Si no controlas la memoria el modulo te respondera algo como:

PANIC: unprotected error in call to Lua API (not enough memory)

Revisas el codigo alguna vez

El reducido tiempo de los proyectos (y el no saber hacerlo de otra manera) hace que las revisiones, pruebas, evaluaciones, etc.. Se centren todas en los resultados; en lo que puede hacer la aplicacion y no como esta hecha  por dentro.

Uno de los motivos por los que los programadores siempre creen hacerlo todo bien cuando terminan un desarrollo es que nadie revisa su codigo.

Se debe  gastar tiempo en revisar el codigo para comprobar:

• Se sigue el marco de trabajo.
• No se crean algoritmos grandes y complejos.
• Se hace un codigo mantenible.

No quemarse y no dejar que se quemen

En realidad esta buena practica sirve no solo para un proyecto de software y se puede aplicar a cualquier trabajo prácticamente.

Hay que estar siempre pendiente de tu estado de animo y no dejar que un proyecto de desarrollo de software te queme. Hay muchas formas de que un trabajo te queme pero voy a centrarme en las dos mas generales: echar mas horas de las que te corresponden y hacer un trabajo que no te gusta.

¿Como evitar quemarse?

- Si echas mas horas de las que te corresponde entonces puedes llegar a quemarte y adoptar aptitudes muy compulsivas (como por ejemplo estar en la situacion de "a las 18 es mi hora de salida y me voy". Me da igual dejarlo todo mal). Lo que debes hacer es tener una visión mas a largo plazo y tener tus propios mecanimos que te compensen el  echar uno o varios dias mas horas. Por ejemplo, la mayor parte de dias de trabajo son intrascendentes por lo que una buena practica es "vale, hoy me he quedado dos horas mas porque era necesario para el proyecto pero la semana que viene vendre a trabajar dos dias una hora tarde".

- Si haces un trabajo que no te gusta entonces puedes llegar a quemarte y adoptar aptitudes muy pasiva (como por ejemplo estar en la situacion de "puff llevo aqui tres horas y solo he escrito dos lieneas pero no tengo ganas de hacer mas"). Lo que debes hacer es tener una visión mas proactiva y tener tus propios mecanimos que te permitan buscar la parte mas interesante de tu trabajo. Por ejemplo, todos los trabajos (sobre todos los aburridos) se pueden mejorar, saca tiempo laboral para investigar como se puede mejorar la forma de trabajar y si consigues que al final en tu trabajo se adopte tu propuesta de forma de trabajar entonces te sentiras mas realzado.

Si eres jefe de proyecto entonces no solo tienes que no quemarte. Ademas tienes que evitar que se quemen tus trabajadores. En el momento que notes que alguno se quema actua (cambia al trabajador de tarea, planteale que desarrolle una mejore, cuentale un chiste, ... ) y no lo dejes que vaya a mas porque puede llegar a un punto donde ya no tenga solución.

La fe en lo empirico

Si tienes un puesto con un minimo de resposabilidad se te exige que tomes decisiones en lo que realemente no importa la decision que tomes. Solo importa que el resultado de tomar esas decisiones sea el correcto.

En muchas ocasiones se te presenta la tesitura en la que tienes que elegir un camino para afrontar una situación a sabiendas que el elegir una opcion u otra puede tener mucho impacto en el desarrollo de un proyecto.

Por ejemplo, tengo 10 incidencias que abordar para esta semana y las 10 no pueden estar porque no hay tiempo para solucionarlas todas ¿que hago?:
- ¿Soluciono estas 3 incidencias que son de la misma funcionalidad y asi cierro esta funcionalidad?
- ¿Soluciono estas 7 incidencias y asi soluciono el mayor numero de incidencias posibles?
- ¿Soluciono estas 5 incidencias que son las que tienen mas visibilidad?

Cual es la correcta?

Pues cualquiera puede ser la correcta pero es una loteria porque todas estan basadas en la forma inicial del problema. No en el resultado. La forma correcta es empezar por el resultado. Seguimos con el ejemplo,
¿Cual es el resultado valido? Pues la experiencia me dice que las 10 incidencias tienen que estar solucionadas, no puedo dejar ninguna fuera. Me han dado una semana pero mi experiencia me dice que si empiezo por las incidencias mas dificiles al final de la semana puedo justificar que no da tiempo y conseguir mas tiempo y al final tener las 10 incidencias.

En este ejemplo, te basas en la experiencia para saber cual es el resultado valido y saber como afrontar el problema pero te estas "ariesgando" mucho porque ¿Seguro que tienen que ser las 10 incidencias si o si? ¿Como sabes que te van a dar una semana mas?. Pues muy sencillo, ten fe en lo que ya sabes.

Hablar con los subordinados

Cuando te toca hablar con los subordinados tienes que mostrarte de una manera determinada que puede ir de entre los dos extremos: dialogante  y autoritario. Vamos a analizar lo positivo y lo negativo de ambas extremos.

Dialogante:

Positivo:

Si te perciben como una persona dialogante entonces se mostraran comodos hablando contigo y potenciaras su creativadad.

Mejoras tu empatia y puedes ayudar a los subordinados a decir lo que saben pero no saben explicar.

Negativo:

Al mostrarte dialogante provocas que no tengan que tomar decisiones por lo que se vuelven mas dependientes.

Un exceso de dialogo provoca que un subordinado crea que pueda hablar contigo de todo. Muchas veces te comentara cosas repetitivas que ya deberían saber (potencia el conformismo).


Autoritario:

Positivo:

Tendrán mas cuidado en lo que te comentan por lo que auto-obligaran a estar mas preparados.

Seran mas precisos y meticulosos en su trabajo.

Negativo:  

Si empiezan a tenerte miedo pueden ocultar fallos con el proposito de no contartelo.

Pueden engendrar un resentimiento que afecte a su trabajo y  al de sus compañeros.

Son muchos aspectos y puede dar la sensanción de que hagas lo que hagas vas hacer algo bien y algo mal. ¿Que debes hacer? Mantener un equilibrio habra ocasiones que tendras  que ser dialogante y
otras que tendras que ser autoritario.

Lo que si es seguro que hay que seguir las siguientes pautas:

• Hay que saber identificar cuando y con quien debes ser autoritario o dialogante.
• No hay que enfadarse nunca. Rotundo si. Furioso no.
• No puedes equivocarte. Te pueden convencer de lo contrario de lo que piensas pero si no sabes si llevas razon, no insistas.

Saber explicarse

No saber explicarse tiene muchos aspectos que afectan al trabajo de los profesionales del software:

• Es una características que puede convertir a un buen programador/jefe/funcional/etc... parecer mediocre y viceversa (es decir a un profesional que SI sabe explicarse, que en verdad es un "vendemotos", en un profesional muy valorado).
• Supone la diferencia en que se haga lo correcto (o la mejor opcion dentro de lo correcto) o que no se haga ya que si no sabes explicarte entonces las conversaciones y/o reuniones (donde se decide que se hace en el desarrollo) las "ganará" otra persona y serán sus ideas las que se desarrollen.
• Es un motivo de frustración para el profesional. Un buen profesional sabe lo que tiene que hacer ante un desarrollo y/o problema pero si no sabe explicarse puede que en la conversacion y/o reunion donde se decide todo se decida lo que ha explicado mejor otra persona (pero que el profesional que no sabe explicarse sabe que no es correcta). Por lo que se da el caso de que el buen profesional que no sabe explicarse se vea desarrollando una solución que sabe que es incorrecta.

¿Como puedes explicarte mejor? A continuación enumero una serie de buenas practicas para mejorar la forma de explicarse:

• Practica. Practica. Practica. Ya sea en conversaciones y/o reuniones donde se decide que se hace en el desarrollo o simplemente con un compañero de trabajo que tienes al lado intenta explicarle de vez en cuando lo que estas haciendo y porque crees que es la mejor opción.
• Asegurate que todos en la reunion/conversación hablen el mismo idioma. Con esto no quiero decir que hables todos ingles, español o frances (doy por sentado que todos hablais el mismo lenguaje) sino que usais las palabras del mismo modo. Por ejemplo, si dices algo como: "el modulo A hace de interface de usuario" luego en la conversación/reunion no digas algo como "el componente A hace de interface de usuario" si en las dos ocasiones te referias a lo mismo. Es decir, utiliza siempre la misma palabra para referirte al mismo concepto.

 

Desconocer como se hace bien