Archivo de la etiqueta: programador

Crunch o sobresfuerzo en el trabajo, ¿Es autoimpuesto?

Ayer, mientras paseaba por la playa con mi padre, vi a un antiguo compañero que hacía mucho tiempo con el que no coincidía. Me contaba que estaba a tope de trabajo, como siempre desde que se cambió de empresa. Cuando le dije que ahora era Agile Coach en lugar de programador, me dijo que había hecho bien, ya que hay que intentar dejar la programación, ya que todos los programadores tienen crunch.

El crunch es un exfuerzo excesivo y continuado para terminar el trabajo asignado (normalmente software) en el plazo previsto. No es extraño oir casos en los que se han trabajado jornadas de incluso 60-80 horas semanales. Este concepto viene sobre todo del mundo de los videojuegos y se popularizó cuando dió la vuelta al mundo al ocurrir durante los ultimos meses anteriores a la salida del videojuego GTA5.

Yo tengo una opinion muy clara al respecto y es de lo que quiero hablar. Creo sinceramante que nosotros mismos debemos tener el control de la potencia de nuestro motor personal, que representa el trabajo que realizamos y por ello somos los unicos responsables de su sobrecarga cuando ocurre.

Asumiento esto, ¿qué obliga a uno mismo a forzar la máquina más de su capacidad? He visto muchos ejemplos de compañeros sufriendo de una gran carga de trabajo día tras día, generando gran ansiedad, poniendo incluso en peligro su salud y su vida familiar. Estas personas piensan que tienen a sus espaldas ya sea el proyecto, el equipo o incluso la empresa y que si bajan el ritmo, pueden ocasionar un gran problema. En muchos de estos casos, estas personas acaban cambiando de trabajo o necesitando meses de baja laboral por ansiedad. ¿Y adivinas qué ocurre con la empresa que tanto estaban protegiendo y por la que habían puesto en riesgo su salud? Al final no se ve perjudicada como ellos temían, sino que sólamente se readapta y sigue adelante.

Uno mismo debe intentar ser consciente de dónde viene esa presión por trabajar más, para gestionarlo apropiadamente y no llegar a estos extremos. Debe tener realmente el control del propio esfuerzo, para incrementarlo cuando es necesario pero también para bajar el ritmo cuando la situación se convierte en insostenible y empieza a ocasionar efectos secundarios como la falta de sueño, irritabilidad o incluso desgaste de las relaciones con los seres queridos.

Hay casos en los que esta presión viene del exterior, como el propio mercado, de los usuarios, stakeholders,negocio… Sentimos que siempre se pide más y más y pensamos que estamos fallando al no poder satisfacer la demanda. En estos casos hay que tener en cuenta que en el mundo del software, no hay limite al numero de ideas, iniciativas, mercados, hipotesis que probar… Siempre se va a pedir más y más funcionalidades y desarrollos. Sincéramente, no me gustaría trabajar en un equipo de desarrollo en el que no existíera esta demanda contínua de cosas nuevas a hacer. Para mí sería un síntoma de que las cosas van a pique, que el producto está a punto de morir.

También influye la presion social, compañeros, o jefes que tienen asumida esta cultura de darlo todo, y para encajar en el grupo necesitas hacer lo mismo. Mola mucho cuando estás en un equipo motivado. Sin embargo cuando notas que lo que ocurre al tu alrededor se escapa de la simple buena motivación y que en general todo el mundo se está dejando de lado la salud o la familia, hay un serio problema. En estos casos lo mejor es intentar entre todos hacer este análisis del origen de la presión en una retrospectiva o incluso tomando una cerveza en un bar, para poder disociarse del día a día y ser consciente de la realidad del problema. En ocasiones es dificil hablar de ello porque es un tema tabú o está demasiado asumido en la cultura del equpo para darse cuenta.

Sin embargo, en la mayoría de casos lo que ocurre es un exceso de autoexigencia en el que no hay una presión real que venga del exterior. Es sencillamente una sensación de necesitar hacer más y más porque siempre el backlog de cosas por hacer no para de crecer. También me he encontrado muchos casos en los que lo que ocurre es el sindrome del impostor, es decir, el sentir que no nos merecemos el puesto, cargo o sueldo que tenemos. Esto suele provocar el intentar trabajar más duro o más tiempo para «demostrar» que sí que nos lo merecemos. En estos casos es importante reforzar la seguridad en uno mismo, y también aprender que decir que «NO» es más profesional que decir un «SI» y después hacer algo de mala calidad y llegar a un sobresfuerzo que te obligue a buscar trabajo en otro sitio.

En la industria del software tenemos la ventaja de la gran oferta de puestos de desarrolladores. En 2 semanas podemos encontrar un trabajo y en un mes podemos encontrar un BUEN trabajo. La presión para hacer más y más está en todos los lados, pero es responsabilidad de cada uno mantener el control de la potencia de nuestro propio motor para ir a buena velocidad de manera constante sin «griparlo». Poder volver a disfrutar del trabajo de programador y al mismo tiempo hacerlo cada vez mejor por la motivación que tenías hace años y que has vuelto a encontrar. Sé que todo esto más facil decirlo que hacerlo. Si piensas igual, habla con alguien de tu confianza o pide ayuda si lo necesitas.

Características de la comunicación de equipos de alto rendimiento

Hay multitud de vídeos, libros, artículos en Internet que hablan de los equipos de alto rendimiento. ¿Qué son? ¿Cómo se definen? ¿Qué los diferencia del resto? Y casi lo más importante. ¿Cómo un equipo puede llegar a serlo?

En el Laboratorio de Dinámicas Humanas del MIT han estudiado multitud de equipos y han identificado qué características de comunicación tienen. Estas características se observan en equipos que tienen gran creatividad y trabajan con gran energía y compromiso por encima de cualquier otro equipo. Estas características son observables, cuantificables y pueden usarse para ayudar a equipos a mejorar, enfocándose en sus flujos de comunicación.

La comunicación de los equipos se puede ponderar usando tres categorías principales.

  • Energía

La energía de comunicación es lo que también se llama ancho de banda.  En esto interviene mucho el medio que usen los miembros para comunicarse entre sí.  El medio de comunicación con más energía o ancho de banda es una conversación cara a cara. Cada interlocutor observa los gestos y el lenguaje corporal, oye e interpreta la entonación con la que dice cada frase además de entender el contenido del mensaje en sí mismo.  Después de éste, pasaríamos a usar la videoconferencia en la que no podemos ver por completo a la persona con la que hablamos al estar limitados a una pantalla. Después de los medios audiovisuales tendríamos los medios de comunicación de sólo voz como el teléfono. En ultimo lugar tenemos sistemas de mensajería asíncronos como los correos electrónicos . En estos últimos son en los que más malinterpretación hay por lo que se gasta mucho tiempo en ser exhaustivos en su escritura y aún así no consigue transmitir correctamente el mensaje.

Un equipo de alto rendimiento hace uso de canales de comunicación de gran energía. Conversan hablandose cara a cara para transmitir la información en el menor tiempo posible y disminuyendo los malentendidos.

  • Engagement o dedicación. 

Cuando se mide la dedicación de la comunicación, lo que observamos es la frecuencia en la que ocurre la misma entre cada uno de los miembros del equipo. Lo importante de esta parte es que la frecuencia entre todos sea homogénea, que todos hablen con el resto del equipo aproximadamente las mismas veces. Cuando los flujos de comunicación son heterogéneos y desiguales, se puede detectar por ejemplo que hay un líder el cual siempre interviene para que otros miembros se sincronicen entre sí. Esta persona recibiría más flujos de comunicación que el resto de miembros y se convierte en un cuello de botella. También se puede detectar a miembros del equipo que no están tan integrados. Estas personas recibirían una menor frecuencia de comunicación de sus compañeros que la que recibe el resto y normalmente no pueden aportar tanto como el resto.

  • Exploración

En un equipo de alto rendimiento siempre hay necesidades de conocimiento nuevo que no tienen. Para ello es importante que sepan explorar y encontrar en otros medios (Internet, libros, foros, comunidades técnicas,  contactos en otras empresas,..). Cuanta más facilidad tengan en encontrar esa información, estos equipos tendrán menores bloqueos y sus resultados serán de mayor calidad.

¿Cómo podemos medir estas características?
En un próximo artículo que escribiré en breve, explicaré una herramienta con la cual se puede visualizar el engagement o dedicación de un equipo.

Fuente: Harvard Business Review

Autogestión en equipos dentro de consultoras – Novela corta de ciencia ficción

Amanece en la playa Muchavista, situado a media distancia entre la población de Campello y la ciudad de Alicante.  Ya se ve bastantes corredores aprovechando el buen tiempo para estirar las piernas a lo largo del paseo marítimo. Los barrenderos limpian los últimos restos y vasos de Mac Donalds dejados por los paseantes nocturnos antes de dar paso a un día que promete tener bastante ocupación de la playa.

Sin embargo, el verdadero movimiento no está precisamente en la arena. A pocos metros de la misma se ve un chico de 30 años, de pie mirando al mar y disfrutando de su café en una taza en la que se lee las palabras «Clean Code». Da los últimos sorbos, deja la taza en una mesa del jardin y estira sus brazos y piernas para despertarlos después de una noche de sueño reponedor. Javier y su equipo son miembros de una consultora internacional, HGY,  que da servicio a grandes corporaciones financieras. Son un equipo 100% autogestionado dentro de la compañía, y muy disputado entre los clientes de la misma.

Javier recoge la taza y se va al interior de la pequeña casa de dos plantas con vistas al mar.  Deja atrás el pequeño jardín algo dejado a su destino al que nadie presta atención. Atraviesa la cocina  y sube los escalones que dividen la casa entre la planta en la que Javier y sus compañeros de equipo descansan y comen de la planta donde trabajan. El clac, clac, clac de un teclado mecánico le devuelve a Javier a la realidad del trabajo, y le produce una sonrisa.

– Diego, ¿Cómo fue la revisión de lo que entregamos ayer por la tarde a Banco Palomo? ¿Tenemos ya algún comentario de Daniel, nuestro querido Product Owner? – Pregunta tirando  una pelota de malabares que había encima de una de las mesas a  Diego, un miembro del equipo que estaba revisando el tablero Kanban del proyecto.

– De momento no, hay que dejarles que respiren. La entrega de ayer por la mañana les encantó como bien nos dijeron. Un par de días más y creo que ya tendrán el producto que esperaban. Bueno el que ni siquiera se esperaban. – Responde Diego cogiendo la pelota al vuelo, para sorpresa de Javier.

Diego tiene un poco más de edad que Javier pero, al contrario que él, aún no se le asoma ninguna cana.  Es especialista en sistemas web y entre él y Raúl han desarrollado casi todos los interfaces de usuario del sistema Peer Loans, que permite al banco que sus clientes elijan a quién prestar el dinero de sus depósitos.

– ¿Sabemos algo de Héctor? Desde que cogió el avión a Tailandia con su novia Malai no hemos recibido ninguna de sus fotos empalagosas de parejita feliz. – Pregunta Raúl sin mover la cara del monitor de 32 pulgadas en el que va añadiendo pruebas automatizadas para empezar a desarrollar uno de los últimos módulos de Peer Loans. –  Eso me recuerda que tenemos que revisar a los últimos candidatos para reemplazarlo. –

Raúl es un chico de 33 años, experto en lenguajes web y siempre viste con camisetas de Dragon Ball. Lleva en el equipo 3 años y siempre le acompaña su mujer y sus dos hijas allí donde vayan a trabajar.

– A mi me gustaba Jesús, le da a los dos palos de back y front con la suficiente soltura como la que necesitamos. Además es un miembro respetado del Meetup Full Stack Dev Alicante. – Dice Eva acercandose al monitor de Raúl  – Podemos hacerle una visita o quedar en algún bar para hablar con él. Si le gusta el sueldo que le ofrecemos, que seguro que lo hará, estará con nosotros en un par de días. –

Eva es la chica  de QA, de casi 40 años, y en los últimos años ha hecho un gran trabajo inculcando conocimientos sobre casuísticas de tests a los miembros del equipo. Tiene facilidad de palabra y habla muchos idiomas, lo que le permite estar en comunicación constante con los clientes para prevenir todos los escenarios posibles.

– Raúl, no te olvides del buffer overrun en el tratamiento de este campo –  Le dice Eva a Raúl acercándose a su hombro – Por cierto, buen trabajo con estos escenarios. – Una sonrisa de satisfacción casi imperceptible asoma en el rostro de Raúl mientras ejecuta los tests. Una columna de puntos rojos de tests fallidos le indican que es momento de empezar a trabajar en ese trozo de código.

–  No olvidemos que en un par de semanas tendremos nuevo proyecto. A este le quedan sólo un par de coletadas.-  Recuerda Javier desde su puesto de trabajo abriendo la página de la tecnológica Dell y buscando un servidor nuevo para su sistema de integración continua- ¿Habéis revisado últimamente la lista de posibles proyectos? –

Diego se acerca jugueteando con la pelota de malabares a su puesto. Pulsando un botón de su portátil pone en iluminacion su gran monitor así como los leds de su teclado y ratón. Sin sentarse coge el ratón y abre la lista de proyectos que los clientes de HGY les ha enviado. Su éxito con la nueva herramienta de Banco Palomo ha hecho que sean uno de los equipos más solicitados de toda la consultora y prácticamente de toda Europa.  Los honorarios que ellos mismos solicitan son altos pero hay muchos clientes a los que no le importa gastar un poco más para tener a estos chicos a su disposición.

– Ja, ja, ja. ¿A que no adivinais quién nos pide volver a trabajar con ellos? – Suelta Diego riéndose con las manos detrás de la nuca.

Eva y Javier se acercan a su monitor y se unen a Diego en las risas.

– ¿Podemos reirnos todos? – Suelta socarronamente Raúl sin levantar la mirada del monitor y sin dejar de teclear.

Eva, apoyada en la espalda de Diego, se vuelve a Raúl y le dice con una gran sonrisa – Nuestro «amigo» Financial Bureau quiere que le hagamos el sistema de banca con Realidad Aumentada igual al que le hicimos a Banco Marsella. –

–  ¡ Ni de coña ! – Suelta tajantemente Raúl mientras vuelve a ejecutar la lista de tests.  Ahora una columna de puntos verdes remplaza a los rojos, indicando que su cambio ha funcionado a la perfección. Aprovecha para girarse y mirar al resto del equipo. – ¿Os acordáis de lo impertinente que fue el CIO? Nos obligaba a trabajar a través de su entorno virtual. Como si nuestro entorno de red cifrada no fuera menos seguro que el suyo.  Quiere velocidad y calidad y nos da un martillo y un cincel para escribir código.  ¿Hay algun proyecto en Tailandia?  –

– Tú lo que quieres es intentar que Héctor vuelva con nosotros. Si encontramos una oficina cerca de donde van a montar la Startup estarías visitándole a todas horas. – Le dice Eva mirando la lista de posibles clientes.

– No. Es que allí tiene la oficina central Jurgen Fowler, el experto en EcmaScript 11, y que lideró su definición. – Responde Raúl, con media sonrisa –  He estado en comunicación con él últimamente y creo que nos puede preparar un curso intensivo al menos unos días si estamos por allí. El precio que pone es asequible y algunos lo necesitáis bastante… –

– Venga, me apetece empezar a codificar ya. ¿Qué os parece que hagamos una ronda de 3 pomodoros? – Sugiere Diego dirigiéndose a su silla. Esta idea hace que Javier y Eva también vayan corriendo a sus sillas y Raúl haga crujir sus dedos preparándose para una sesión intensa. – Pongo el crono de 25 minutos en marcha.  Empezamos en  3,2,1… –

El sol ya está iluminando con fuerza la arena y los primeros bañistas entran en las aguas de la playa Muchavista. Javier y su equipo están ya concentrados trabajando el resto día para terminar lo poco que le queda de su asignación actual. En un par de semanas, en la fachada de la casa colgará un cartel de «Se alquila». El equipo se habrá desplazado a un lugar algo más montañoso, por sugerencia de Eva. Sólo ellos mismos saben cual será el siguiente proyecto y lugar en el que trabajen. Son dueños de su propio destino.

FIN

Esta historia, que es naturalmente una historia de ficción, representa una imagen que a día de hoy parece imposible de conseguir en equipos que trabajan para consultoras. Hemos visto algunos ejemplos de decisiones en manos en un equipo totalmente autogestionado, aunque puede haber más. Estos equipos:

  • Deciden quién entra y quién se va de su equipo
  • Deciden su sueldo
  • Deciden su proyecto
  • Deciden dónde trabajan fisicamente
  • Deciden sus herramientas
  • Deciden su formación
  • Deciden cuándo toman vacaciones

Cuando un equipo llega a estos niveles de autonomía, logran una gran motivación y eficacia, lo cual les convierte en un equipo de alto rendimiento y para los clientes se traduce en productos de gran calidad e innovación. Sin embargo para llegar a estos niveles hace falta que tanto los miembros de los equipos como los directivos de las organizaciones tengan como meta conjunta esa autogestión. Los directivos y cargos intermedios tienen que aprender a delegar aunque suponga que al principio cometerán errores. Pero también cada miembro del equipo debe responsabilizarse del poder que se le da y saber dar el paso adelante para tomar esas decisiones. Aunque no lo parezca, tan difícil es lo uno como lo otro. Pero ¿quién sabe?, la ciencia ficción a veces se convierte en realidad. Todo camino empieza por un primer paso ¿Qué tal si empezamos por que los miembros de tu equipo puedan  autoasigarse las tareas?

 

 

Optimiza el uso de tu memoria (mental)

¿Cuantas cosas sabes hacer a la vez? ¿y hacerlas realmente bien? ¿Y además en un tiempo aceptable? Antes de responder a estas preguntas, me gustaría que conocieras cómo funciona nuestra mente.

El cerebro está compuesto de bloques de memoria de cortisimo plazo o de trabajo, de corto plazo y de largo plazo. Cuando realizamos un trabajo utilizamos una combinación de todos estos bloques a la vez. Por ejemplo, un desarrollador de software necesita tener en la mente el lenguaje de programación a usar, el diagrama conceptual del proyecto que está modificando, el objetivo de la funcionalidad que está desarrollando y en la zona de cortísimo plazo el algoritmo que se está escribiendo en ese momento. Un ingeniero de soporte puede tener el sistema del cliente, los detalles del problema en cuestión y el producto del cual está dando soporte. Un comercial puede tener detalles del producto que vende y detalles del cliente al que quiere vender.

Bloques de memoria de un desarrollador concentrado
Bloques de memoria de un desarrollador concentrado

Contínuamente tenemos que reemplazar estos bloques. Esto puede ser  por una interrupción que provoca un cambio de contexto y necesitas modificar tu memoria de más corto plazo. Pero también puede ser cuando cambias a desarrollar otro programa, otra historia de usuario u otra funcionalidad, incluso por un cambio de lenguaje de programación. Cada cambio requiere que uno o más bloques de memoria se reemplacen. Y ese reemplazo tarda tiempo. Si es memoria a corto plazo puede tardar incluso más de 15 minutos pero si es memoria de medio plazo como el lenguaje de programación se puede tardar días en sustituirlo completamente.

Cambio de tarea en otro lenguaje de programación
Cambio de tarea en otro lenguaje de programación

Hasta que un bloque es completamente sustituido, el bloque tiene una mezcla de distintos contenidos. Es el momento en el cual se toman decisiones incorrectas y se cometen fallos. Es cuando lo justificamos a que no estamos completamente concentrado y se producen frustraciones.

Para tomar mejores decisiones, realizar un trabajo de mejor calidad y más rápido hay que reducir el WIP. WIP significa trabajo en curso (Work In Progress) y hay que intentar que como máximo se tenga una tarea en la cabeza,  o una característica nueva a la vez por equipo, o una incidencia de soporte a la vez. Ya existen herramientas como Kanban, GTD y la Técnica Pomodoro para ayudarte a enfocarte en una tarea o con un mínimo de trabajo a la vez. Pero ninguna de estas técnicas ayuda a decidir con qué tareas ponerse o qué trabajo empezar una vez se ha terminado para minimizar el reemplazo de la memoria de trabajo.

Para ello propongo hacer una lista de los 5  elementos que más se tienen en cuenta a la hora de realizar una tarea . En el ejemplo del desarrollador de sofware, haríamos esta lista:

  • El tipo de tarea a hacer: desarrollo, administrativo (emails, imputar,…) , test, formación…
  • El lenguaje de desarrollo a usar
  • La estructura del programa a modificar
  • El framework o API que se usa: ASPNET MVC, Backbone, Angular,…
  • Las características del cliente que usará la funcionalidad

Para cada característica distinta a la de la tarea que se ha terminado se suma un punto. Si hacemos un tipo de tarea completamente distinta tendríamos 5 puntos porque seguramente necesita reemplazar todos los bloques de memoria. Si es del mismo programa pero hay que cambiar de lenguaje es un punto por el cambio de lenguaje y seguramente otro por el cambio de framework llegando a 2 puntos. Cada vez que se elige una nueva tarea hay que evaluar los puntos de lo que podemos empezar dentro de las que tengan igual prioridad. Idealmente se elegirá una tarea del mismo lenguajes, del mismo programa, con el mismo framework y para el mismo cliente. De este modo reducimos el número de bloques de memoria a reemplazar consiguiendo un resultado con mejor calidad, en menor tiempo y sin frustraciones.

 

¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.

 

 

 

En VSN buscamos C++ developer. Lo que no nos cabe en Infojobs

EN VSN estamos contratando. Necesitamos bastante urgentemente dos programadores C++. Quisiera ampliar aquí lo que no nos ha cabido en la oferta de Infojobs.

Analista/Programador Senior C++  – Programador Junior C++
Dos puestos, uno junior y otro aguerrido, un C++ Black Belt que mapee mentalmente el heap y stack sin siquiera levantar la ceja.

Empresa: Video Stream Networks S.L.
Nos dedicamos a hacer software para cadenas de televisión. Tenemos muchos clientes «pequeños» como televisiones locales y últimamente hacemos muchos clientes grandes como la productora Telson/Turner o Dorna, los que retransmiten el MOTOGP. Tenemos oficinas en varias partes del mundo y clientes en casi todos los lados. Nos falta el Ártico y algún rincón más.

Provincia:
Alicante – España

Concretamente en San Juan de Alicante. Hay facilidades de aparcamiento por ser un pueblo, acceso facil desde la autovía y tiendas cercanas de casi todo. Sólo nos echamos de menos un FNAC.

Perfil del Candidato:
Titulado en Ingeniería, preferiblemente en Informática o Telecomunicaciones o Licenciado en Ciencias (Físicas, Matemáticas)
Usamos regularmente conceptos avanzados cómo muestreo de señal digital, algorítmia avanzada, las capas de la comunicación TCP. Necesitamos que tengas una buena base de conocimientos técnicos y una mente bien entrenada.

Analista Programador – Programador C++ con al menos tres años de experiencia.
Te vamos a meter a saco a mantener un programa complejo y sacarlo adelante por lo que necesitamos que le des caña desde el primer día.

Capacidad para asimilar grandes proyectos y entender su código fuente rápidamente.
Como vas a mantener un programa que ya existe, debes tener facilidad en entender el por qué lo que hace. Nosotros te ayudaremos pero eres tú el que debes darnos la mayoría de respuestas. Si te mola bajarte proyectos del Github por el mero hecho de leerlos para ti esto será pan comido.

Buena capacidad comunicativa tanto hablada como escrita para el trabajo en equipo.
El C++ déjalo para el compilador. Tus compañeros necesitamos entenderte bien, y no digamos ya los que trabajan en otros departamentos.

Must have:

C++.
Como segunda (o primera) lengua madre

Aplicaciones visuales (GUI) sobre plataforma Windows (preferiblemente con MFC/Win32).
Crear botones, grids, ponerles textos comprensibles, elementos alineaditos…

Multihilos/Concurrencia/Tiempo real
Tengo que ser sincero. Te vas a tener que pelear con semáforos y sincronía de hilos.  La aplicación que vas a mantener necesita comunicarse continuamente con otros elementos y no puede pararse a pensar ni 40 milisegundos.

TCP / IP, Sockets.
Crear server, crear cliente, conectar, send buffer, receive buffer… ese tipo de cosas

SO Windows.
Entender bien cómo funcionan los hilos y sistema de ficheros en Windows sobre todo. Leer y escribir en registro y otras cosillas que tan poco gusta a los linuxeros.

Microsoft Visual Studio.
Esta será tu herramienta. Si ya la sabes manejar, y conoces sus secretos sabemos que serás más productivo desde el principio que si nunca lo has tocado.

INGLÉS
Esta claro que si sabes bien programar es muy probable que sepas inglés escrito. Sin embargo esperamos que te desenvuelvas bien también en el oral para poder contar contigo en todo tipo de situaciones. En ocasiones hay que llamar a algún cliente, a algun compañero que vive en otro continente, recibir formación en otro pais,….

Good to have:
(Lo que ya nos emocionará si lo tienes)

* Git, Subversion.
Tenemos la mitad de proyectos en Subversion pero los que mantendrás al empezar estan en GIT. Hacer PULL, PUSH, CLONE… Pero cuidado que yo odio los Feature Branches por lo que voy a estar muy atento de cómo lo usas.

* WxWidgets
Como objetivo de que sea multiplatarforma está hecho en xwWidgets… Lo sentimos

* Boost, STL
Esas herramientas que hacen del C++ un mundo mejor en el que vivir

* ActiveX, OCX, Interfaces COM.
CoCreateInstances y QueryIntefaces. Si te suenan nos harás tilín en la entrevista

* Conocimientos en los estándares, codecs y protocolos de streaming de video.
No sólo el DIVX, piratilla. En las teles usan muchos codecs distintos. Si no los conoces ya te irás familiarizando aqui.

* Java, C#.
Sobretodo el C# que es en lo que estamos basando los nuevos productos aunque el Java también nos será útil

* MS SQL Server, diseño de BD, procedimientos almacenados.
Todo necesita su persistencia y nosotros usamos SQL Server. Tendrás que crearte las tablas y lo que necesites tú mismo.

* Conocimientos sobre servicios REST, SOA.
Es a lo que estamos tendiendo, todo basado en servicios web con REST. Si sabes de qué hablamos cuando te lo preguntemos empezaremos con buen pié.

* ActiveMQ
(sigh)

* TDD, Refactoring, Código Limpio.
Es posible que en la entrevista hagas un kata con TDD. En VSN llevamos muchos años perfeccionando el cómo generar test y cómo hacer código limpio y estructurado. ¡ Muestranos lo que sabes y por lo menos a mí me tendrás en el bolsillo !

* Haber trabajado en un proyecto Open Source
Esto es propuesta mia.  Je, je. Si eres friki del desarrollo, sientete orgulloso y hablanos de cómo has pasado sabados por la noche peleandote con el código sólo por gusto.

Ofrecemos:

* Participar en las decisiones de diseño e implementación de los productos.
Desde el primer día. Pensamos que no existe idea mala y queremos oir tu voz en todas las reuniones.

* 6 Meses + 6 Meses + Contrato Indefinido e incorporación a proyecto estable.
Es un puesto que necesitamos y necesitaremos por lo que si lo haces bien tienes tu sitio asegurado.

* Salario en función de la experiencia aportada por el candidato/a.
No es confirmado pero puedes esperar algo entre 25000 y 30000 euros brutos al año. Pensamos que es un buen sueldo para empezar y pero también que el sueldo no debería ser la única motivación para trabajar con nosotros.

* Facilidades para combinar la vida familiar
Para nosotros es muy importante que estés en la oficina en el mismo horario que el resto de compañeros, sobre todo para trabajar en equipo. Sin embargo si necesitas dejar a tus hijos en el cole y llegar algo más tarde no hay problema. Hay facilidades para ajustar el horario un poco hacia los lados.

* Formar parte de una plantilla con el mejor ambiente de trabajo, participando en proyectos de gran envergadura.
Formarás parte de un equipo muy motivado en el que trabajar con intensidad no está reñido con estar de buen humor.

* Gran colaboración entre miembros del equipo de trabajo.
El departamento de desarrollo forma una especie de círculo alargado y siempre vamos moviéndonos en la sillas de un puesto a otro ayudando a quien lo necesite.

* Trabajos colaborativos en grandes proyectos.
Hay algunos proyectos que llevamos entre varias personas.  Así mejoramos la velocidad y disminuimos el riesgo por si alguno se pone malito o tiene algún compromiso.

* Trabajar en un entorno ágil en el que se valora el talento y las ideas de los miembros del equipo.
Hacemos standup dailies reales(menos de 15 min.), tenemos un buen sistema de integración continua, el testing está integrado en el equipo de desarrollo, vamos mejorando retrospectiva tras retrospectiva,… No hacemos SCRUM sino que es más parecido a FDD aunque hacemos entregas oficiales cada 3 semanas.

* Un puesto rotativo de desarrollo de pié para estirar de vez en cuando las piernas
En VSN cuidamos de tu salud. Si necesitas estirar las piernas puedes pasarte un rato a un puesto de desarrollo en el que podrás trabajar de pié y ver las cosas desde otro ángulo.

Experiencia:
3-5 años
Lo sentimos. No necesitamos un newby esta vez

Datos del Puesto:

* El candidato liderará la evolución del producto,siendo apoyado e instruido por un miembro del equipo de desarrollo actual, proponiendo mejoras a la arquitectura actual del sistema, así como las tecnologías y herramientas más apropiadas para la tarea.
Raro pero no tengo nada que añadir.

Nivel Profesional:
Empleado.
A cuenta ajena, claro.

Jornada:
Jornada completa (L-J 9:00-14:00  15:00 – 18:30, V-9:00 15:00)

Si vives cerca y prefieres y a comer allí podrás comer de 14 a 15:30 y después salir a las 19. El salir los viernes a las 15 es una PASADA…

Tipo de contrato:
Indefinido

Creo que ya hemos hablado de esto. Si ambas partes estamos contentas puede que te jubiles con nosotros, sea el que sea el lenguaje de programación que se use entonces.

Funciones:
Analista Programador – Programador

¡Ups!. Esto no me había dado cuenta, que fallo. Para mí el puesto es de DESARROLLADOR en mayúsculas. Olvídate de las funciones típicas. En VSN cortamos, pegamos y coloreamos todo lo que hace falta para sacar el producto con calidad.

Tecnología:
C++,Video, MultiHilo, Concurrencia, TCP/IP,Sockets,Windows,HTTP,Visual Studio,GIT,
Esperamos que no te asuste todo esto.

Si no lo ha hecho, saca brillo a tu currículum y envíamelo a jmuria en el dominio vsn.es. Tus propios compañeros lo leerán y colaborarán en tu selección.