La ambición como motor de la superación

La mayoría de nosotros consideramos la ambición como algo negativo, solemos utilizarlo de manera peyorativa porque nos viene a la mente la típica persona con una filosofía muy clara “el fin justifica los medios”. Socialmente sabemos que destacar no está bien visto, como tampoco el inconformismo y mucho menos la ambición, pero si queremos mejorar cualquier aspecto de nuestra vida, la ambición es un motor necesario.

Tenemos completamente estigmatizados los conceptos de ambición y más si lo asociamos a empresario y empleado. Un empresario con ambición solo piensa en ganar dinero, un empleado con ambición es un trepa, en cambio un emprendedor con ambición es un creativo luchador Como normal general, cuando hablamos de los empresarios, asociamos su ambición a la avaricia y a la falta de escrúpulos, de igual forma que cuando tenemos un compañero inconformista y ambicioso, no hay duda que es un auténtico trepa.

Vamos a ponernos a pensar en un empresario, un emprendedor y un empleado sin ambición. ¿Cuál de los tres sería capaz de “sobrevivir” en el mercado laboral?

Empresario sin ambición: Si partimos de la base que quedarse en la “famosa” zona de confort es carecer de la ambición necesaria para mantenerse en este mercado competitivo y en constante transformación, una empresa que no busca la mejora continua está abocada al fracaso, por tanto la ambición debe formar parte de la personalidad del empresario.

Emprendedor sin ambición: No tiene ningún sentido ser emprendedor sin ambición, es básico en las personas emprendedoras su predisposición a buscar nuevos retos y luchar en cumplirlos.

Empleado sin ambición: Puede “sobrevivir” en tan solo una situación: Si el empleado está contento desempeñando su trabajo y el puesto no requiere nada más que se realice correctamente, sin aspiración de nuevos retos. (Este tema es muy importante a la hora de seleccionar y gestionar el talento)

Foto obtenida de la página web desmotivaciones.es

No hay ninguna duda que si queremos mejorar o evolucionar profesionalmente, la ambición es imprescindible,e incluso en algunas profesiones puede marcar la diferencia. En tecnología, los mejores profesionales que he conocido tiene ese “puntillo” ambicioso que les empuja a:

Buscar soluciones creativas
Ayudar a los demás a que logren sus metas
Percibir los obstáculos como retos que hay que alcanzar
Conseguir sus propósitos y sus sueños como parte de su crecimiento personal
Ser autocríticos y humildes, gracias a su interés en mejorar y evolucionar
No sentir la necesidad de estar continuamente probando que son capaces de alcanzar todo lo que se propongan
Valorar y sentirse satisfechos con los logros obtenidos
Centrarse en mejorar cada día sin estar pendientes de controlar y “fulminar” a posibles competidores
Estar siempre preparados, listos y actualizados
Dedicar parte de su tiempo libre a aprender.

Conseguir lo que ahora mismo no somos, no hacemos o no tenemos forma parte de la ambición humana y no es ningún problema. La ambición es el término medio entre la codicia y la avaricia, no queremos ser y mucho menos tener a nuestro lado personas tóxicas (como hablamos en post anteriores), pero está demostrado que si queremos cambiar cosas que no nos gustan de nuestra vida, necesitamos ambición, bien encauzada para impulsarnos a hacer las cosas mejor, a no rendirnos, a ser perseverantes y a no “tirar la toalla” ante cualquier obstáculo que se nos presente. Nos permite ser capaces de disfrutar del proceso y genera gran satisfacción cuando nuestros éxitos son alcanzados, gracias a nuestro esfuerzo, motivación y actitud.

Como en casi todo en nuestra vida, es en el término medio donde está la virtud. La ambición en su justa medida está satisfecha de lo que tiene y no le obsesiona lo que no tiene

Posted on mayo 19, 2013 by Emma in Blog Leave a comment

Amor y motivación: Consultora vs Compañía de productos

Es curioso como uno puede sentarse, indagar en internet y encontrarse opiniones de trabajadores de Google, Linkedin, Microsoft, Facebook (por citar de las más conocidas a nivel mundial) y recibir una onda de “buen rollismo”, pasión, energía y ganas por innovar que despiertan ese pequeño emprendedor, inquieto de mente y de corazón que todos llevamos dentro.

Es una sensación que nos atrapa y nos hace mirar a nuestro alrededor de una forma distinta, parece que ese trabajo ideal existe, pero debe estar en una realidad paralela a la que muy pocos tenemos alcance. Seguro que a todos nos ha venido la mente: buen salario, salas de recreo, multitud de beneficios sociales, etc, y sí, todo eso ayuda, pero curiosamente nunca es lo primero que destacan.

Sus primeras palabras pueden resumirse en una frase: “Somos un gran equipo y estamos haciendo algo importante“, y nosotros nos preguntamos: ¿Por qué en las consultoras (parece) que no hay cabida para esas sensaciones?

Las consultora ofrece sus servicios a un cliente para que este pueda crear o mejorar un producto: aumentando la productividad, mejorando sus procesos logísticos o de comunicación, reduciendo costes, etc, en definitiva: Vender más y mejor, asegurando la continuidad de sus trabajadores y por tanto de la empresa.

En el siguiente vídeo que mostramos a continuación, los testers de Microsoft (esa gente que crea y realiza los test de sus productos) demuestran la motivación por el producto. ¿Habéis tenido en algún momento de vuestra experiencia profesional esa sensación?

¿Por qué estas diferencias?, ¿Por qué no vemos la misma motivación en una empresa de consultoría que en una empresa “de producto”?. Equivocados o acertados se nos ocurren algunos motivos:

Marca de empresa vs Marca de producto

La empresa asigna a sus trabajadores a un proyecto (solos o en UTE) como “recursos” (ya salió la p*** palabra) de la empresa X, bajo su política y filosofía de empresa: códigos de conducta, vestimenta, horarios, normas, etc. En definitiva, con la marca de la empresa por delante y dejando en un segundo plano, el proyecto en el que se participa.

En una empresa “de producto”, el producto es lo más importante, es superior al de la marca de empresa. Representar a la marca producto es el objetivo para la marca de empresa.

Equipo de producto vs Equipo empresa

Relacionado con la marca de empresa está el “equipo empresa”. La necesidad, por encima de todo de sentirse responsables y propietarios de un producto (sin olvidar tu empresa). La idea del emigrante que para triunfar debe adaptarse y ser parte de su nuevo destino sin olvidar su hogar.

La compañía “de productos” entiende la importancia del equipo de producto y su importancia diaria sobre el “equipo empresa”, una identificación 100% al producto sin olvidar sus valores de empresa.

Sentimiento de pertenencia del producto

Estar contratado por una empresa y llevar a cabo el proyecto para un cliente, dificulta la sensación de identificación y pertenencia del proyecto, y por tanto la motivación por construir el mejor de los productos.

En una empresa “de producto”, el equipo se identifica totalmente con su actual proyecto porque es un reto estratégico para la compañía, y ellos son el mejor equipo para hacerlo.

Conciencia de relevancia e impacto de un proyecto

No sentir el proyecto como propio, implica estar completamente cerrado a entender conceptos tan vitales como alcance, importancia, relevancia, impacto. En la empresa “de producto” entender y conseguir la identificación de esos conceptos es imprescindible para motivar y potenciar las ganas por crear el mejor de los productos.

Querer al producto vs querer al cliente

Transmitir “amor” por el producto es el motor en la creación de un producto que el cliente ame. Un cliente que ame el producto, amará al equipo y pagará por él. Una empresa “de producto” sabe que la mejor forma de conseguir clientes es enamorándoles de sus productos.

¿Pueden estas “diferencias” ser solventadas?, ¿Podrían las consultoras cambiar para conseguir una mayor motivación entre sus trabajadores?, ¿Sería posible ese cambio?.

Para conseguir estos cambios, no sólo debe cambiar la compañía en la que trabajamos, sino que debe ser capaz de GUIAR a sus clientes hacia una nueva metodología de trabajo, una nueva forma de entender y afrontar un proyecto tecnológico.

Si no se consigue dirigir al cliente hacia la forma de trabajo que nosotros consideramos que es la mejor, sin duda que no se podrá introducir los cambios necesarios para favorecer y mantener la motivación de los trabajadores. ¿Tan complicado es que todos vayamos en la misma dirección y nos acompañemos en la consecución del objetivo?

Para finalizar, nos encantaría recomendar estos 18 minutos de vídeo sobre la importancia de la motivación intrínseca basado en un modelo en el que las empresas deben girar entorno a tres conceptos: autonomía, maestría y propósito.

Google, Microsoft, Atlassian ya tienen ese modelo. Son conscientes del desajuste entre lo que la ciencia sabe y lo que la empresa hace.

¿Cómo es el modelo de tu empresa?, ¿Sería posible implantar el modelo de la compañía de productos en las consultoras?, ¿Amas tu trabajo?

Posted on mayo 5, 2013 by Ángel Cereijo Martínez in Blog, Colaboradores 2 Comments

Saberlo todo

Con el paso de los años, las razones de las ansiedades cambian: del inoportuno acné antes de una fiesta a la muñeca agotada que nuestra hija desea para reyes. De la paga mensual que no alcanza para comprar el trapito de moda al depósito que ofrece menos interés que el de otro banco. Y de repente, la sensación cada vez más profunda de la propia mortalidad, que palidece – eso sí – en comparación con las grandes preguntas de la experiencia humana. No pensamos siempre en ellas – tal vez para evitar sentirnos abrumados – pero están ahí. El origen de la vida y su sentido, si es que alguno tiene. La composición y funcionamiento del universo. Nuestro lugar en el mundo.

A medida que al reloj le queda menos recorrido, al corazón fatigado menos litros por bombear y que la fecha de caducidad está más presente, todas las preguntas llevan a una necesidad imposible de satisfacer, que me provoca una angustia intermitente: saberlo todo. ¿Cuál es el verdadero significado de estas dos palabras? ¿Cómo enfrentarse a ellas? Responder a estas preguntas puede ser una buena terapia para superarla.

Hemos tenido la suerte de vivir -al contrario que casi todos nuestros antepasados- en esta época de conocimiento accesible, con el mundo cartografiado, una ventana abierta a lo más pequeño, subatómico, y otra a lo más grande, universal. Usando Internet, podemos llegar a conocer un dato del que tengamos necesidad, en cualquier momento y lugar. Atrás quedaron las discusiones de bar que se prolongaban durante horas. Hoy, con un smartphone, los puntos de vista contrarios se enfrentan a la solución instantánea.

Hay millones de páginas escritas, libros y webs, repletos de información más o menos veraz o valiosa. Las “infinitas palabras”, que cantaba Drexler. Aunque dedicáramos nuestra vida a intentar leerlas – y tuviéramos la capacidad de comprender – no las abarcaríamos todas. Y aún así, sumando todo el conocimiento que contienen, no es más que una pequeña fracción del posible. La información ausente cae dentro de dos grupos:

Conocida pero inaccesible o de acceso ineficiente. Los nombres de todos los habitantes del planeta, desde que estos tienen nombres. La temperatura en la región que hoy se llama Madrid a mediodía del 12 de noviembre de 375. Incluso la fecha de nacimiento de un tatarabuelo. Son informaciones que no podemos conocer, ya sea porque no están registradas o por el esfuerzo inasumible para acceder a ellas. Son lágrimas de replicante.

Información desconocida. ¿Cuántos planetas habitables hay en el universo? ¿Cuántas civilizaciones similares a la nuestra existen? Preguntas abiertas para las que no tenemos respuesta y ni siquiera sabemos si podremos llegar a tenerla. Un paso más allá, en un escalón más de nuestra ignorancia están las respuestas a aquellas preguntas que no podemos plantear. ¿Dónde están los límites del futuro conocimiento humano?

Por eso, si pierdo mis llaves, me da igual la posición de cada uno de sus átomos. Con una idea aproximada de donde las he dejado, suficiente para que no pertenezcan al primer grupo de incógnitas, estaré satisfecho. No necesito saber como extraer una muela, pero no estaría de más conocer la dirección del dentista más cercano, porque el conocimiento disponible es colaboración. Es decir,debemos centrarnos en la información relevante y que lo sea – o no – depende de cada uno.

A parte de la desesperación y cierta tristeza – a evitar -, he aquí unas ideas para enfrentarse a la sensación de ignorancia casi absoluta:

Aceptar que saberlo todo es imposible. De verdad. Repetirlo mentalmente cuando sientas que te estás perdiendo algo.
Definir la información relevante para ti. Volver a definir cuando – es inevitable – tus intereses cambien.
Convertirse en un rastreador de las fuentes de información fiables. En estos tiempos, es mejor razonar y entender que memorizar.
Tomárselo con menos dramatismo y seriedad. Al final, no tiene tanta importancia.

Hay escritas infinitas palabras: Zen, gol, bang, rap, Dios, fin…

Posted on abril 14, 2013 by Félix Menéndez Rodríguez in Blog, Colaboradores 2 Comments

El desarrollo como escritura

Hace poco me preguntaron: ¿Qué profesión habrías elegido si no pudieses ser desarrollador? La respuesta, meditada con años de antelación, sonó como un impulso: Escritor.

Desde que era un adolescente timorato e introvertido, la literatura ha estado ahí, compañera de viaje. Al principio, lector ávido de novelas de ciencia ficción. Después, a sugerencia de un profesor del instituto, algunas joyas de las letras universales. Por último, creador de pequeñas obras, ensayos, poemas.

Como todo autodidacta, al principio crees que tus trabajos son de calidad abrumadora, te asombra la facilidad con la que puedes avanzar e imaginas que tienes un talento natural para el oficio – el efecto Dunning-Kruger. Las primeros críticas y un par de manuales de iniciación te ponen los pies en el suelo. Revisas tus frases, buscando los errores frecuentes que señala el libro de estilo, y están ahí, burlándose de ti. Miras en los párrafos y la misma palabra repetida diez veces te golpea. Páginas que se suceden, sin coherencia interna, sin estructura. Llegan las dudas. Perseveras. Aprendes más. Y, de repente, te das cuenta de que la clave no está en plasmar las ideas sobre el papel en su forma perfecta y final, sino en la edición posterior.

Cuando desarrollo y cuando escribo noto como se activan partes similares de mi pensamiento. Existe un paralelismo entre ambas profesiones, puntos comunes, sin llegar a ser idénticas. Como dice Robert C. Martin - nada sospechoso de ser mal desarrollador – en Clean Code:

Writing software is like any other kind of writing. When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read.

When I write functions, they come out long and complicated. They have lots of indenting and nested loops. They have long argument lists. The names are arbitrary, and there is duplicated code. But I also have a suite of unit tests that cover every one of those clumsy lines of code.

So then I massage and refine that code, splitting out functions, changing names, eliminating duplication. I shrink the methods and reorder them. Sometimes I break out whole classes, all the while keeping the tests passing.

In the end, I wind up with functions that follow the rules I’ve laid down in this chapter. I don’t write them that way to start. I don’t think anyone could.

En este fragmento aparece, no obstante, una de las diferencias más importantes que debilitan la analogía escritura – desarrollo. El código fuente de un proyecto es como un libro que nunca llega a publicarse del todo o sujeto a cambios después de su publicación. Los cambios pueden ser insignificantes (el color de la chaqueta del malo en el capítulo siete) o devastadores (queremos que el protagonista muera en el capítulo dos).

Posted on marzo 20, 2013 by Félix Menéndez Rodríguez in Blog, Colaboradores Leave a comment

¿Eres buen o mal desarrollador de software? Rockers Developers

Orgullosos de su trabajo, defienden con convicción que su profesión es un arte. Guitarristas del código, mentalidad creativa y corazón inconformista, la esencia de los Rockers Developers.

“Ladies and Gentlemen, We are Floating in Space”

David García: Desarrollador de acción, vocalista y guitarrista de vocación. En su momento no tuvo miedo a rememorar el postgrunge con su grupo Los Niños Muertos, ahora su guitarra es el teclado y su espectáculo, la discreción.

Con respecto a la afirmación “Good developer develops features which create value for customers. Bad developer completes tasks. Good developer will never claim the requirements are incomplete, and will make sure to fully understand the features he’s working on. Bad developer will wait until the finest details are available. To emphasize: good developer is the CEO of the feature – he’s going to make sure he always has the information needed to accomplish the feature, and in case information is missing he’ll make sure he gets it” David reflexiona y nos cuenta:

Se supone que estás ahí porque lo has elegido, haciendo eso que haces porque tu quieres. Puede ser que no tengas el control al 100%, pero tienes los vientos, las corrientes, incluso las estrellas, y sabes navegar … ya sabes lo que hacer.

Si has llegado ahí de ese modo es imposible que no tomes partido en tu trabajo, que de algún modo no lo empujes con la visión que desde un principio tengas de la imagen final. Efectivamente eres “CEO of the feature” porque eres el responsable de tu trabajo.

Es todo un montón de obviedades, pero son las cosas que la rutina, el tiempo y la inercia te pueden hacer olvidar. Tenerlo presente es la clave para que tu modo de vida te aporte algo más que una remuneración económica, algo muy importante (ya lo sabemos), pero es que como decía, estamos en esto porque queremos ¿no?

Por otro lado, el riesgo de tener esa visión de tu trabajo es que siempre faltará algo, como tu principal crítico conoces mejor que nadie las imperfecciones y las cosas a mejorar. Es ahí donde es necesario enfrentarse a los conflictos de la gestión del tiempo y evitar estar en un “work in progress” continuo en cada tarea, un pecado en el que difícilmente caerá un mal desarrollador.

Creo que todo esto se aplica a muchos ámbitos, no solo desarrollo y no solo trabajo.

“Hay que intentar ir a comerse el mundo, no ser uno más del rebaño. Puedes conseguirlo o no, pero hay que ir a por ello con determinación, y yo no pienso parar de crecer.”

Sergio Ruiz: Artista del código, guitarrista, aprendiz de japonés y mago. Demostró a los japoneses su manejo de JavaScript desarrollando 2 juegos en un semana. Le encanta investigar sobre nuevas tecnologías, teclear al ritmo de Led Zeppelin y maquinar estrategias heróicas jugando en su PC.

El autor no tiene duda en afirmar que “Good developer is an artist, a craftsman who enjoys the process of creation. Bad developer considers himself as a programmer, responsible for generating lines of code” y Sergio con plena seguridad opina que:

Crear. Nuestra profesión es completamente creativa. Uno no tira líneas por tirarlas, tiene un fin en mente, unos usuarios, quiere que alguien utilice lo que él o ella han desarrollado, y quiere hacerlo perfecto. No hay mayor satisfacción en nuestro trabajo que ver a otra persona utilizar el producto en el que has colaborado y saber que has realizado un buen trabajo.

En el tiempo que llevo en el mundo de la consultoría rara vez he podido desarrollar como yo he querido: con tiempo, con calma y con buena letra. Suele haber alguien (la mayoría de las veces no técnico) que se reúne con el cliente para escuchar sus exigencias, y le ofrece desarrollos en tiempo récord para que dicho cliente no se vaya a otra consultora que tarde o cobre menos. Me parece muy bien porque la empresa consigue a dicho cliente, pero rara vez se tiene en cuenta al que va a tener que desarrollar eso.

Puedes ser muy bueno en tu área, pero a veces necesitas ser un superhéroe para hacerlo todo bien en el tiempo que te dan. O eso, o acudes a las famosas “ñapas”. El desarrollo que te plantean, tú lo estimas en tres semanas y ellos lo han estimado (y cerrado con el cliente, que es lo peor) en una semana, por lo que te están obligando a realizar todas las tareas de análisis, diseño, desarrollo y testeo, en menos tiempo del que requiere, lo que conlleva a que alguno de esos puntos, si no todos, se vean afectados.

Al final terminas el trabajo a tiempo, por supuesto, porque eres bueno en lo tuyo y puedes con ello, pero puedes llegar a avergonzarte de cómo has tenido que resolverlo, teniendo en mente que con tiempo lo habrías refactorizado, testeado, documentado, y realizado tu pequeña obra de arte.

El usuario tal vez no se dé cuenta “de lo que hay debajo”, pero tú sí lo sabes, y otra persona que sea curiosa también lo sabrá, y puede llegar a pensar “pues vaya código”. Y bajo ese código, tal vez haya un artista frustrado que no ha podido realizar su obra a gusto, y al que han obligado a ser mediocre.

Así que … nota para esas personas que se reúnen con los clientes: Siempre escuchad a vuestros programadores, porque son quienes saben cuánto se va a tardar y cómo se ha de hacer una tarea, y si son buenos, podrán demostrarlo.

Y nota para los programadores: No dejéis de luchar por estas cosas, no hay que quedarse callado, si queréis realizar un buen trabajo dejádselo claro a quien haga falta. Sois artistas, unos magos del código, no unos resolutores de problemas.

Gracias a los dos por colaborar, me ha encantado el magnetismo de vuestras reflexiones. Después de leeros me quedo con dos titulares:

“Efectivamente eres “CEO of the feature” porque eres el responsable de tu trabajo”

“Los programadores son artistas, magos del código, no unos resolutores de problemas”

¡Ohhhhhhhhhhhhhhh yeahhhhhhhh!

Artículo relacionado con la serie de opiniones de los Soul Develpers, Gentelmen Developers y Natural Developers sobre los 9 puntos : “Good Developer, Bad Developer“

Posted on febrero 25, 2013 by Emma in Blog 7 Comments

¿Eres buen o mal desarrollador? Natural Developers

Podrían ser los Asturian Developers pero no quiero que ni los Soul Developers ni el gentelman Félix se sientan desterrados

Naturalistas del código, explican la realidad con objetividad, desde lo más filosófico a lo más simple. Sencillos sin ser simples, complejos sin llegar a ser complicados. Naturalidad sin dobleces, la esencia de los Natural Developers.

Érase una vez… una chica, un columpio y 40 minutos de espera para coger un bus.

Sheila Fernández: Avilesina residente en Madrid. Fan de la sidra y la fabada como buena Asturiana que es. Adicta a las series de TV y viajante incansable. Siempre descubriendo nuevas aficiones, su nuevo descubrimiento: un puzzle de 3000 piezas. Como en la vida, las piezas irán encajando.

Con respecto a la afirmación: “Good developer will never feel his code is good enough, and will always continue to clean and fix. Good developer always strives to create elegant solutions but understands that his job is to deliver value to customers. Bad developer thinks only about the elegance of his code and leave the job of delivering value to others” Sheila considera que depende de las circunstancias y de la persona. Entrando más en detalle nos comenta:

A casi todos nos gusta desarrollar buen código, pero por lo general siempre estás atado a una fecha de entrega que no suele ser muy acorde a lo que uno mismo considera necesario para terminar el trabajo. En muchas ocasiones, por ir corto de tiempo tienes que tirar por la solución menos elegante pero sí más rápida. Y es una pena, porque el buen código es mucho más legible y mantenible.

Por desgracia, las personas encargadas de hablar con el cliente y definir una fecha de entrega, no suelen hablar con los analistas y programadores, para ver hasta dónde podemos llegar. El resultado es que vuelven de una reunión y te dicen que dentro de un mes tienes que entregar el trabajo de tres meses, y su solución para llegar es siempre añadir más recursos, lo cuál casi siempre es contraproducente. No entienden que explicar el proyecto, cómo está montado y las tecnologías que se usan a un cierto número de personas, además de la curva de aprendizaje de esas personas para estar trabajando a pleno rendimiento, es un tiempo mucho mayor que si lo desarrollaran las personas que componen el equipo, los cuáles ya están siendo 100% productivos. Por lo que finalmente, acabas perdiendo más tiempo, y muy pocas veces se consigue llegar a la fecha estipulada.

Para que esto cambie, creo que debería existir más diálogo entre ambas partes, y un cambio de mentalidad por parte de jefes/directores de proyecto.

“Freedom For The Spin Country”

Daniel González: Natural de El Espín viviendo en Madrid. Exprimiendo la manzana de Apple para hacer sidra. Cocinillas, sus bizcochos son conocidos en toda España.

Citamos textualmente del artículo “Good Developer, Bad Developer“:

“Good developer understands the complete architecture of the product. Bad developer knows only the components he’s written. Good developer fully understands the technologies that are used within the product. He understands what they are used for, and how they work internally” Daniel da su opinión sobre este punto:

Cuando escoges la profesión de desarrollador (si es que se puede llamar así), aceptas que tu vida va a ser un constante cambio y que siempre vivirás en reciclaje. Todo el mundo te dice que tu crecimiento y aprendizaje debe ser constante, que te plantees como un reto el aprender de aquellas tecnologías que en cada momento sean punteras, estén de moda y puedan ayudar a que tu trabajo sea más agradable.

Ahora abramos la coctelera y mezclemos lo siguiente:

Trabaja con tecnologías en constante evolución. Ahora son las tablets, antes fueron los teléfonos móviles, antes los ordenadores portátiles, antes los PCs…. Todo viene del ábaco, antes solamente había madera y hierro, ahora tenemos chips superpotentes y software al que le falta poco para evolucionar a una inteligencia artificial completa.
Trabaja con diferentes tipos de lenguajes y culturas de desarrollo. En la carrera aprendes muchos lenguajes (C, Java, HTML, Javascript, XML…) cada uno orientado a una rama de la profesión, parecidos pero diferentes, combinables. Cuando te plantas en el mundo real te hacen falta todos y ninguno al mismo tiempo. Java se divide en miles de frameworks. .NET en diversas versiones. Aparecen lenguajes nuevos.
Trabajas para un sector. Si comienzas en el sector de la banca aprendes de éste, si es en el de los seguros, seguros, si es sanidad, sanidad, transportes, turismo, deportes, medios de comunicación… todos con partes iguales, pero diferentes.
Trabajas para una empresa. Eso implica aceptar la política de organización, horarios (horas extra que sacas de tu tiempo personal), filosofía, definición técnica de los responsables, arquitecturas propias, frameworks, etc.
Trabajas en una ciudad. Muchos de nosotros venimos de núcleos pequeños y nos encontramos en ciudades grandes, lugares donde el tiempo es oro. Transportes eternos, tráfico, huelgas, alto coste de la vida.

Cuando agitas toda esta mezcla, obtienes una persona con control sobre muchas cosas de gran diversidad, enfocado a una cosa en concreto: sus tareas en su trabajo y que dispone del tiempo justo para su propio disfrute. Depende después de cada persona y que hacer con el (poco) tiempo libre que le quede, si decide romper con la rutina, o si por el contrario es un apasionado de su profesión. En este segundo caso, además se puede dividir en si está cansado de tratar con lo mismo siempre (aquello que ve en su rutina diaria) y quiere ver cosas nuevas, o si por el contrario le encanta tanto su trabajo que es capaz de seguir trabajando y aplicando sus nuevos conocimientos.

En definitiva, personalmente creo que no es mejor programador aquel que lee más libros, lee más artículos, sabe más de la tecnología de la que es experto, escribe libros, da conferencias, cursos… esto lo puede hacer cualquiera. Sin embargo, aquellos que demuestran su compromiso, pasión, entrega, dedicación, esfuerzo en su trabajo y además son capaces de contagiar a los que les rodean con ello, haciendo que todos seamos mejores desarrolladores, ellos si son buenos desarrolladores, y buenos profesionales.

Me quedo con dos titulares:

“Debería existir más diálogo entre ambas partes, y un cambio de mentalidad por parte de jefes/directores de proyecto”

“Aquellos que demuestran su compromiso, pasión, entrega, dedicación, esfuerzo en su trabajo y además son capaces de contagiar a los que les rodean con ello, haciendo que todos seamos mejores desarrolladores, ellos si son buenos desarrolladores, y buenos profesionales“ Si queréis curiosear más sobre Daniel, su vida, su gente, sus sitios, haced una parada por su blog: Freedom For The Spin Country.

Sheila, Dani, mil gracias por colaborar, ¡me presta mucho!

Posted on febrero 19, 2013 by Emma in Blog 3 Comments

¿Eres buen o mal desarrollador de software? Gentlemen Developers

Después de las opiniones realizadas por los Soul Developers con respecto a dos de los puntos del artículo “Good Devoloper, Bad Developer”, continuamos con las reflexiones de los caballeros de las buenas prácticas, inspiradores de sabiduría y literatos del código: Gentlemen Developers

“La motivación y la pasión son las armas mas potentes con las que contamos las personas”

Israel Alcázar: Informático de vocación. Dedica parte de su tiempo ayudando a equipos de desarrollo realizando labores de Formación, Coaching Técnico y Mentoring. Le apasiona compartir conocimiento y el trabajo con personas.

La mejora continua es una de sus obsesiones por ello se encuentra en búsqueda de nuevas formas de trabajar. Apasionado de la web y la tecnología móvil también dedica parte de su tiempo a coordinar el grupo de JavaScript en Madrid (http://madridjs.org) (@MadridJS) y es uno de los organizadores de SpainJS, una conferencia internacional sobre JavaScript. Cuando le queda tiempo escribe en su blog http://farmerdev.com.

“Good developer understands the problems of the customers. Bad developer understands only the technical problem at hand. Good developer does not define the why, but constantly strives to understand why. He’s responsible for the how, and still sees the big picture. Bad developer is focused on building classes and methods and configuration files, but does not get the big picture”

Israel comenta: Puede ser un fallo bastante habitual que los desarrolladores nos olvidemos muchas veces del por qué del software que desarrollamos. Nos olvidamos que ese software que construimos tiene que servir a alguien para mejorar su forma de trabajar y hacerle mas productivo.

Hay que reconocer que a veces sólo nos centramos en cultivar nuestra parte mas técnica. Asistimos a eventos, charlas y conferencias técnicas pero, se nos olvida que también, sería bueno cultivar otro tipo de cualidades. Cualidades como empatía, paciencia, visión de producto. Todas ellas igual o mas importantes que las actitudes técnicas.

Un buen desarrollador, debería pensar antes de “tirar” una sola línea de código en los usuarios que utilizarán la aplicación, en qué problemas tienen y cómo queremos ayudarles. Por eso, antes de ponerte a programar piensa en tu usuario.

Dicen que entre el 50-70% de los defectos que se encuentran en el software provienen de un mal entendimiento de los requisitos. Un buen desarrollador, intentará minimizar el número de defectos. Esforcémonos por entender bien esos requisitos a través de las personas.

También perderemos foco si olvidamos el propósito general de la aplicación. Esa foto general de lo que se supone debe hacer la aplicación deberíamos tenerla siempre presente. Actúa en local (en tu código) pero piensa en general (en toda tu aplicación).

Existen algunas técnicas ágiles como las Incepciones al inicio de un proyecto que sirven para conseguir ambos objetivos: entender mejor a nuestros usuarios, no perder de vista el objetivo principal de la aplicación.

“Siempre mirando al futuro”

Félix Manuel Menéndez: Analista, ideólogo, crítico de ideas, desarrollador clave y superviviente de cualquier proyecto tecnológico. Multidisciplinar más que especializado. Cuando desarrolla o cuando escribe, nota como se activan partes similares de su pensamiento. Caballero inspirador y de gran sentido ético. La literatura ha sido siempre su compañera de viaje. Si no hubiera sido desarrollador, hubiera sido escritor. Su mayor obra: su hija.

“Good developer is not afraid to go into anyone’s code. Bad developer is afraid of others looking into his. Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify”

Una vez establecidas las premisas Félix comenta:

Good developer is not afraid to go into anyone’s code. Puede servir como indicador de la profesionalidad o el compromiso de un trabajador ante un problema que desearía no afrontar, como si se tratase de un cirujano con una operación complicada por delante. Nuestro trabajo no siempre es divertido, y no tiene por qué salir bien.

¿Dónde nace este código presuntamente terrorífico? La respuesta que a todos nos gusta escupir es la falta de profesionalidad de los demás. Pero es apresurada y dañina.

Teniendo en cuenta que el mantenimiento se prolonga en el tiempo más que la construcción, todos queremos escribir un código genial que nos permita afrontar esa fase con garantía de éxito. Por los motivos expuestos, en ocasiones entregamos código mejorable (eufemismo). Si siempre se toma la decisión de quitar prioridad a la parte técnica – un cliente que el primer día te dice que no quiere pruebas unitarias va por este camino – terminamos con bases de código de pesadilla.

Bad developer is afraid of others looking into his. Mi experiencia me dice que justo el opuesto es cierto.

Por el efecto del Impostor (hermano del Dunning-Kruger), quién más miedo tiene de qué miren su código suele ser el buen desarrollador, que entiende que el desarrollo de software es una búsqueda de equilibrios, capaz de distanciarse del concepto de perfección, y sabe los atajos que ha tenido que tomar para que la pieza que acaba de escribir encaje en el contexto del proyecto.

Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify.

Salvo para pequeños trozos de código aislado, escribir código limpio y documentado lleva más tiempo. En un proyecto real, cada cambio es complejo y es difícil dar la mejor solución a la primera.

Los detalles no emergen hasta el momento en el que las letras empiezan a aparecer en la pantalla (ver la cita de Clean Code). Puedes diseñar, escribir, las líneas en tu cabeza y restar ese tiempo del que estas tocando el teclado, pero eso es una trampa. Cada elemento que convierte en bueno un fragmento de código (por ejemplo, las pruebas unitarias, que son, además, documentación) hay que escribirlo, lleva tiempo, no aparece de la nada. Y, a veces, hacer buen código significa simplificar (recomiendo leer “The Most Beautiful Code I Never Wrote” de Jon Bentley).

Israel, Félix es una maravilla poder aprender tanto de vosotros ¡gracias! Me quedo con dos titulares:

“Cualidades como empatía, paciencia, visión de producto. Todas ellas igual o mas importantes que las actitudes técnicas”

“Por el efecto del Impostor (hermano del Dunning-Kruger), quién más miedo tiene de qué miren su código suele ser el buen desarrollador”

Hasta la semana que viene

Posted on febrero 5, 2013 by Emma in Blog 1 Comment

¿Eres buen o mal desarrollador de software? Soul Developers

Leyendo el artículo “Good Developer, Bad Developer” que recomendó a través de Twitter mi compañero Eduardo Antón me paré a reflexionar en cada uno de los puntos que expone el autor. Si preguntamos a cualquier desarrollador que es para él ser bueno en su trabajo, no habrá duda que contestarán lo mismo que Guy Nirpaz, el conflicto se produce cuando esa teoría choca con la realidad profesional de muchos de los programadores.

Con la finalidad de acercarnos más al día de los programadores, 9 desarrolladores de distintas tecnologías nos darán su visión sobre lo que para ellos es ser buen o mal programador.

Comenzamos con los desarrolladores que ponen el alma en su trabajo, programan por el mero placer de desarrollar, aprenden nuevas tecnologías por la satisfacción que les genera el hecho de aprender, la esencia de los Soul Developers.

“Antes que nada, somos personas”

Ricardo García Vega: Siempre en constante búsqueda del equilibrio entre el desarrollo y el diseño, para crear una buena experiencia para el usuario. Cuando no está desarrollando nuevas aplicaciones web, se le puede ver montado en cualquiera de sus tablas, ya sea por mar, por nieve o asfalto… Love & Boards, yeah!

Daniel Sánchez Gómez: Su afición por la tecnología viene desde muy pequeño. Con 6 años implementó su primera aplicación “Hola Mundo!” con un Spectrum ZX de 64K. Es un apasionado de todos los gadgets o frikadas (como su novia prefiere llamarlas). Le encanta disfrutar de la naturaleza, realizando rutas de montaña o intentando coger unas olas en la playa.

“Good developer understands the complete architecture of the product. Bad developer knows only the components he’s written. Good developer fully understands the technologies that are used within the product. He understands what they are used for, and how they work internally”

Daniel nos cuenta su opinión sobre este punto:

En plena Edad Media un peregrino vio en París a tres obreros trabajando con grandes bloques de piedra.
— ¿Qué están haciendo?, les preguntó.
— Cortando piedra, dijo uno de ellos con indiferencia.
— Ganándome unos francos, repuso secamente el segundo.
El tercero suspendió su labor por un momento y con una gran sonrisa y marcado entusiasmo respondió:
— Estoy construyendo una hermosa y espectacular catedral que va a ser la más importante de toda la región.

Al igual que con los trabajadores de la catedral, para ser un buen programador deberemos conocer de manera global el producto para el cual estamos trabajando. De esta manera a parte de fortalecer nuestros conocimientos, trabajaremos con mayor motivación y entusiasmo al saber lo importante que es nuestro aporte en el proyecto. También tendremos más energía, inspiración y fuerza para realizar de la mejor manera posible nuestras tareas.

Pensando a la inversa, igual de importante es conocer cada una de las tecnologías que se usan en el desarrollo de un proyecto. No sólo por motivación, sino también por la seguridad y confianza que vamos a tener al saber que estamos aprovechando al máximo, y utilizando de manera adecuada todas las herramientas, librerías o lenguajes de programación que intervienen en el proyecto.

En muchas ocasiones no nos dejan tiempo para estudiar a fondo las tecnologías que se utilizan en los proyectos. Esto es debido a que no se invierte tiempo en aprender y formar a la gente en una empresa pensando que se ahorran costes. Pero al final en vez de ahorrar, lo que se consigue es todo lo contrario. ¿Quién no ha escuchado la frase: “lo barato termina saliendo caro”? Pues en el desarrollo de software pasa lo mismo. Si no se forma o se dedica el tiempo suficiente en conocer las herramientas y tecnologías con las que se trabaja, al final pueden surgir errores o problemas, en los cuales se gaste mucho más tiempo en resolverlos que el necesario para estudiarlos a fondo desde un principio.

“Good developer is not afraid of new technologies but embraces them by quickly getting a grip. Bad developer only sticks to what he knows. His immediate reaction to any technical change is negative”

Ricardo nos cuenta su realidad sobre esta afirmación:

Muchas veces el poder usar nuevas tecnologías en nuestro trabajo no depende de nosotros. Muchos de nosotros trabajamos en empresas donde las personas que toman las decisiones sobre qué tecnologías usar en qué proyecto a duras penas tienen el conocimiento técnico de qué tecnologías existen y lo beneficiosas que pueden llegar a ser para el desarrollo del mismo.

Suelen ser personas que la última vez que han programado, si es que lo hecho alguna vez, fue hace décadas, y siguen agarrándose a esas tecnologías obsoletas porque es lo único que conocen y donde se sienten cómodos. Pero aquí no acaba la cosa, ya que muchas veces tampoco cuentan con la opinión ni el consejo de las personas que tienen esos conocimientos, que son los que al final van a desarrollar ese proyecto y sus conocimientos pueden ser muy útiles a la hora de elegir las herramientas para hacerlo. Y no hablemos de la formación interna para que sus empleados sean mejores desarrolladores, ya que muchas veces o es inexistente o se trata de cursos obsoletos y sin sentido. Esto conlleva también a que mucha gente dentro de esas empresas sigan desarrollando usando las tecnologías de siempre, sintiéndose cómodos, porque es lo que usan a diario y no necesitan saber más para realizar su trabajo.

A mi personalmente me apasiona aprender cosas nuevas. Me encanta pegarme con ellas, entenderlas, llegar a saber utilizarlas y seguir mejorando. Siempre que puedo intento usar todo lo nuevo que aprendo en mis proyectos personales. Estamos en una era en la que no hay excusa para no aprender nuevas tecnologías, ya que Internet está lleno de manuales, tutoriales, blogs, código libre, auténticos cracks que comparten sus conocimientos, y un sin fin de información al alcance de todos. Si las empresas para las que trabajamos no van a hacer nada para que seamos mejores desarrolladores, depende de nosotros el serlo o no, así que no sé vosotros, pero yo voy a seguir luchando cada día por mejorar. Love & Boards!

Si quieres saber más sobre ellos no dudes en pasarte por TonkaLabs. Por cierto … me quedo con dos titulares:

“Lo barato termina saliendo caro, dediquemos tiempo suficiente a conocer las herramientas y tecnologías con las que vamos a trabajar”

“Si las empresas para las que trabajamos no van a hacer nada para que seamos mejores desarrolladores, depende de nosotros el serlo o no”

Esto no es todo amigos … ¡hasta la próxima!

Posted on enero 28, 2013 by Emma in Blog 11 Comments

¿Bug? ¡Quita bicho!

Cualquier persona que se dedique a la programación o se haya aproximado al mundo del software sabe lo que es un “bug”. Los fallos que aparecen a lo largo del proceso de cualquiera de las etapas del ciclo del software, frecuentemente en la fase de desarrollo y programación son los denominados coloquialmente “bugs” (que en inglés significa “bichos”). Cuenta la leyenda que este curioso nombre se debe a que una polilla (si, si un bicho de esos de la ropa ) se metió en el ordenador y provocó un fallo en el relé electromagnético.

Foto del origen de la leyenda acerca del primer “bug” informático conocido.

Grace Murray Hopper, licenciada en Física y destacada matemática que trabajó como programadora en el Mark II, pegó el insecto con cinta adhesiva en la bitácora y se refirió a ella como “bicho” para describir la causa del problema.

Sea verdad o no esta leyenda, el origen del término es tan antiguo como la programación en sí misma.

Durante las etapas de desarrollo de software, son muchas las personas que se encuentran programando en diferentes partes del sistema, y no suelen ir trabajando al mismo ritmo, por lo que sus desarrollos no finalizan de manera simultánea y provocan errores que los informáticos han clasificado según su “comportamiento“.

Con la intención de poner un poco de humor al trabajo de los programadores, clasificaremos los “bugs” según las experiencias vividas por muchos de vosotros. ¡Al lío!

Bug “porque yo lo valgo”

Es ese bug que no tiene porque llegar a serlo pero tiene madera para ello. Es un error provocado por un desarrollador que hace un commit a última hora, sin ejecutar los test unitarios y se va a su casa tan pancho, orgulloso de su trabajo. Si tienes suerte, el servidor de integración continua te avisa y te advierte del problema, si no, ya te enterarás en algún bonito momento.

Bug “bomba ninja”

Error que aparece “incomprensiblemente” en cualquier momento sobre código que ha funcionado correctamente durante mucho tiempo. El problema se suele encontrar en el código comentado para algún tipo de prueba y que se ha subido al repositorio. Nos podemos encontrar con 2 posibilidades que:

Al desarrollador que le toque ver el código, sea el mismo que lo ha comentado y oigas de repente: “¡mierda!, la cagué”.
El desarrollador sea cualquier otra víctima que no ha tocado nada de ese código y se encuentre una sorpresita maravillosa. Si además el originario del “pufo” se ha ido tranquilamente de vacaciones o ha abandonado el proyecto, te ha dejado un romántico regalo de despedida.

Bug “hazlotú”

Esos desarrolladores “cracks” que les apasiona meter todas las tecnologías del mundo y dicen frases cargadas de emoción como: ”Ruby a tope, ¡qué pasada!”. Como sabes la que te espera si intentas meter mano en su código, prefieres hablar directamente con el emocionado en cuestión y decirle: “te has venido arriba, así que mejor hazlo tú”, aunque todos sabemos que no siempre se puede optar por esa medida, es entonces cuando el ego se apodera de ti, te armas de valentía y te pones a tocar aquí y allí, y que “dios nos pille confesados”.

Bug “paranormal”

El más allá existe. No funciona nada y nadie ha tocado nada. Miradas de desconfianza, misterio e indignación para demostrar que ni tú, ni tu equipo sois los culpables.

El resultado puede ser variado:

Nivel “Rocky IV”: Encontramos el problema ajeno y no regocijamos con orgullo y satisfacción “ya había dicho que no habíamos tocado nada y el error no era nuestro” (uahahahaha)
Nivel “Oda Mae Brown”: Ese bug al más estilo pitonisa de la película de Ghost. El elemento externo está haciendo algo que se suponía que no hacía y rompe lo nuestro, pero no pasa nada, tenemos la clara excusa de decir que no estaba en nuestras manos prevenir esto.
Nivel “Mister Bean”: Encontramos un error con lo que no contábamos y que ha llegado para traernos diversión a nuestro monótono día.

Bug "Forrest Gump”

Fallo todavía no reportado así que de momento no existe ¬¬. Todos saben que es un “marrón” de los grandes y que tarde o temprano saldrá a la luz, pero ni es el momento ni se dispone de tiempo para pensar en eso. Se opta por ignorar el problema, posponer su solución y vivir con la ilusión de que cuando caiga, nos pille bien lejosss ¡corre Forrest!.

Bug “Ecce Homo”

Hoy en un gran día, te sientes motivado, ves un trozo de código que no es tuyo y dices: “¡que cosa más fea”, y en un arranque de inspiración divina lo rehaces a tu gusto. El problema surge porque en ese impulso de ”me creo artista y punto” has olvidado que no conoces el código (#fail) y cuando el bug salta no te quedan más opciones que:

Callarte e intentar deshacer tu obra de arte (¡ainssss!)
Le toca a otro arreglarlo y tienes que darle explicaciones por aquel día tan inspirado, asumiendo tu culpa y escuchando la gran frase de tu compañero: “¡no toques!, ¿por qué tocas?”.

Bug “Gandalf”

Ese bug que piensas que se ha solucionado pero ¡noooo! se ha ido a los p**** infiernos y volverá convertido en mago blanco, más fuerte que nunca. (ohhh myyyy)

Bug “expediente X”

Maldito día, todo falla, imposible encontrar el error. Te vas a casa asqueado y al día siguiente está todo solucionado. No sabes cómo ni por qué, tampoco te importa, sólo sabes que “la verdad está ahí fuera…”

Ya sea en nuestro trabajo o en cualquier aspecto de nuestra vida, no hay mejor forma de aprender de nuestros errores que con humor. ¿Y tú? ¿Añades código correctivo o eliminas el código erróneo? (sin ofender ¿eh?)

Gracias a Ángel Cereijo por enseñarme lo complicado que es ser un buen desarrollador de software cuando las circunstancias no son las más idóneas, y por cada una de las risas compartidas escribiendo este post.

Posted on noviembre 19, 2012 by Emma in Blog 5 Comments

Héroes de nuestra vida

Siempre me he preguntado por qué nos fascinan tanto los superhéroes, y he llegado a la conclusión que el éxito radica en el poder adaptar una doble personalidad. Dejar de ser un ciudadano de a pie, “normalito” para pasar a adoptar una personalidad sobrehumana y superpoderosa es el deseo de cualquiera, y más si nuestro origen del poder se deben a traumas, carencias afectivas, o vidas tan tristes y aburridas que se superan cuando nos ponemos el disfraz.

Aunque los superhéroes parezcan irreales, lo único que nos distinguen de muchos de ellos son determinadas capacidades especiales como: lanzar rayos energéticos, volar, trepar por las paredes, tener una fuerza desmesurada, hacernos invisibles o ser invulnerables (menos mal, porque para rollos ya tenemos la vida real). Pero lo más curioso, es que la base sociológica y psicológica de nuestros héroes de toda la vida tienen algo en común con nosotros: el sentido de justicia, su personalidad arrasadora y la fortaleza mental para superar cualquier tipo de obstáculos.

Pilar Jericó, en su libro “Héroes cotidianos”, explica a través de casos reales como personas normales y corrientes son asaltadas duramente por circunstancias de la vida y se enfrentan a ella con habilidades y capacidades especiales aparentemente insuperables como ser humano. En determinados momentos de nuestras vidas adoptamos esa doble personalidad esterotipada de los superhéroes y no somos conscientes del poder que tenemos hasta que nos toca ponernos el “disfraz” y sacar el “héroe que todo llevamos dentro”.

Haciendo un repaso por los superhéroes más famosos y apasionantes de la historia de los cómics (volviéndome loca con cada uno de ellos, dicho sea de paso), finalmente he optado por hablar de seis increíbles heroínas (lo siento, chicos, me ha salido del alma). Impresionantes mujeres, complejas en su personaje, y ejemplos de la caricaturización de las debilidades y fortalezas del ser humano.

WONDER WOMAN

Imagen obtenida de la página fanpop.com

Historia: No es el equivalente femenino de ningún superhéroe. Diana, princesa de Themiscyra, vive con las amazonas en una isla remota donde no hay hombres. Sin embargo, por ser la mejor de su estirpe, se gana el derecho de devolver al mundo exterior a un piloto que cayó en la isla. Su misión va más allá, acaba luchando contra los nazis, tal como lo hicieron muchos superhéroes creados entre los años treinta y principios de los cuarenta.

El personaje de Diana está muy relacionado con la diosa griega Artemisa (Diana, para los romanos), diosa de la caza y protectora de la naturaleza. Usando un uniforme decorado con símbolos que representan a una legendaria heroína amazona, Diana llevó su coraje y habilidades al máximo como Mujer Maravilla. Guiada por una indomable voluntad y un corazón compasivo, lucha por proteger a los inocentes de las fuerzas tiranas.

Poderes y armas: Posee fuerza, velocidad, inmortalidad (como diosa que es), la habilidad de volar, brazaletes que desvían balas, un lazo mágico que obliga a cualquier persona sujeta a él a decir la verdad, y una tiara boomerang que puede cortar el diamante.

Personalidad: Inteligente, polifacética, compasiva y con la enorme capacidad de adaptarse a cualquier tipo de situación. Luchadora incansable en búsqueda de la paz. Consigue sus objetivos a través de la persuasión.

Diría que es mi preferida pero …

CATWOMAN (GATÚBELA)

Historia: En el seno de una familia humilde nació Selina Kyle, tuvo una infancia traumática y se quedó huérfana a una temprana edad. Estas duras circunstancias, propiciaron a Selina a realizar la prostitución para sobrevivir, pero oprimida por un criminal proxeneta, se plantea dejar todo ese maldito mundo. Comienza a dar clases de artes marciales, a cargo del Maestro sin brazos, y de boxeo y lucha callejera por Wildcat. El Maestro al ver su potencial, la convence para dejar la prostitución y la motiva a buscar un propósito más elevado en su vida. Un día, por ciertas circunstancias, el proxeneta ataca a la hermana de Selina y ésta lo mata para defender a su hermana. A partir de ese momento comienza a ejercer el robo y se convierte en una excelente ladrona de “guante blanco”, robando a los millonarios y apoyando a los más desfavorecidos, al más estilo Robin Hood.

Imagen obtenida de la página es.ioffer.com

Cierto día, tras un breve enfrentamiento con Batman, Selina piensa -”Si hay un murciélago, porque no hay un gato”- y entonces nació Catwoman.

Se mezclaba con los peores criminales, pero también actuaba como una heroína cuando era necesario, especialmente ayudando a Batman, con el cual siempre tuvo un peculiar romance, hasta el punto que Batman le confiesa su identidad secreta e incluso le lleva a la Batcueva … pero la relación nunca progresa por diferencias entre ambos.

Poderes y armas: Experta en artes marciales, gran atleta, elegante ladrona, ágil como un gato, utiliza un látigo y sus afiladas uñas.

Personalidad: Moral ambigua, no se sabe si es buena o mala, y siempre debatiéndose entre su deseo de venganza y su sentido de la justicia. Su pasado está cargado de traumas y de desconfianzas, por lo que adquiere un carácter inestable y caprichoso. Su personalidad felina le hace ser seductora, tímida, provocadora, inteligente, independiente, solitaria, tenaz y ambivalente de emociones. Antepone su libertad al amor hacia un hombre.

BATGIRL (BARBARA GORDON - BATICHICA - ORACÚLO)

Imagen obtenida de la página free-ecomics.blogspot.com.es

Historia: Barbara Gordon, hija del comisario de policia Jim Gordon, era una estudiante brillante y una experta luchadora. Cuando se enteró de que uno de los villanos de Batman, la Polilla Asesina, se disponía a capturar al millonario Bruce Wayne, emuló a su ídolo, Batman, y creó un disfraz de Batman femenina, y rescató a Wayne (sin sospechar que él era en realidad Batman). De ahí en adelante, se haría llamar Batgirl y se convertirá en la ayudante regular de Batman y de Robin. Años después de retirarse como Batgirl, Bárbara fue atacada por el villano Joker, que la disparó en la cintura, dejándola paralítica de por vida. A partir de ese momento, se pasó a llamar simplemente Oráculo y ejerció de ayuda intelectual e informática de Batman.

Poderes y armas: No tiene poderes especiales, sin embargo es una excelente combatiente cuerpo a cuerpo, atleta, literata, dotada de una gran inteligencia, con excelente memoria fotográfica, experta en el uso de ordenadores y hacker de gran nivel, capaz de infiltrarse en los sistemas de seguridad más inaccesibles.

Personalidad: Más buenas intenciones que capacidades especiales. Un duro accidente en su vida, le hace cambiar su carácter, pasando de ser un personaje divertido y desenfado en sus acciones, a adquirir un alto grado de seriedad e intelectualidad (al más estilo Batman). Luchadora, inteligente, altruista y no vengativa. Ejemplo de control mental, superación y madurez.

SUPERGIRL (KARA ZOR-EL)

Imagen obtenida de la página maidofmight.net

Historia: Por ser prima de Superman, tiene tantos poderes como el superhéroe. Es uno de los personajes más criticados y más infravalorados de los comics, cuando (a mi parecer) es una de las heroínas más complejas e interesantes.

Ha sufrido varias evoluciones y cambios de nombre (Kara, Matrix, Linda…) tanto que es casi imposible resumir en breves líneas su historia (para los más curiosos, al final del post os pongo webs interesantes para indagar).

Poderes y armas: Fuerza sobrehumana, vuelo, visión calorífica y de rayo X, potenciada capacidad de oír, súper aliento congelante y súper velocidad.

Personalidad: Soñadora, ingenua, inmadura, tierna, dispuesta a aprender y con una motivación muy clara, ser cada día mejor heroína.

EMMA FROST

Imagen obtenida de la página comics.emmafrostfiles.com

Historia: Emma Frost nació en Boston (Massachussets) en el seno de la rica familia. Su padre era muy autoritario y estricto con sus hijos, mientras que su madre se refugiaba en las drogas por su fallido matrimonio.

Con el paso de los años descubrió su poder mutante y lo usó en beneficio propio para tener una vida mejor. De ahí pasó al “Club Fuego Infernal”, en el cual llegó a ser su “Reina Blanca” (liderazgo en los negocios y entre los mutantes de la organización), y años más tarde en X-men, enseñaba a las nuevas generaciones de mutantes y dejaba atrás su pasado como mala-malísima.

Poderes y armas: Se encuentra entre las telépatas más poderosas, puede leer mentes, manipular recuerdos, controlar a la gente, inducir parálisis, proyectar “rayos mentales”, crear ilusiones, y hacer uso de la “proyección astral” (abandonar su cuerpo temporalmente). También puede cambiar a un exoesqueleto de diamante a voluntad, con cierto grado de invulnerabilidad y fuerza sobrehumana.

Personalidad: Antes de convertirse en la cruel “Reina Blanca”, era una adolescente inocente con una estupenda capacidad para detectar las mentiras de los demás. Su situación familiar era tan complicada que no tuvo más remedio que huir de su casa y poco a poco fue adquiriendo una personalidad aparentemente insensible y fría. A veces mala, a veces buena, carismática, calculadora, exuberante, y a ojos de los demás muy fría pero con lapsus de sensibilidad que muestran su parte más humana.

ROGUE (PÍCARA- TITANIA)

Imagen obtenida de la página masquecomics.blogspot.com.es

Historia: Cuando era joven, Pícara descubrió sus poderes de una dolorosa forma, besando a su novio Cody absorbiendo su energia vital y llevándolo al coma. Horrorizada por lo sucedido, Picara escapó de su casa y empezó a vagabundear. En ese momento fue cuando otra mutante llamada Mística la encontró y la crió como si fuese su hija. Pero una vez creció la integró en su Hermandad de Mutantes Diabólicos, utilizando su poder para sus fechorías. Durante una de estas acciones criminales, Pícara absorbió permanentemente los poderes de Miss Marvel. Desesperada por no poder controlar sus poderes, Pícara huyó nuevamente, pidiendo ayuda al entonces su enemigo Profesor Xavier.

Sus principios fueron difíciles, pero finalmente Pícara encontró su sitio entre los X-Men , y aunque no consiguió controlar sus poderes encontró una “familia”, donde conoció la amistad, la lealtad y el amor.

Durante su andadura, volvió al lado del mal temporalmente, aliándose con Magneto del que se enamoró (pues su poder magnético anulaba el poder de absorción de Pícara). Los poderes de Pícara se desbocaban cuando entraba en contactato con cualquier raza alienígena, pudiendo manifestar la mutación de cualquier mutante que haya tocado a lo largo de su vida. Sin embargo, tras un duro combate contra un enemigo, perdió todos sus poderes que finalmente fueron reactivados finalmente por Sabia.

Poderes y armas: Anna Marie es una mutante nacida con una estructura genética que le concede habilidades especiales que la diferencian de los seres humanos. Con la adolescencia desarrolló la capacidad de absorber recuerdos, habilidades, personalidades y características físicas a través del contacto de su piel con la de la víctima, lo que provoca que ésta quede inconsciente. Un contacto extenso puede provocar absorción permanente (este caso tuvo lugar con Miss Marvel). Anna Marie tiene además poderes de gran fuerza, invulnerabilidad, y la capacidad de volar. También ha retenido su séptimo sentido que le permite adelantarse a las acciones de sus oponentes. Como resultado de la doble psique, Anna Marie es resistente a ataques telepáticos.

Personalidad: Es una de las heroínas que más me gustan. Tiene los poderes más impresionantes que un superhéroe puede poseer, pero su poder de absorción le impide el contacto físico con las personas que quiere. No puede abrazar, acariciar o besar sin hacer daño pero a pesar de ese estigma, su personalidad alegre, descarada y pícara le hace tener un carisma especial.

Y a ti, ¿qué superheroína te ha tocado ser?

¿Polifacética y con una enorme capacidad de adaptación como Wonder Woman?
¿Caprichosa y de moral ambigua como Catwoman?
¿Soñadora e ingenua para afrontar los problemas de la vida como Supergirl?
¿Madura e inteligente emocionalmente como Batgirl?
¿Con una coraza en el corazón para enfrentarte a las complejidades de la vida como Emma Frost?
¿Plantándote a la vida con descaro y con cierta distancia emocional sin dejar a un lado de los sentimientos como Pícara?

Podría poner innumerables enlaces sobre este apasionante mundo de los superhéroes, pero os dejo los mejores que he visto, no sólo en cuanto a contenido, sino visualmente (porque hay cada página por internet, horrible de leer). Si conocéis más, no dudéis en compartirlos

DC Comics, The Dreamers, Superheroes y Villanos, 20 minutos, y Wikia

Fotos de la portada: Comicartcommunity.com y deviantart.com