Jun 14

Google indiscreto

 Una pequeña estupidez. Cuando empezamos a teclear algo en google para buscarlo, se nos abre un desplegable con las frases que más hay en la web, de forma que si vamos a buscar lo "normal", lo tenemos más fácil. Pues bien, si vamos tecleando "tengo 1….", vemos que las preocupaciones de la gente de diez años para arriba van todas por el mismo lado

google indiscreto

Lo que me gustaría saber es si realmente hay tanta gente que busca "tengo 13 años y mi papa me pego porque me arrestaron por borracha stoy muy molesta". Creo que google a veces se lía un poco con tanto dato.

Visto en Emezetablog.

Jul 01

Ser o no ser héroes

 

Imagínate que caes en un equipo de desarrollo con gente competente, que saben lo que hacen y lo hacen bien. Tienes además la suerte de que el jefe de proyecto para el que trabajas también es un buen jefe de proyecto. Sabe lo que quiere, se lo cuenta al equipo con claridad y trata de resolver todos los problemas que se presenten. ¿Qué pasa en esta situación?. Lo normal. El proyecto va bien, sin problemas graves, llega a tiempo a sus fechas de entrega con unas incidencias razonables y sin fallos graves.

Suponte ahora lo contrario. Un proyecto en el que el jefe de proyecto no tiene claro lo que quiere, no te especifica nada, no te dice como lo quiere, pero sí te dice cuando ya los has hecho que así no lo quería. Además, el grupo de desarrolladores es más bien de la media para abajo, el poco código que sale está lleno de errores y si funciona, es de casualidad. ¿Qué pasa en esta situación? Pues lo normal, que el proyecto va mal, que no llega en fechas, que cuando se pasan las pruebas con cliente todo es un "efecto demo" gigante.

Entre los dos proyectos hay además una consecuencia interesante. En el primer caso, los jefes del jefe de proyecto apenas saben que existe ese proyecto. Es un proyecto que no da pegas, que no gasta más dinero de la cuenta, que no se retrasa y que no recibe quejas del cliente, así que la cosa "no sube" hacia arriba, así que para ellos no es más que una cifra bonita en alguna tabla de Excel.

En el segundo caso, empiezan a dispararse las alarmas, los jefes del jefe empiezan a recibir los problemas de dinero, fechas y quejas del cliente. Empiezan a saber que ese proyecto existe y empiezan a hacerle un seguimiento exhaustivo día a día. Se empieza a hacer presión y los desarrolladores y jefe de proyecto empiezan a echar horas como locos y se olvidan de que tienen casa.

En el primer proyecto, el buen jefe de proyecto y los buenos desarrolladores han hecho estupendamente su trabajo, pero no se les ha notado ni los jefes los van a valorar en lo que merecen. En resumen, "no son héroes".

En el segundo proyecto, si después de echar muchos fines de semana y horas a tope se consigue que el proyecto pase como se pueda, con un listado interminable de incidencias y cosas pendientes, con el cliente descontento, pero pasa, entonces los que han participado en él son la leche, han hecho un esfuerzo sobrehumano y han conseguido sacar adelante un proyecto que era un caos. Gracias a esto, los jefes de proyecto ya conocen las caras de los desarrolladores y del jefe de proyecto. Por supuesto, se han creído todas las excusas que el jefe de proyecto y los desarrolladores les han dado para justificar que el proyecto va mal. En resumen, "Sí son héroes".

Desgraciadamente, es la realidad. Se valora más al desarrollador que echa horas y horas resolviendo problemas en un proyecto caótico, que al desarrollador que no resuelve problemas a horas intempestivas de la noche, símplemente porque no ha generado esos problemas.

Jun 27

Tipos de debugger

 

Cuando queremos depurar nuestro código, hay tres tipos de debugger, que de menos evolucionado a más evolucionado son:

  1. Poner prints, compilar, ejecutar y mirar la traza. Ponemos más prints, volvemos a ejecutar y volvemos a mirar la traza. Así, por aproximaciones sucesivas, vamos aislando el problema hasta que damos con él.
  2. Usar un debugger propiamente dicho, el que venga con el compilador o el de nuestro IDE favorito. Ponemos breakpoints, watches, inspects y similares. Ejecutamos el códido y vamos dándole a "step over", "step into" y demás variantes. De esta forma, llegamos más lentos que en el paso anterior al error, ya que tenemos que aprender a usar el debugger y si apenas sabemos programar, es pedir demasiado.
  3. La opción buena. Cogemos nuestro proyecto y lo metemos un un zip. Hacemos un copy-paste del error/excepción que nos sale y lo subimos todo a varios foros junto con una explicación más o menos elaborada, pero sobre todo misteriosa (estilo "lo tengo todo bien pero no funciona"). Esta es la forma más cómoda, con un poco de suerte, el bug se soluciona solo y además usamos las metodologías más avanzadas (el internet) y compartimos conocimientos (otros pueden aprender de nuestros errores).

Lo siento. A veces me espanto con lo que veo en los foros …

Jun 11

¿La programación es una carrera que llena tu vida?

 

Leo en DosIdeas el siguiente post : ¿La programación es una carrera que llena tu vida ?. Precisamente eso es algo en lo que estaba reflexionando en días anteriores y ahí van los porqués.

En el curro me dedico o intento dedicarme a programar. Siempre he huído despavorido de ser jefe de proyecto, de un grupo o de cualquier otra cosa. ¿Por qué?. Por que pienso que todas las relaciones con clientes y en general con gente en ambiente de trabajo siempre acaba llevando a tener roces. Al principio con el cliente todo son buenas palabras, pero cuando los plazos empiezan a echarse encima y log bugs del sistema empiezan a aparecer y ser complejos de resolver, la relación con el cliente puede volverse tensa. Con los compañeros de trabajo, habiendo buen rollo, no suele haber problemas. Pero al llegar a las etapas finales de proyecto, la presión, los bugs y las muchas horas de más pueden llevar también a roces y discusiones. "Mi parte funciona, el bug es tuyo". "Y unas narices". Si ya entre compañeros puede llegar a ser tensa, no te digo entre jefe y curritos. Además, en momentos de presión, un jefe debe ser malo, debe conseguir que la gente se quede a echar horas y terminen a tiempo. Los jefes inútiles lo hacen amenazando, regañando, chillando e imponiéndose. Los jefes astutos (y esos son los peores), lo consiguen sin necesidad siquiera de pedirlo. Todavía recuerdo un Domingo que me quedé hasta las dos de la madrugada para un proyecto que pasaba pruebas el Lunes y lo peor es que la jefa de proyecto… ¡ ni siquiera me pidió que fuera el fin de semana !, consiguió que yo lo hiciera voluntariamente.

Sin embargo, cuando me dedico a programar es cuando realmente estoy en mi salsa. Puedo pasar horas entretenido, sin darme cuenta del tiempo que pasa. Y cuando consigo acabar algo o resuelvo algún bug especialmente complejo, es cuando más satisfecho me voy a casa. De hecho, cuando llego a casa, suelo encender el ordenador y ponerme a hacer/aprender cosas de programación o relacionas. Además de mi trabajo, es también mi hobby.

Sí, entiendo que si quisiese ser jefe de la forma tradicional, cogiera proyectos como jefe de proyecto, me dedicara con mi traje y corbata a aguantar y engañar al cliente y me importara tres pepinos "explotar" a mis compañeros, posiblemente cobraría más y estaría mejor considerado en la empresa, pero… a mi, por lo menos, no me merece la pena. Prefiero tener la conciencia tranquila y dedicarme a algo que realmente me gusta. Irme a mi hora a casa (salvo agún Domingo excepcional), llevarme bien con la gente y aprender cosas nuevas todos los días.

Apr 30

Test FourSight

 

Un poco jugando, un compañero mío ha propuesto que realicemos el test FourSight para ver el perfil de cada uno de nosotros. Yo, por supuesto, me he escaqueado hábilmente, por aquello de que no me gusta exhibir mis vergüenzas en público. Eso sí, lo he hecho luego, tranquilamente, en mi casa (supongo que el Lunes seré honesto con mis compañeros y lo llevaré para que lo vean).

Este test trata de ver tus puntos fuertes y débiles a la hora de afrontar problemas. Hay cuatro pasos a la hora de resolver un problema y según en qué pasos eres más fuerte (o tienes más gusto por dar), así es tu perfil. Esos cuatro pasos son:

  1. Análisis del problema. Una persona a la que sólo gusta este aspecto es un Clarificador.
  2. Generar ideas para resolver un problema. Este tipo de persona es Ideador.
  3. Analizar esas ideas para ver cual es mejor y planificar cómo llevarla a cabo. Este tipo de persona es Desarrollador.
  4. Solucionar el problema. Este es implementador.

Para ver tu perfil realizas un test en que contestas, poniendo crucecitas, en unas treinta y tantas preguntas. Luego sumas puntos y ves el resultado. Por supuesto, hay perfiles mixtos, en el que algunos de los puntos anteriores pueden ser más fuertes y otros más flojos. Cada uno de estos perfiles mixtos tiene un nombre, estilo "Acelerador" que es el que destaca en el análisis del problema y en solucionarlo, es decir, analizo el problema y me pongo inmediatamente a implementar la primera solución que se me ocurre, sin evaluar alternativas ni sopesar pros y contras de cada una de ellas. Otro es el "Conductor", que no analiza el problema, se le ocurren muchas ideas para solucionarlo, no mira pros y contras de cada una de ellas y rápidamente se pone a implementar una de ellas, o todas a la vez.

¿Qué me ha salido a mí?

Pues soy un "corredor de ideas". Según el test, me salen valores altos en 1,2 y 4, pero muy bajo en 3. Es decir, me gusta entender el problema, se me ocurren muchas posibles soluciones, no analizo los pros y contras de cada una de ellas, sino que elijo la que intuitivamente más me gusta, y me lanzo a implementarla.

¿Cual es el objetivo del test?

Bueno, como he comentado, lo hemos (lo han) hecho un poco jugando, pero la idea de este test es doble:

  1. Por un lado, que cada uno conozca sus puntos flacos para intentar reforzarlos. Me aplicaré el cuento, tengo que analizar un poco las ideas que se me ocurran para ver cual es mejor antes de lanzarme a hacer cosas.
  2. Por otro lado, en un grupo de trabajo, conviene poner junta a gente que se complemente. En mi caso, se supone que trabajaría bien con alquien que tenga fuerte el tercer punto, en el que yo flaqueo. Alguien que sea capaz de ver los pros y contras de las ideas que se generen y sepa elegir la mejor y planificar cómo llevarla a cabo.

 

Dec 19

¿Es bueno dejar las cosas a medias?

Obviamente, la mayoría de la gente responderá que no, que cuando se empieza una cosa, hay que acabarla. Sin embargo, tengo mis dudas.

Yo soy de esas personas que les gusta, en temas de programación, jugar y aprender cosas nuevas. En casa miro perl, python, grails, últimamente ando mirando groovy y multitud de herramientas que hay por ahí. Soy un poco caótico y cuando aprendo un lenguaje, en vez de leerme unos manuales antes de empezar, decido que la forma más entretenida es hacer directamente un programa que haga algo, a ser posible un programa no muy complejo, pero tampoco trivial. Por ejemplo, para perl hice un script que cambia tipos de ficheros .h a clases Java. Con python hice una pequeña web para pedir a los desarrolladores las horas dedicadas a cada proyecto y almacenarlo en una base de datos, etc.

¿Cual es el problema?. Muchas veces el programa que me propongo hacer es más complejo de lo que pensaba en principio y llego a un punto en que no me apetece seguir con ese programa. Ya he aprendido lo que quería del lenguaje (o se me ha pasado la "novedad" del asunto) y lo que me queda del programa que me propuse es ya rutinario y pesado de hacer.

Llegado a ese punto, puedo "emperrarme" en acabarlo, pero el resultado final es que me da pereza la tarea y me paso varios días o semanas que no sigo con él y tampoco empiezo un tema nuevo porque quiero terminar el que tengo a medias. Me está pasando actualmente con un programa que me propuse hacer para el móvil, usando J2ME: un cuatro en raya. Ya he aprendido lo básico para meter un programa en el móvil y codificar con el Midlet y hacer gráficos, pero me he quedado atascado en el algoritmo para que el ordenador sea capaz de jugar al cuatro en raya. Por supuesto, sí tengo una idea de cómo hacer el algoritmo que sé que no es la mejor, pero sí lo suficientemente válida como para ganar a un humano no muy avispado, pero el problema es que tengo que implementarlo. He empezado a hacerlo, pero me da pereza depurarlo y acabarlo. Y ahí estoy, que no avanzo en mi juego ni empiezo otros temas. Y llevo ya tres o cuatro semanas en ese plan.

Me pasa lo mismo con las novelas. Si una novela empieza a no gustarme y me obligo a acabarla, el resultado es que paso varias semanas sin leer. No empiezo una novela nueva porque tengo otra a medias, pero no acabo la que tengo a medias porque no me gusta.

Por eso pienso que, si te no querer dejar algo a medias te bloquea, es mejor dejarlo a medias y desbloquearse. Tanto en novelas como en ordenador, hay muchísimas opciones y si por la que has tirado no te convence o deja de gustarte, puedes saltar alegremente a otra. Muchos dirán que así no llegaré a conocer en profundidad ningún lenguaje, y tienen razón. Pero también hay que pensar que por mucho que me esfuerce en casa como hobby, tampoco voy a llegar a conocer nunca un lenguaje con la misma profundidad que si trabajo con él, ocho horas al día, varios años y compartiendo experiencias y problemas con mis compañeros de trabajo. Así que, puesto que voy a aprender superficialmente en cualquier caso y que en casa lo hago como hobby para entretenerme, ¿no es mejor hacer "lo que te pide el cuerpo" que "obligarse" a seguir con algo que ya no te llama la atención?.

Yo pienso que sí, aunque a veces da rabia no terminar lo que has empezado.