Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Mostrando entradas con la etiqueta trabajo. Mostrar todas las entradas
Mostrando entradas con la etiqueta trabajo. Mostrar todas las entradas
domingo, 13 de enero de 2008
Hace unos meses, el blog Inter-Sections publicó un interesante post donde el autor recogía las conclusiones obtenidas a partir de su experiencia desarrollando y seleccionando personal, respecto a cómo reconocer a los buenos desarrolladores.

Esta información, además, ha sido complementada con decenas de comentarios de lectores a raíz de su reciente aparición en Slashdot, convirtiéndose en un artículo muy recomendable para los que estamos en el mundo del desarrollo de software y vemos lo complicado que resulta a veces dar con las personas apropiadas. Y es que la contratación del personal adecuado es un factor clave para el éxito (y a veces supervivencia) en una empresa de software, cuya actividad se basa en gran medida en el talento de sus desarrolladores.

Los indicadores clave que, según Daniel, nos pueden ayudar a detectar a los buenos desarrolladores de software se agrupan en los siguientes puntos:
  1. son apasionados por el desarrollo
  2. son autodidactas y les encanta aprender
  3. son inteligentes
  4. normalmente tienen experiencia oculta
  5. son conocedores de tecnologías variadas y punteras
  6. por último, aporta lo que en su opinión no es en absoluto determinante: la titulación.
Estos se concretan en un resumen final de características positivas y negativas, casi un checklist, que nos podrían ayudar a detectar comportamientos y actitudes clave:

Indicadores Positivos (propios de los buenos desarrolladores)
  1. Apasionado por la tecnología
  2. Programa por hobby
  3. Capaz de hablar durante horas sobre temas técnicos si se le anima
  4. Lleva (y ha llevado) a cabo proyectos personales
  5. Aprende nuevas tecnologías por su cuenta
  6. Opina sobre las tecnologías apropiadas en cada caso
  7. Se siente poco cómodo usando tecnologías que no considera correctas
  8. Es claramente inteligente, se puede conversar con él de muchos temas
  9. Comenzó a programar mucho antes de ir a la universidad o empezar a trabajar
  10. Tiene "icebergs" ocultos, grandes proyectos y actividades personales que no aparecen en el currículum.
  11. Conoce gran variedad de tecnologías, que pueden no encontrarse reflejadas en el CV.

Indicadores Negativos (propios de los no tan buenos desarrolladores)
  1. Ve la programación simplemente como su trabajo
  2. No habla de programación fuera del trabajo
  3. Aprende nuevas tecnologías exclusivamente en cursos ofrecidos por la empresa
  4. Se siente cómodo con la tecnología que se les imponga, piensa que cualquiera es buena
  5. No parece ser muy inteligente
  6. Comenzó a programar en la universidad
  7. Toda su experiencia en programación está en su currículum
  8. Está centrado exclusivamente en una o dos tecnologías

En mi opinión, aunque la lista incluye puntos interesantes y acertados, y puede sernos útil como base para la reflexión, el tema creo que es mucho más complejo. Seguro que cada uno de nosotros podría matizar los puntos, eliminarlos o ampliar las listas, tal y como se pone de manifiesto en los comentarios del post, partiendo de nuestras propias experiencias y convicciones.

Por ejemplo, desde mi punto de vista, los indicadores positivos podríamos ampliarlos mucho; los buenos desarrolladores deben mostrar, aparte de las habilidades y actitudes ya citadas, otras comentadas por aquí hace tiempo como capacidad de comunicación e integración en equipos de trabajo, responsabilidad, compromiso, interés y cariño por el resultado de los productos que uno genera, habilidades literarias, curiosidad y seguro que un larguísimo etcétera. Además, pueden producirse falsos positivos; como muestra, decir que es bueno ser un apasionado del desarrollo, pero este hecho no garantiza el ser un gran desarrollador.

En el grupo de los indicadores negativos podríamos añadir, por ejemplo, los inversos de las características anteriores (incapacidad de hacerse responsable de algo, falta de cuidado en los resultados...), o matizar las recogidas por Daniel. Por ejemplo, estar centrado exclusivamente en una o dos tecnologías puede ser indicador de una gran especialización, o tener intereses y hobbies ajenos a la programación puede ser muy beneficioso para los profesionales que nos dedicamos a esto.

Y es que también hay que tener en cuenta que no es lo mismo ser un gran desarrollador en tu casa, como hobby, que serlo en una empresa. He conocido magníficos desarrolladores que según estos indicadores no parecerían pasar de la mediocridad, al igual que otros que aún cumpliendo la mayoría de los puntos positivos adolece de otras características, como habilidades de trabajo en equipo o actitudes elitistas, que lo hacen absolutamente inútil en una compañía de producción de software en el que tendrá que trabajar codo con codo con sus compañeros.

En cualquier caso, se trata siempre de características difíciles de percibir por la empresa vía el tradicional currículum y de ahí la necesidad de contar con medios complementarios como los blogs (sabéis que tengo la certeza de que los blogs ayudan a encontrar empleo), o realizar entrevistas y pruebas de nivel cada vez más complejas.

Publicado en: http://www.variablenotfound.com/.
miércoles, 19 de diciembre de 2007
Hace unos días me topé con los Diez Mandamientos del Abogado, el célebre decálogo formulado por el jurista uruguayo Eduardo J. Couture, donde se recogen una serie de normas éticas y de conducta que deberían guiar las acciones de estos profesionales.

Me llamó la atención porque muchas de estas líneas son totalmente aplicables a otros ámbitos y colectivos, y por supuesto al mundo del desarrollo de software, dado que contiene perlas como: "Estudia, puesto que el Derecho evoluciona constantemente", o "Piensa, puesto que el Derecho se aprende estudiando pero se ejerce pensando".

Sin embargo, el que me hizo reflexionar fue el décimo:

10. AMA TU PROFESION. Trata de considerar la abogacía de tal manera, que el día en que tu hijo te pida consejo sobre su destino, consideres un honor para ti proponerle que se haga abogado.

Y es que la pregunta es: ¿estamos tan satisfechos de nuestra profesión como para aconsejar a un hijo, al que se supone que debemos desearle lo mejor del mundo, dedicarse a ella?

No son pocos los profesionales del desarrollo de software que, bien por circunstancias laborales, personales, falta de vocación u otros motivos, reniegan continuamente, y a veces no sin razón, de este mundillo. Y es que con mucha frecuencia se trata de un trabajo mal pagado, muy duro, con horarios imposibles, estrés continuo, necesidad de actualización de conocimientos frecuente, y escaso reconocimiento social.

Así está el patio como está. Cada vez más gente que huye dando el salto a otras profesiones, las matrículas en informática por los suelos, los ingenieros en continua protesta (;-)) ... en fin, un panorama nada alentador para el futuro.

A pesar de esto, yo soy de los que estarían encantados de que alguno de mis hijos (hijas, en este caso) se dedicara al mundo del desarrollo de software, siempre, eso sí, que consiguieran apasionarse por ello. Nunca se la recomendaría como una salida profesional más, pues creo que al igual que es una dedicación fascinante para el que le gusta, estoy seguro de que debe ser una auténtica pesadilla para el que no disfrute creando software.

Probablemente dedicándose a esto no conseguirán nunca hacerse ricas, ni famosas, ni llegar todos los días pronto a casa... pero bueno, tampoco siendo médicos, ni abogados, ni taxistas. Y, en cambio, tendrían por delante una profesión (y muchas veces hobby) donde volcar toda su creatividad y talento, la satisfacción de la investigación y aprendizaje continuos, de crear software que ayuden a otros a trabajar, estudiar o pasar buenos ratos de ocio... en fin, un universo de posibilidades.

¿Y tú, recomendarías a tu hijo que se dedicara al mundo del desarrollo?

Publicado en: www.variablenotfound.com
domingo, 30 de septiembre de 2007
El otro día comentábamos en mi empresa que podría ser el momento de incorporar un nuevo desarrollador software en el equipo, de contratar a alguien. Esto, que puede resultar rutinario en grandes compañías, es para los que somos pequeños, un auténtico suplicio.

Experiencias anteriores nos han demostrado que los portales de empleo son útiles cuando se trata de ofertas muy específicas a la que acudirán pocos candidatos. Casos más genéricos, como podría ser la contratación de un desarrollador con cierta experiencia bajo unas condiciones aceptables, provocan una entrada masiva de candidatos que hacen de la selección un proceso imposible... ¿qué pequeña empresa puede preseleccionar con tino de entre una lista de cientos de personas, entrevistar físicamente a decenas de personas y encontrar a su candidato ideal?

Esta masificación es la que hace que tengan mayores probabilidades de éxito aquellos candidatos que destacan de alguna forma sobre el resto. Conocimientos técnicos, habilidades, actitudes... son muchas las características interesantes para las empresas, y algunas de ellas son difíciles de demostrar a priori, y más aún usando el habitual curriculum.

Y es justo aquí donde los blogs pueden jugar un papel fundamental. Si estás buscando empleo, se me ocurren al menos diez razones por las que deberías tener tu propio blog e incluirlo en tu currículum como un activo de alto interés:

1. Demuestras tus conocimientos.
Sí, es cierto que tu título debería hacerlo o al menos ser una pista, pero por desgracia no es así. El mero hecho de poseer una ingeniería, titulación técnica o haber realizado cursos específicos no implica un nivel de conocimientos determinado, pues la mayoría de las veces éste se adquiere con la experiencia o de forma autodidacta.

En un blog puedes demostrar tu nivel de conocimientos en los temas que tratas, tus especialidades, preferencias e inquietudes de forma mucho más directa, detallada y creíble de lo que puedes hacer con un currículum tradicional.

2. Demuestras tu facilidad de aprendizaje
Respecto a esto, siempre digo lo mismo: si piensas que vales lo que sabes, estás muy equivocado. Tus conocimientos de hoy no tienen mucho valor más allá de un par de años. Lo que vales es lo que puedes llegar a aprender, la facilidad con la que te adaptas a los cambios que esta profesión nos regala tan frecuentemente.

Tu blog puede demostrar que tienes una actitud positiva frente al aprendizaje.

3. Demuestras pasión por tu profesión
La pasión por tu profesión, por tu trabajo, esa característica tan demandada en el mundo empresarial, viene incluida casi de serie en el blogger. Resulta imposible imaginar a alguien al que no le guste el mundo del desarrollo de software escribiendo varios posts mensuales comentando las nuevas tecnologías que va descubriendo, trucos o cualquier tema relacionado con ello.

El simple hecho de tener un blog ya es un punto a tu favor.

4. Demuestras tu capacidad de trabajo
Un blogger, salvo excepciones (que seguro que hay), es un trabajador nato. Es importante tener en cuenta que cada post requiere un trabajo considerable, sobre todo cuando se genera contenido propio. Existen asimismo otras tareas, como la lectura de fuentes o la gestión de comentarios que pueden llegar a consumir mucho tiempo y esfuerzo. Esto, además, tiene mucho más mérito cuando se hace por gusto (véase el punto 3).

Obviamente, ser trabajador es una característica muy apreciada por la empresa, y tu blog te ayudará a demostrar que lo eres. ;-D

5. Demuestras rasgos importantes de tu personalidad
En cada post que escribes vas dejando un poco de tí mismo; consecuentemente, si sumas muchos de ellos seguro que podríamos unir tantos trocitos que habría información suficiente para psicoanalizarte en profundidad.

Las características personales de los candidatos son aspectos vitales en un proceso de selección. En el mundo del desarrollo, nadie va a contratar a personas conflictivas, violentas, de posturas radicales o de difícil encaje para el trabajo en equipo.

La imagen que transmites en tu blog puede ayudar a las empresas a hacerse una idea de cómo eres y de cómo no.

6. Demuestras tus habilidades literarias
Aunque a veces sea injustamente considerada la parte más tediosa y poco creativa de nuestra profesión, no olvidemos que una buena parte del trabajo de desarrollador consiste, a distintos niveles, en escribir textos. Pantallas, mensajes, ayudas, documentación de código, documentos técnicos, de diseño, análisis o propuestas son sólo algunos ejemplos de las tareas para las que hay que saber redactar apropiadamente. Las faltas de ortografía, o simplemente una redacción pobre en cualquier entregable, dan muy mala imagen de la persona y empresa que los generan.

Tu blog, aparte de ayudarte a cultivar estas virtudes, demuestra cómo podrías hacerlo en el desempeño de tus tareas como profesional, aportando un plus respecto al resto de candidatos que simplemente presentan un currículum.

7. Fortaleces y demuestras tu capacidad de comunicación
Un blog, aunque pueda parecer lo contrario, no es una herramienta de comunicación unidireccional, una palestra donde recitar monólogos: se escribe, se escucha, se debate, se critica, se comparten conocimientos y experiencia.

Ya en su momento, en el post "Entre 10 y 28 desarrolladores por el precio de uno" comenté que una de las características imprescindibles de un buen desarrollador es la capacidad comunicación bidireccional, pues repercute de forma muy positiva en la productividad del equipo de trabajo donde se ubique. Y, ¿qué es un blog sino un potente medio de comunicación?

Tu blog hace que te comuniques, y demuestra la facilidad que tienes para ello.

8. Demuestras tu experiencia, incluso si no la tienes
Está claro que nadie que busque su primer trabajo tiene experiencia; también es cierto que la experiencia es vital para encontrar empleo... ¿cómo salimos de este círculo sin fin?

Hay personas que sin haber salido todavía al mercado laboral, acumulan ya centenares de horas de vuelo. Suelen ocupar sus ratos libres en investigar, probar, aprender, y a veces pueden llegar a alcanzar niveles de dominio de una tecnología increíbles, y que serían muy valiosos en el mundo empresarial. El problema casi siempre es demostrarlo.

Tu blog puede demostrar la experiencia que tienes como desarrollador, independientemente de si has comenzado o no tu carrera profesional. Y si además participas en proyectos de software libre, mucho mejor.

9. Ganas prestigio
Lo mejor para conseguir un puesto de trabajo son, sin duda, las referencias y recomendaciones facilitadas por personas o entidades de confianza. Sin embargo, en un mundo 2.0 como éste, donde somos los usuarios de la red los que vamos aportando nuestro granito de arena a la inteligencia colectiva, no hay mejor aval que la credibilidad y fidelidad de cientos o miles de individuos repartidos por todo el mundo que, día a día, leen, comentan y citan nuestros posts.

Un blog con contenidos medianamente decentes se va haciendo, a la larga, un hueco en la red, aumentando el prestigio y autoridad de su autor.


10. Y sobre todo, destacar
Destacar sobre el resto de candidatos que, como tú, son ingenieros, técnicos, programadores estupendos o grandes expertos en lenguajes de última generación. Es la distinción lo que puede hacer que triunfes, y especialmente si acabas de terminar tus estudios, momento en el que se lanzan al mercado laboral decenas de jóvenes con currículums prácticamente idénticos.

Incluir el blog en tu currículum provocará, como mínimo, la curiosidad de los responsables de las primeras fases de una selección de personal, que probablemente acudirán a comprobar si eres el candidato apropiado.

En fin, espero que estas reflexiones puedan servir para algo; por un lado, motivar a aquellos que todavía no tienen blog para que se atrevan a empezar, y por otro, para animar a los que ya lo tienen y trabajan duro en él. En cualquier caso, tened por seguro que va a valer la pena.
lunes, 24 de septiembre de 2007
Hace unas semanas Miguel de Icaza publicaba en su blog personal un par de ejemplos del tipo de pruebas técnicas que realizan cuando contratan personal, en este caso para el proyecto Mono.

La filosofía es bastante simple, y la verdad es que no carece de sentido: los aspirantes reciben por correo electrónico el "enunciado" de la prueba, y disponen de dos semanas para responder. Aunque el tiempo de respuesta puede parecer excesivo, está pensado para ser realizado por los aspirantes cuando vuelven a casa tras sus jornadas de trabajo o estudio.

Según Miguel, esta técnica le da mejores resultados que las tradicionales entrevistas cara a cara, donde una lectura del currículum y varias preguntas rápidas no permiten conocer en profundidad al candidato. No hay nada como ver planteamientos y código para saber el tipo de desarrollador que tenemos delante.

La prueba para trabajar en el ámbito de Windows.Forms consistía en desarrollar un Control (Widget) y responder una pregunta, y decía más o menos esto (traducción libre):


Desarrollo de un control

Debes implementar un pequeño motor de renderizado para un lenguaje de marcas basado en XML. Este lenguaje acepta las siguientes etiquetas:

<p>...</p>, para definir el inicio y fin de párrafos.

Los párrafos pueden contener en su interior los siguientes tags:

  • <b>...</b>, para poner en negrita el texto
  • <i>...</i>, para poner el texto en cursiva

  • <link>...</link>, para que el texto sea renderizado como un hiperenlace.
  • <blink>...</blink> para que el texto parpadee
El control debe exponer la siguiente propiedad, que permitirá al desarrollador modificar el contenido (en este lenguaje de marcas) de forma programática.

  string Markup { get; set; }
 
Por ejemplo:

  m = new MarkupControl ();
m.Markup = "<p>Hello <b>World</b>!</p>";
 
El control también debe exponer un evento que permita notificar de los clicks del usuario sobre los enlaces (etiqueta <link>), algo así como:

  delegate void LinkClicked (object sender, string link_text);
 
De esta forma, será posible suscribirse al evento usando un código como el siguiente:

  m.LinkClicked += my_clicked;
...

void my_clicked (object sender, string link_text)
{
Console.WriteLine
("The link {0} was clicked", link_text);
}
 
Debes enviar una aplicación completa que se ejecute correctamente en Linux, y debe hacerse uso del evento y la propiedad citados con anterioridad. Por ejemplo, estaría bien tener algo como:

void my_clicked (object sender, string link_text)
{
Console.WriteLine ("Link {0} pulsado", link_text);
((MarkupControl) sender).Markup = "<p>Nuevo <b>texto</b></p>";
}
 
Puntos extra: al usar <blink> será necesario actualizar la vista, se valorará si se evita el parpadeo usando buffers dobles o repintando sólo el área modificada.

Quiero una pequeña y sucinta implementación, pero es tu oportunidad para demostrar que puedes escribir código robusto, así que impresióname.

Pregunta

En nuestra implementación de corlib, en System/DateTime.cs tenemos una implementación no óptima del método TryParse, básicamente invocamos a Parse dentro de un bloque try/catch.

Explica:
  • ¿Por qué digo que nuestra solución no es óptima?

  • ¿Qué debería tener para hacerla más eficiente?

  • ¿Por qué el desarrollador que escribió el código no realizó lo más eficiente?

La trick-question es: ¿por qué el proceso más rápido no se realizó en primer lugar? Explícalo.

¿Que os parece? ¿Podríais entrar a trabajar en el equipo de Mono?
jueves, 19 de julio de 2007
Hace tiempo ya, oí hablar sobre el libro The Mytical Man-Month, de Frederick P. Brooks, donde se asegura que los mejores programadores rinden hasta 10 veces más que los que se encuentran en el lado opuesto, los peores. Otras fuentes, como "Facts and Fallacies of Software Engineering" llegan a indicar que la diferencia puede ser incluso de 28 a 1.

Sin duda, la productividad en el desarrollo es algo más que tirar muchas líneas de código por día; ya lo comenta Charles Connell en su artículo It's not about lines of code, donde explica por qué la productividad no puede ser medida en esos términos, de hecho, ¿muchas líneas de código implican un trabajo bien hecho? ¿y si se trata de un nido de bugs?

Así, a lo largo de su artículo, Charles va definiendo y añadiendo características que debería presentar el código creado hasta llegar a una posible unidad de medida de la productividad, líneas de código limpio, simple, correcto y bien documentado por día, para finalmente llegar a la conclusión de que tampoco es del todo apropiado: ¿qué ocurre si un buen desarrollador es capaz de crear una función en 100 líneas de código perfecto y salir de la oficina a la hora habitual, mientras que otros realizan el mismo buen trabajo en 2000 líneas de código trabajando hasta altas horas de la madrugada? ¿quién es más productivo?

La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida. La ingeniería del software trata precisamente de eso, de aportar soluciones a los usuarios que usarán el sistema desarrollado, todo lo demás sobra. Sin embargo, como él mismo indica, es realmente difícil medir estas capacidades utilizando indicadores habituales como número de líneas de código, bugs provocados o tiempo de trabajo en la oficina.

Partiendo de esto, en "10 Developers For The Price Of One", Phil Haack, cuyo apellido seguro que lo predestinó a dedicarse a la informática, escribe sobre este tema centrando la medida de la productividad de los desarrolladores en torno al concepto TCO (Total Cost of Ownership), o Coste Total de Propiedad (CTO), e introduce algunas características propias de los buenos desarrolladores que hace que este factor sea óptimo.

La primera de ellas es la asunción de un proyecto como propio, la autosuficiencia en la resolución de problemas, tomar el control, resolver y asumir el avance del mismo como un objetivo personal. De esta forma se libera a los responsables de estar tan pendientes de estos aspectos y se recurre a ellos sólo cuando surgen problemas de entidad y con objeto de plantear una solución. Un desarrollador que escribe código rápido no es productivo, pues requiere de tiempo de los demás, y sobre todo, de aquellos que por sus responsabilidades disponen de menos tiempo.

La segunda hace referencia a la escritura de código con pocos errores. Un mal programador que escriba código muy rápidamente es un generador de bugs a una velocidad proporcional, lo que provocaría un mayor gasto de tiempo del equipo de testeo y control de calidad, así como del propio equipo de desarrollo en la corrección de los errores. Como comenta Phil, de nada vale ir rápido hacia la dirección equivocada.

En la tercera, se introduce el concepto de la creación de código mantenible. Y no sólo pensando en el mantenimiento futuro del software, sino durante el propio desarrollo inicial. Me ha gustado mucho su visión sobre esto, textualmente, Tan pronto como una línea de código sale de la pantalla y volvemos a ella, estamos en modo mantenimiento de la misma". Un código bien escrito, comprensible y limpio puede ahorrar mucho tiempo en el presente y futuro.

En cuarto lugar, comenta que los buenos desarrolladores hacen más con menos código, son capaces de identificar cuándo deben y cuándo no deben escribir software y utilizar componentes o elementos existentes. El reinvento de la rueda, no es beneficioso para nadie, y los buenos programadores suelen y deben esquivarlo.

Teniendo todos estos aspectos en cuenta, Phil retoma el concepto TCO indicando que todos estos factores son importantes a la hora de evaluar la productividad de un desarrollador en tanto en cuanto que influyen en el coste total de tener a un programador en la empresa, y no sólo fijándose en el coste directo que representa su nómina. Por ello asegura que intenta contratar, aunque no siempre lo consigue, al mejor desarrollador que encuentra en cada momento puesto que si es capaz de hacer más con menos código, escribir de forma inteligible, fácilmente mantenible y con menos errores, incrementará la productividad de sus compañeros, directivos y colegas. Por el contrario, un mal desarrollador puede disminuir la productividad de su entorno por los motivos anteriormente expuestos. Por este motivo puede justificarse la relación de 28 a 1 en la productividad entre unos y otros.

Estoy absolutamente de acuerdo con estas apreciaciones, un desarrollador no puede ser evaluado únicamente teniendo en cuenta aspectos cuantitativos como la cantidad de líneas de código que es capaz de generar: si lo que buscas es velocidad a la hora de teclear, contrata a un mecanógrafo, leche. Y aunque para cerrar un proyecto hace falta escribir líneas, tanto o más importante es la calidad con que esto se haga o tener capacidad para decidir cuándo hay que reutilizar en vez de escribir.

Quizás, por poner alguna pega, echo en falta un par de factores que a mi entender son fundamentales para aumentar la productividad en el desarrollo, y están relacionadas con la visión global introducida en el artículo citado anteriomente.

En primer lugar, la capacidad de comunicación bidireccional, es decir, ser tanto capaz de entender los mensajes de los usuarios, de analistas, comerciales o cualquier otro grupo de interés, como transmitir claramente mensajes, problemas o cuestiones siempre adaptándose a su interlocutor. Esta es, en mi opinión, una habilidad difícil de encontrar y que puede repercutir de forma muy negativa en la productividad global de un equipo de trabajo. ¿Quién no ha tenido que desechar código por culpa de un malentendido?

En segundo lugar, es fundamental la facilidad de integración en equipos de trabajo. Los desarrolladores trabajando en islas son difíciles de ver, la complejidad del software actual hace que en casi cualquier proyecto tengan que intervenir varias personas colaborando de forma muy estrecha. Además, en una máquina perfecta de producción de software la información y conocimientos fluyen con facilidad, lo cual influye en la productividad de cada uno de los componentes de la misma.

Curiosamente, ninguna de estas dos habilidades son técnicas... Sin duda esto de la productividad es un tema tan interesante como complejo, ¿eh?

miércoles, 28 de febrero de 2007
Vía el magnífico Coding Horror he encontrado un interesante post en el que se comenta algo tan curioso como increíble: durante entrevistas de trabajo para cubrir vacantes de puestos de programación, se constata que la inmensa mayoría de los candidatos no son capaces de codificar ni los programas más simples.

Habitualmente se trata de personas con titulaciones medias o superiores, cierta experiencia previa y un conocimiento de tecnologías de programación, al menos en teoría, relativamente alto, perfectamente capaces de mantener una conversación sin soltar barbaridades destacables.

Y lo más increíble de todo es una de las técnicas que usan para "filtrar" el personal en las entrevistas de selección: el "test FizzBuzz". La prueba consiste en solicitar a los candidatos:

Escribir un programa que imprima los números del 1 al 100. Sin embargo, hacer que en los múltiplos de tres se imprima la palabra "Fizz" en vez del propio número, y en los múltiplos de cinco se imprima "Buzz". Para aquellos números múltiplos de tres y cinco simultáneamente, se debe imprimir "FizzBuzz".

Si piensas que esta prueba es una chorrada, atento a las conclusiones que sacan los que la han puesto en práctica. La mayoría de los graduados, ingenieros, diplomados en informática no pueden hacerlo. Incluso muchos auto-proclamados programadores expertos tardan más de diez minutos en escribir una solución.

No sé si se trata de una exageración, pero en realidad se toca un tema muy espinoso y cierto como la vida misma: la falta de preparación de los futuros (y algunos actuales) programadores.

Y está claro que una de las medidas a tomar, desde el punto de vista de una empresa, es reforzar las pruebas y criterios de selección de su personal. No sé si el "FizzBuzz" es la solución, pero sin duda es un buen ejemplo: intentar conocer al candidato, sus habilidades y limitaciones básicas puede ayudar a descartar tarugos que pululan por el ciberespacio y han anidado masivamente en sitios web de ofertas de empleo. De esta forma, se evitará que entren en casa.

Pero el origen del problema es anterior a todo esto. ¿Qué se está enseñando en los centros de formación? ¿Qué nivel se exige a los estudiantes? ¿Existe todavía vocación en esta profesión?

Preocupante, ¿no?
viernes, 24 de noviembre de 2006
Pues eso, ya estoy aquí. Después de una estancia en territorio Marroquí de cinco días, he tenido la ocasión de saborear la enorme alegría de volver a casa. Y es que todos estos viajes acaban resumiéndose en una palabra: "Paliza".

Desde el punto de vista profesional, un éxito. Se han cerrado aspectos de vital importancia para el proyecto, y se han creado nuevos vínculos con el personal "de allí", fundamental para poder continuar trabajando juntos y de forma coordinada.

Durante estos cinco días hemos estado en Casablanca, Kenitra, y Tánger. Las jornadas de reuniones eran amplias, lo cual no ha permitido dedicar mucho tiempo a hacer turismo, sólo una tarde-noche, que nos hemos acercado a un mercado (zoco) en Rabat, la capital del reino, donde hemos podido disfrutar el ambiente mercantil de estos lugares y comprar algunos detallitos.

La opinión del país con la que me he ido es diferente a la que tenía antes de visitarlo, formada únicamente por tópicos y comentarios puntuales de conocidos que habían pasado allí algunos días de vacaciones. Aunque sí, es cierto que las diarreas han tenido su protagonismo en la visita, que hay mucha pobreza y se persigue bastante al forastero con objeto de sacarte algunas perrillas, y que la conducción es en general muy temeraria, pero no es menos cierto es que los marroquíes resultan muy acogedores, con una gran simpatía y educación, y se esfuerzan enormemente en agradar al visitante, que la comida es muy buena, y que las ciudades (al menos las grandes) son muy parecidas a las occidentales.

En fin, ahora toca dormir como un oso, que el fin de semana es corto.
Nos vemos.
domingo, 19 de noviembre de 2006
Ahora sí que me voy. Todo está listo: maleta como para cinco días, portátil repleto de software y tareas pendientes, y mi carpeta marrón de documentación relacionada con el proyecto que tan gentilmente me lleva de excursión.

Sólo me falta por cerrar el transporte desde casa hasta el punto donde estoy citado con el resto de componentes de la visita, que habrá de ser en taxi, y tendré que llamarlo mañana un rato antes de salir.

Nos vemos a la vuelta (¿esto no lo he dicho ya antes?)
miércoles, 15 de noviembre de 2006
Pero no, no vengo de Marruecos. Al final se canceló el viaje, y la salida está programada para el próximo lunes 20 de Noviembre.

De momento acabo de librarme de atravesar el estrecho con un temporal de narices, climatológicamente hablando. Todo un alivio para alguien al que no suelen sentar demasiado bien los viajes movidos.

En los pronósticos para el lunes hay diversidad de opiniones, aunque parece que son más los que estiman que será un día nuboso, aunque no apunta lluvia. Todo se verá.
domingo, 12 de noviembre de 2006
Pues parece ser que el próximo miércoles salgo para Marruecos en misión especial.

Asistiré a una serie de reuniones técnicas donde se decidirá el juego de datos, los procedimientos y los formatos de intercambio de información entre dos sistemas informáticos que están siendo desarrollados, uno por parte del cliente al que representaré en las reuniones y otro por parte de las autoridades Marroquíes. Seguro que va a ser divertido: no hablo nada de Francés y supongo que ellos tampoco hablarán castellano, así que tendremos que recurrir a intérpretes (humanos) o, si se dejan, intentaremos comunicarnos en inglés, en c#, java o como sea.

En cuanto al viaje en sí, la verdad es que a priori no es un lugar por el que sienta especial interés. De hecho, ni siquiera aparecería en mi imaginaria lista de sitios a los que querría ir en vacaciones. Esto hace que sienta cierta inquietud ante la excursión, que supongo que estará motivada por mi desconocimiento total sobre la zona. En otras ocasiones en las que, también por trabajo, he salido del país a Portugal, Holanda o el Reino Unido, más o menos sabía a donde me dirigía; en este caso, sin embargo, no tengo ni idea de cómo será aquello.

En fin, vamos a darle una oportunidad al reino vecino. A la vuelta contaré lo que me ha parecido.

Hasta entonces.