mitfits

No temas ser un inadaptado, teme no serlo

Misfit, un término anglosajón que significa ‘inadaptado social’. Conocí el término por la serie que lleva dicho termino por nombre Misfits, la cual recomiendo que la veas. Llevo 6 meses ya en mi nueva empresa y en esta semanas pasadas han ocurrido dos cosas importantes que cualquier desarrollador suele vivir: pasar el período de prueba y tu primer Sprint importante.

Del primero no hace falta hablar. Todos los puestos de trabajo requieren que pases un período inicial de llegada y adaptación a la empresa donde se te evalúa como última fase de tu contratación. Lo pasé, bien por mí.

El segundo os será más familiar a los programadores. Es un período de tiempo dedicado a poner a remar a todo el equipo en una dirección concreta para lograr unos objetivos marcados con un propósito específico en un tiempo acotado y predeterminado. He usado una definición tan indeterminada a conciencia para dejar claro lo absurdo que me parece este método.

Cuando nos hablaron de que íbamos a empezar un período de 6 semanas donde íbamos a finalizar 18 proyectos abiertos (que al final fueron 21) para empezar ‘en blanco’ a principios de Junio una nueva fase, pensé dos cosas:

  • ¿Por qué tenemos tantos proyectos?
  • ¿Qué estábamos haciendo hasta ahora sino era finalizar estos proyectos?

La explicación que nos daban eran que necesitábamos hacer un sobreesfuerzo para cumplir este objetivo en la fecha fijada. La pregunta obvia sobre qué iba a venir después tenía una respuesta no tan obvia: no lo sabemos aún.

¿Cómo dirías que fueron estas 6 semanas? Seguramente que por lo descrito pensarás que fue un vaivén de horas extras, estrés, reuniones, cafés… Más o menos… No. De echo se organizaron hasta torneos de ping pong. Hasta que al final se pudo vivir unos momentos, que un profesor que tuve lo describía perfectamente, de llanto y crujir de dientes. Era de esperar.

Viendo este escenario, de prisas sin prisas y con objetivos sin definir, viniendo de una etapa donde el control de todo era mi día a día, se comprende mi pequeña frustración personal.

*    *    *

Cuando llegas a una nueva oficina, traes contigo un equipaje. En este equipaje hay de todo y se resumen en una palabra: Experiencias. Estas experiencias son lo que te definen como profesional y que hace que tu llegada a un nuevo equipo aporte una diferencia a lo que antes de que llegaras había. Si la diferencia fuese inapreciable, harían bien en prescindir de ti. Si la diferencia fuese negativa, harían bien en evaluar por qué y, tomar una decisión después sobre tu continuidad. Y si la diferencia es positiva, han hecho un buen trabajo contratándote. Es decir, sólo marcando una diferencia en el equipo, tienes posibilidades de demostrar que te necesitan, para bien o para mal.


sólo marcando una diferencia en el equipo, tienes posibilidades de demostrar que te necesitan, para bien o para mal.


Actualmente, me encuentro en un punto en el que no sé cual es mi aportación al equipo, positiva o negativa. Mi punto de vista esta claro que es diferente y, para algunos es un buen punto de vista, pero la realidad es que se aplica otro distinto. La clave para saberlo está siempre en hablar con tus compañeros, pero el problema fuera de un ‘ambiente latino’ les cuesta decirte la verdad a la cara, ahí españoles e italianos somos los reyes :).

La importancia de ser sinceros y abiertos a nuevas ideas es crucial cuando llega un nuevo miembro al equipo y, más aún, cuando tú eres ese miembro. Es lógico tener roces con la nueva forma de trabajar, significa que estas marcando una diferencia. Lo importante es saber que esa diferencia debe ir más orientada a un efecto positivo, pero si con ello llevase decir a todo ‘brilliant’, vas a caer en la única posibilidad que tu contratación no fue acertada: indiferencia.

Era sensato no intentar nada por cambiar las cosas durante un sprint, demasiados nervios hay en el ambiente como para añadir más leña. Pero ahora llega otra época de normalidad. Mi objetivo en los próximos 3 meses será demostrar por qué fui un buen candidato para el puesto que ocupo. Estoy totalmente convencido de que me esperan momentos de tensión y momentos donde mi orgullo no vendrá a trabajar conmigo. Pero es necesario. Si quiero autorealizarme no puedo quedarme en un escritorio ejecutando tareas que considero erróneas al son de ‘sounds great!‘. Un ejemplo es el caso de una API interna que tenemos para la que necesitamos crear parser por cada tipo de llamada desde nuestra web (son 2 apps distintas) … yo la llamo API CADUBO ‘cada uno va a su bola’.

Hasta ahora siempre me había preocupado por saber cómo gestionar un equipo, ahora es cómo hacerlo cuando no eres manager sino solo un simple desarrollador, un peón. Me recuerda a God of War, dónde en cada entrega de la saga, al héroe le quitan sus poderes al empezar, pero sin la parte de ser un héroe :). De esto iré contando un poco en los próximos meses y espero que más o menos con algún éxito. Lo que si puedo asegurarte que lo que escriba, será basado en hechos reales.

Deséame suerte.

PD.- No temas ser un misfit, teme no serlo.

Inquietudes, recursos y un salto al vacio

Recursos, inquietudes y un salto al vacío

Si tuvieras que elegir una tecnología en la que especializarte, es más o menos como un salto al vacío si no tienes en cuenta tus inquietudes. Como programador me he sometido a continuas reflexiones sobre dónde debería especializarme, muchas más de las que me hubiera gustado. Estar en momentos donde te cuestionas tus propios conocimientos y las decisiones que has tomado hasta el momento no es 100% beneficioso siempre, ya que te resta dedicación al estudio de tu campo para estar buscando las alternativas que el mercado demanda o que tus inquietudes necesitan.

Seguramente, si no eres de la comunidad de Rails o de Ruby, no habrás estado siguiendo la última polémica surgida con las altas esferas de los desarrolladores de Rails. No te preocupes, te hago un mini resumen. Existen muchas opiniones sobre las bondades y limitaciones de Rails en la propia comunidad, pero la corriente más crítica es la que mantiene la idea de que el framework fue desarrollado por DHH para construir Basecamp y, que todo va orientado según las necesidades y criterios de DHH para su proyecto. En esta línea, muchos desarrolladores terminan dejando la comunidad por no estar en sincronía con las decisiones que se toman, siempre con la idea de que éstas están sujetas al ideal en cuestión. La última polémica la generó Piotr Solnica (si no lo sigues, ya estas tardando) con un artículo en su blog que generó mucha polémica en la comunidad: My Time with Rails is up.

*   *   *

Polémicas a parte, Piotr planteaba algo que todo programador nos pasa a menudo en nuestra vida profesional: ¿Estamos usando la mejor tecnología, los mejores recursos? Obviamente muchos puristas dirán que no importa la herramienta sino el mecánico, totalmente de acuerdo. Pero es posible que muchas de las paredes que nos encontramos en nuestro día a día se deban a que estamos usando una herramienta que no concuerda con nuestra forma de ver las cosas, de buscar y plantear las soluciones.

Para que te hagas una idea, voy a plantear 3 escenarios. El primero mi background actual, dónde estoy trabajando. El segundo, con lo que estoy jugando a ver que puede pasar al primer escenario y, por último, las herramientas y tecnologías que me gustaría que pasaran a los estados anteriores.

Mi background actual

Bueno, si me conoces o has leído algo escrito por mí en redes sociales, sabrás que soy desarrollador de Ruby y Ruby on Rails. Trabajo con bases de datos relacionales la mayor parte del tiempo pero me apoyo mucho en NoSql como Redis. Me peleo a diario con frameworks de Javascript como jQuery y últimamente, con ReactJS que está entrando tímidamente en este paso (y me alegro).

A parte de las herramientas y las técnicas que uso a diario, éste es mi estado actual. No quiero ponerme pedante con clean code y estas cosas que más que unos skills las considero un must.

¿Con qué estoy jugando?

MongoDB y ReactJS son los dos juguetes más predominantes que tengo. El primero ya lo llevo usando un tiempo pero no consigo hacerlo pasar al paso anterior por diferentes motivos. El primero es que nunca me lo HAN requerido en los puesto en los que he estado y, el segundo, el no haber tenido la oportunidad de trabajar con más compañeros expertos en este sistema. Es cierto que lo incluí en la última fase de Sociack en producción, pero sigo pensando que fue muy amateur y por ello, no lo cuento.

ReactJS se encuentra a caballo entre este y mis herramientas de trabajo, te explico por qué. Hace 4 semanas empezamos a usarlo en mi empresa (KitmanLabs), pero iba de segundo de abordo en este proyecto. Mi background es más de Backend que de FrontEnd y mi compañero (Michael)  es lo contrario, mis tareas se enfocaban a “hacer la cama” para que él se centrara en ReactJS y D3. Pero no por ello me quede sin jugar :). Creé mi componente y ayude a mejorar los que implementó y, tengo que decir que la vida en componentes esta muy molondria.

¿Con qué me gustaría jugar?

Aprovechando que estoy metiendo medio pie en ReactJS, siempre me ha interesado poder desarrollar mis proyectos con su versión en dispositivos móviles. Aprovechar ReactJS para crear componentes usables en Web y móvil a la vez va a ser algo que, más temprano que tarde, va a llegar.

La rama Data Science. Se está poniendo cada vez más de moda tener a un científico de datos cuando tu aplicación coge cierto volumen de usuarios y de datos, para que esta persona empiece a explorar caminos de explotación de estos datos. Me interesa por tener una base muy teórica, por las posibilidades que ofrece en una época en la que las API’s están más presentes que nunca (y menos que mañana) y en la que aún estamos en pañales en esta rama. Trabajar con macro conjuntos de datos para sacar patrones es algo que me apasiona pero, a su vez, me aterra por no saber aún que puerta es la que me llevará a adentrarme en este campo con el añadido que Ruby no tiene cabida (aún, echa un vistazo al proyecto 3×3) en el sector.

*    *    *

Si eres programador, te sentirás más o menos identificado con esta lista de deseos. Si no lo eres, seguro que en tu sector tienes el gusanillo de probar nuevas tendencias o técnicas que están siendo muy utilizadas o en auge. Es una constante en nuestras carreras.

Para enlazar ambas partes de mi artículo, planteo la duda: como Piotr en su artículo (a parte de roces ideológicos), ¿están nuestras herramientas y recursos en concordancia con nuestras inquietudes? Si quiero desarrollar cosas para analizar datos, debería estudiar R y/o Python o Julia. Si me gustan los dispositivos móviles, ¿por qué no empiezo con IOS o Android? ¿Me irá bien con React Native?

El tiempo es limitado y hay más cosas que el trabajo en la vida, la gestión del tiempo para una buena conciliación familiar/social y profesional es un reto en sí. Así que todo con calma, paciencia y dedicación se puede solucionar. Pero no puedo ocultar que estoy impaciente por conocer cual será el próximo gran paso en mi carrera y si será en la dirección adecuada sabiendo cuales son mis inquietudes.

¿Cuáles son tus inquietudes? ¿Cuáles serán tus próximos pasos?

Prototipado

Prototipado: construyendo mejores aplicaciones.

Hace un tiempo que descubrí el prototipado como una nueva forma de documentar nuevas funcionalidades en un proyecto. No es un concepto nuevo para los desarrolladores pero es un nuevo paso en el flujo de trabajo para desarrollar aplicaciones.

Todo el mundo conoce la importancia de los usuarios en el proceso de desarrollo de nuestras aplicaciones. Son una de las fuentes para conocer si estamos construyendo una buena solución o vamos en el camino equivocado.

Otro pilar fundamental es el departamento de I+D. Normalmente, ellos no son gente con conocimientos técnicos y necesitan un punto intermedio para discutir cada detalle. Hasta ahora, contamos con algunas técnicas y procedimientos que nos permiten encontrar este punto: BDD, designs y herramientas de desarrollo rápido.

Y finalmente, el tercer factor que influye en el producto es el equipo de desarrollo. Aquí me encuentro yo. Necesitamos conocer los puntos críticos que nos encontraremos y es nuestra responsabilidad dar una estimación, al menos intentarlo :). Por ello, la información acerca de la nueva funcionalidad necesita ser lo más exacta posible para reducir el margen de error.

*   *   *

El prototipado es ese punto intermedio. Necesitaos construir algo lo suficientemente cercano al diseño que ha sido validado y al resultado final, al mismo tiempo. Y necesitamos  que todo se pueda cambiar rápidamente y con la menor cantidad de recursos posibles. La solución necesita ser práctica también porque se la enviaremos a un grupo reducido de clientes para explorar cómo la van a usar y obtener un valioso feedback de ellos.

En resumen, nuestro prototipo necesita ser:

  • Práctico
  • Representativo
  • Dinámico

¿Cómo lo haremos? La respuesta es: FrontEnd. Si piensas cómo es el proceso de fabricar un coche, el primer paso es el motor, la transmisión, las ruedas…Después el chasis y finalmente las cosas para conducir y demás. ¿Y si lo hiciéramos al revés? Crearíamos en primer lugar el chasis y todo lo que el cliente necesita para hacer un uso real de nuestro coche. Podemos validar la experiencia del usuario con el diseño y nosotros (el equipo de desarrollo) conoceríamos  muchos detalles como el espacio para el motor, la distancia con respecto al suelo, la aerodinámica y más detalles críticos y prácticos para nosotros. Éste es el concepto de prototipado.

*   *   * 

Las claves para crear buenos prototipos son encontrar exactamente el punto intermedio entre el diseño y producción. Por esta razón, necesitamos centrarnos solo en la interfaz con el usuario usando la tecnología que usaremos en la interfaz pero con datos de prueba.

Un ejemplo. En mi empresa (KitmanLabs), estamos usando ReactJS y Highcharts para crear gráficas geniales. Nuestro Backend es Ruby on Rails pero eso no es importante para el prototipo. Tenemos un proyecto publicado específicamente para nuestros prototipos usando datos de prueba para simular casos reales. Como un entorno de pre-producción (staging), podemos acceder a la plataforma de prototipos para visitar a nuestros clientes y discutir con ellos las nuevas funcionalidades y descubrir si serán útiles e importantes para ellos.  El prototipo sigue los diseños aprobados y usa ReactJS y Highcharts. Podemos modificar cualquier cosa rápidamente porque la parte más compleja es cómo procesamos los datos antes de mostrarlos en la interfaz. Después de ajustar el prototipo con el feedback de los cliente, recibir la validación de los departamentos de diseño y producto, sólo tenemos que crear el proceso de backend usando el mismo código que en el prototipo en la interfaz final, porque solventamos cualquier problema que apareció al representar el diseño aprobado. Ese el punto intermedio.

Espero que este artículo te sea útil, si quieres hablar mas sobre prototipado, déjame un comentario o envíame un email. Quiero saber tu opinión y experiencias.

Por cierto, estamos contratando :)

English version

GraphTheory

Teoría de grafos aplicada a la gestión de equipo

Siempre he estado convencido de que un equipo de trabajo es como un gráfo y, como tal, se puede estudiar siguiendo los mismas técnicas. Al estudiar mi problema del grafo NP-Completo, donde intentaba sacar una formula para balancear un gráfo tras la entrada de un nuevo vértice, me di cuenta de la similitud que tiene con respecto a la incorporación de un nuevo miembro a un equipo.

No tiene sentido en este post enumerar las ventajas del trabajo en equipo, pero voy a destacar la ventaja que tiene para cada integrante el trabajar al lado de otros profesionales, aprender de ellos y viceversa, claro.

*   *   *

Si tratamos a un equipo como un gráfo conexo, donde cada vértice es un miembro del equipo y las aristas las relaciones entre estos, podremos estudiar (entre otras cosas) cómo afecta la incorporación de un nuevo miembro al equipo.

grafo inicial
Representamos un equipo por un grafo tagueado y ponderado.

 

 

Vemos como el grafo anterior, las arístas tienen un número que simboliza el aporte de valor que existe en la relación entre dos miembros del equipo. Cada vértice tiene un valor resultado de la influencia del miembro en el equipo debido a su aporte de valor al resto. Con éste planteamiento, ya estamos en disposición de estudiar la entrada de un nuevo sujeto al equipo.

New member
Un nuevo integrante llega al equipo y tenemos que evaluar esta incorporación.

 

Un nuevo integrante está en la sala y nos toca ver cómo afecta al resto del equipo ésta incorporación. Lo colocamos cerca de los compañeros con los que va a trabajar (lógico) para que la relación sea más fácil y también la integración. Ahora tenemos que observar cómo influye al valor del resto de miembros. Para ello, vemos 3 fases:

Expansión

El recién llegado viene con nuevos conocimientos que el equipo necesita incorporar. Su llegada influirá directamente en los miembros con los que trabaja directamente aumentando el conocimiento del equipo con sus cualidades. Esta fase la llamo expansión.

Graph expansion
Los nuevos conocimientos llegan a los nodos adyacentes al nuevo miembro.

 

Los conocimientos del nuevo integrante llegan a sus compañeros más inmediatos y éstos aumentan sus conocimientos.

Propagación

Al aumentar el conocimiento y las habilidades técnicas de los miembros de su al rededor, el nuevo integrante consigue que la relación de éstos con el resto de compañeros adyacentes aumente también. Esta fase la llamo propagación.

 

Todos los miembros que trabajan con los adyacentes al nuevo miembro se encuentran con compañeros que han aumentado sus conocimientos y de los que se nutren en el día a día para sus propias actividades.

Promoción

Por último, queda ver cómo el nuevo integrante se beneficia de empezar a trabajar en un nuevo entorno. Al aumentar los conocimientos del resto del equipo y el valor de éste en general, el nuevo integrante tendrá más margen para aprender del resto de compañeros. Esta fase es la promoción.

Propagation
Los nodos adyacentes también propagan los nuevos conocimientos.

Obviamente, tras esta fase nos encontramos que el nuevo miembro ha aumentado sus conocimientos desde que se incorporó al equipo y, por tanto, vuelve a empezar el ciclo.

(Imagen CicleTeam)

Este comportamiento cíclico da lugar a un grafo que intenta balancearse hasta el infinito. Si intentamos  desarrollar un algoritmo que calcule el estado final del grafo tras la llegada del nuevo vértice, nos encontramos con un problema complejidad NP (imposible o muy complicado, en palabras normales). En términos de problema de universidad, es muy malo encontrarte con esto en un examen o en tu día a día. Pero en término de aumentar el valor de tu equipo, es un factor determinante.

*   *   *

Cuando me encontré con este problema descubrí que había factores determinantes a la hora de gestionar un equipo. No sólo referente a elegir al candidat@ adecuado para incorporarlo al equipo, si no a la hora de establecer las correctas relaciones entre los ya integrantes de él. Se pueden observar 3 razones por las que no se producirá una ruptura de éste ciclo

  1. La incorporación de un miembro que aporte un valor negativo, implicará que en lugar de tender al infinito el valor del grupo, lo hará a cero.
  2. La mala distribución de los componentes del equipo, hará que la fase de propagación no funcione y rompamos el ciclo.
  3. Un candidat@ que suponga un nodo asilado del resto, que soluciona sus problemas pero se aísla del trato con el resto, no hará funcionar la fase de promoción y también romperá el ciclo.

Éstas son tres cosas importantes que debemos vigilar si somos un Team Manager en cualquiera de sus roles: Lead Team, CTO, … Un equipo bien engrasado es complicado de conseguir pero es la diferencia entre marcar o no la diferencia.

Espero que te haya ayudado como a mí a ver la gestión de equipos desde una nueva perspectiva y, si es así, compártelo :).

El conocimiento que no se comparte, es conocimiento que se pierde.

Un barquito de cascara de nuez

Supongo que todos recordaremos la canción del famoso mosquito que transportaba doradas gotas de miel en su barquito de cascara de nuez. ¿No? Entonces no tienes infancia… Bueno, no tanto, yo la descubrí a los veintitantos pero desde entonces la tarareo continuamente. Lo más curioso de esta canción es que puede aplicarse a muchas de las partes de mi vida y supongo que es la razón por la que no es una canción más de mi lista de “tarareos greats hits” como: La canción del Mercadona, Como una ola…entre otros.

¿A qué viene la flipada del mosquito?

Analizamos la canción. Un mosquito que pudiendo volar a cualquier parte prefiere ser un navegante que se construye un barco con una cascara de nuez y velas de papel…en el mar…papel…A la primera que llueve ya sabemos el desenlace ¿no? La historia nos desprende una pregunta y es: ¿Qué nos lleva a complicarnos la vida?

Hace dos años me convertí en un mosquito que quería ser navegante. A mi barco lo llame Sociack y lo cargué de gotitas de miel (para los menos versados, hacen referencia a ideas). Os aseguro que tuvimos tormentas contra las que nuestras velas de papel no nos sirvieron de nada, las tuvimos que rehacer una y otra vez, pero esto no nos desmotivaba. Sabíamos que el camino iba a ser muy complicado, y para colmo, solamente intuíamos que la recompensa iba a merecer la pena. ¿Estábamos locos? La respuesta es otra pregunta: ¿Había otra forma de transportar las gotas de miel?

La noticia es que este es el último mes de vida del proyecto Sociack. El pasado Septiembre tomamos la decisión de no continuar con él y dedicarnos a otros menesteres entre los que se encontraba salir de España. Con la misma determinación que tuvimos al empezar en Sociack, un mes después estábamos en tierras Irlandesas y el próximo Lunes empiezo a trabajar con un pedazo de equipo: KitmanLabs. Cerramos así una etapa donde hemos volcado mucho tiempo y esfuerzo y del que nos llevamos mucho aprendido. Pero lo más importante: un proyecto es algo que haces durante tu vida, no al revés. Es muy importante tener presente esto, ya que muchas veces nuestro ego no nos permite ver con claridad (lo sé por propia experiencia).

Me gustaría hacer una lista de agradecimientos a todos los que mas o menos se implicaron con Sociack, temo olvidarme de alguien y que  me salga mal la jugada pero me gusta el riesgo:

Patricia Carmona: compañera en todos los sentidos. GRACIAS.

Tana: Por aguantar, incluso sin hacerme recoger nada por olvidarme de que estabas aguantando todo el día.

Andrés Torrejón: compañero de aventuras y socio, estás hecho un crack.

Félix Ontañón: no hay 3 sin 4 aventureros, hombre ventas y nominador de puestos de trabajo.

Rafa Poveda: Gracias por aquél “¿A qué esperáis para vender esto?”

Jerónimo Palacios: Primeros empujones, experiencias y choques de realidad.

Luis Rull: Primer intento de soltarnos las perras y apoyo moral desde el principio.

Emilio Marquez: Por los ratos de café donde nos ponías por delante retos y experiencias.

Rebeca Pontiveros: ¡Nuestra primera miembra del equipo! Gran trabajo desde el principio, no hay palabras.

Carla Marcelo : ¡Nuestra primera “becaria”! Talento y ganas de aprender, un placer haberte tenido en el equipo.

Socialancer (Benet y Beatriz): por vuestros consejos y la gran difusión que nos habéis dado desde el principio.

– A todos y cada uno de los que recomendasteis Sociack desde el principio y nos apoyasteis: Felipe Martin, el equipo de Calidad Pascual, FUNED, …

– Y por supuesto, gracias a todos los que nos decíais eso de “killo! ¿la empresa como va? ¿Nos hacemos ricos ya o que?” A vosotros os llevo en la patata XD.

Y si me pongo a pensar habré olvidado gente, editaré el post si me acuerdo :).

El blog cambiará de tonalidad, ahora estoy en otra movida y como lo uso para desahogarme pues quien sabe…¡lo mismo hasta escribo en inglés!

Gracias por leerme y Yip ka Yey …