Competencias de un desarrollador de software

Agustín Ramos
Jul 25, 2017 · 11 min read

TL;DR

Hace algunos años creé un framework conceptual cuyo objetivo es servir como guía para la adquisición y evaluación de competencias de desarrolladores de software, ya sea de manera individual o por equipos/proyectos. En aquel entonces lo cree para resolver un problema específico en mi trabajo. Aún está incompleto y definitivamente ahora le cambiaría varias cosas, sin embargo, comentarios que me han hecho algunos amigos me hacen pensar que vale la pena publicarlo para que lo pueda usar quien le convenga, pero también para que me ayuden a completarlo y refinarlo.

Todo tiene una historia

Y esta comenzó hace casi exactamente N años, cuando me incorporé a trabajar en una nueva organización y me encargaron la tarea de liderear 10 (diez) equipos de desarrollo en la adquisición de métodos y prácticas que los hicieran más efectivos y eficientes (o menos malos, dependiendo de la interpretación). El contexto es que todos estos equipos desarrollaban en un lenguaje fuertemente criticado en la industria, sin uso de frameworks, sin hacer pruebas, sin automatizar nada, sin ambientes controlados, sin objetivos y alcances bien definidos… descalzos pues, usando uñas, dientes y un garrote, sobreviviendo un día a la vez.

Vida prehistórica, con todo respeto

Además tenían feos hábitos como el no tener todo el código en repositorios (había casos donde el código en el repositorio difería mucho del que estaba en producción, y llevaban mucho tiempo así), hacer experimentos o probar bug-fixes directo en los ambientes de producción (no había control de acceso), tener todas las IP’s hard-coded en el código y un muy largo etcétera. En resumen: si me nombrabas cualquier “pecado” de un desarrollador de software, te podía señalar varias ocurrencias en ese mismo lugar.

El por qué acepté un trabajo así, es otra historia; dejémoslo en que los meses anteriores la pasé MUY bien y aún si después me hubieran encadenado un tiempo a trabajar en minas de carbón, valió la pena.

Rodando por Creta

Algo viejo, algo nuevo, algo prestado, algo azul

Estaba entonces ahí, con aproximadamente 35 chicos mirándome con cara de “¿y tú qué?”, mientras repetía en mi cabeza: ¿cómo le hago?, ¿cómo #@%! le hago?

Y es que no es lo mismo enseñarle a alguien que está comenzando su carrera que hacerlo con alguien que ya tiene tantos vicios arraigados a su manera de trabajar diariamente. Y tampoco es lo mismo explicarle por ejemplo, cómo hacer integración continua a alguien que ya tiene la costumbre de hacer pruebas unitarias y usa una herramienta de build, que explicárselo a alguien que copia código fuente por FTP al ambiente de producción para ver el resultado de sus “printf” que metió para diagnosticar un bug.

Después de 1 par de días de darle vueltas, mientras revisaba el material de apoyo que había usado varias otras veces para guiar a distintos equipos en distintas prácticas, recordé un viejo post en alemán (que eventualmente evolucionó a un sitio) con el que había simpatizado mucho y que cuando conocí su propuesta, la quise adoptar en los equipos con los que trabajaba, pero la dirección de aquella empresa solo me dio el avión y no pasó nada. El post proponía un sistema compuesto por un pequeño conjunto de prácticas y principios organizados en 7 niveles progresivos para definir lo que significa ser un desarrollador profesional de software.

Me di cuenta que por un lado, la idea servía para sistematizar en niveles las competencias esperadas de un desarrollador, por otro, había ciertos tipos de competencia que no estaban considerados y me parecían muy importantes, y por último, para poder usar un sistema similar con los 10 equipos que estaba trabajando, iba a tener que ser mucho más detallado y específico al comunicárselos y ser su mentor en su proceso de transformación. Así que comencé a crear una matriz que sirviera como mapa de todas las competencias que consideraba relevantes, organizadas por disciplinas (esto fue de mi cosecha) y niveles. También fui creando documentos con guías que describen brevemente de que trata cada competencia y referencias a materiales más detallados. Después de algunas iteraciones, llegué a …

El framework

Se compone de distintos principios y prácticas (P&P) que puedes aplicar en el desarrollo de software, y están agrupados por disciplinas y separados en 5 niveles, identificados con distintos colores. Entre mayor el nivel, por lo general puedes esperar que sean más complejos los P&P o que requieran que domines los del nivel anterior, pero hay algunos casos donde temas de igual complejidad y sin dependencias entre sí están separados en distintos niveles. Esto es así para no saturar de contenido un nivel en particular, por lo que en estos casos seleccioné los P&P que me parecieron más importantes y esos los dejé en el nivel más básico, moviendo los otros a niveles superiores.

Esta es la matriz que resume el framework:

Competencias de un Desarrollador de Software

Aquí lo puedes apreciar con mejor detalle, y dentro podrás encontrar ligas a un documento donde existen descripciones de los criterios para definir si se tiene esa competencia o no, así como referencias a libros, blog-posts y videos que recomiendo para cada tema.

La idea de dividirlo en 5 niveles (y no en 7), la tomé de una herramienta conceptual que conocí en los años en los que los métodos ágiles se pusieron muy de moda y que me ha servido muy bien desde entonces: el modelo de Dreyfus.

Dreyfus

El modelo de Dreyfus sirve para evaluar el nivel de competencia de un individuo en cierto tipo de habilidad particular. En este modelo (basado en investigaciones de campo y el análisis de sus resultados, es decir, no es pura filosofía), se propone que para dominar cualquier habilidad no trivial, se atraviesa por 5 etapas que no son tan graduales como esperaríamos, sino que en cada una surgen nuevas maneras en las que se perciben y abordan los problemas relacionados con la habilidad en cuestión.

Las 5 etapas del modelo de Dreyfus

Una de las mejores características de este modelo, es que se aplica de manera granular a cada tipo de habilidad que se quiera evaluar. Esto nos permite tener una mejor foto de qué significa ser un novato o un experto, ya que por lo general nadie tiene el mismo nivel de competencia en un conjunto de habilidades dado. No hay expertos en todo.

Regresando a nuestro framework, ahora tenemos un marco conceptual para decir, por ejemplo, que El Coyote ha mostrado ser competente en diseño pero un completo novato tanto en pruebas como en hacer releases. Pobre Coyote.

Pobre Coyote, nadie le ha dicho en qué está fallando y todo lo atribuye a su “mala suerte”.

La aplicación que hago del modelo de Dreyfus al definir la matriz no es rigurosa, porque de hacerlo no deberíamos, por ejemplo, prescribir prácticas específicas en el nivel 5 (Experto), ya que según el modelo, un experto ya no trabaja en base a reglas o prácticas, sino tiene su propia visión de cómo hacer las cosas y la mayoría de las veces actúa por la intuición generada por toda la experiencia y conocimientos que ha acumulado y (según la literatura) a veces incluso es incapaz de comunicar como llegó a cierta conclusión o decisión, aunque éstas sean correctas. Sin embargo, yo no concuerdo completamente con esta visión de cómo funciona un experto, ya que creo que siempre debes poder explicar a otros cómo se llega a una conclusión, aunque tú lo hagas casi en automático.

Por otro lado, una manera en que sí se puede aplicar el modelo de manera directa es al evaluar qué tan bien se ha adoptado cierta práctica o principio propuesta en el framework. Esto te permite saber dónde estás y/o que tanto has avanzado en cuanto a dominar cada una de las P&P. Por ejemplo, si tomamos “Diseño orientado a componentes” podemos evaluar qué nivel de competencia tiene una persona en ese tema. Un novato podrá entender el vocabulario, y algunas reglas simples como “usa siempre la interfaz del módulo, no la implementación”. Alguien profesional (mi traducción de proficient) entenderá principios de diseño sobre cómo separar la funcionalidad en distintos módulos, y cuando se encuentre un mal diseño podrá evaluarlo con argumentos sólidos y podrá dar indicaciones de cómo puede arreglarse. Cuando llegue un hype-driven-developer (blufferos, les dicen) con su rollo de que una arquitectura de micro-servicios resuelve todo, un profesional le va a preguntar cosas como ¿y eso de fondo en qué es similar/diferente de SOA? ¿con qué criterio separas la funcionalidad de un monolito en micro-servicios? ¿y eso qué complicaciones “escondidas” trae y en qué otras cosas impacta?, etc. Un experto, va a poder responder adecuadamente todo eso (si tiene sentido responderlo), te va a poder contar sobre varias otras alternativas y métodos de como descomponer un sistema en módulos y además posiblemente te va a salir de repente con una definición de módulo y un nuevo método para diseñarlos del que nunca habías escuchado (posiblemente él se lo inventó), además te va a decir en qué casos te conviene aplicarlos.

¿Qué le falla?

Te puedo decir que estoy consciente que el framework presenta varios problemas, a saber:

Está incompleto. Esto es en primer lugar porque no me he dado el tiempo de escribir un detalle y referencias mínimos de todas las P&P. Por otro lado, en estos años han madurado algunas nuevas que definitivamente debería considerar en incorporar.

Es un tanto arbitrario. Ya que está basado únicamente en mi conocimiento y experiencia sobre qué cosas verdaderamente funcionan. Sería mejor si fuera un esfuerzo colectivo incorporando el conocimiento y opiniones de otros desarrolladores experimentados.

No cumple con el principio Single Level of Abstraction. Este es un problema que no supe resolver sin agregar mucha complejidad al framework. Tomemos por ejemplo la práctica de “Diseño orientado a componentes”. Esto tema es un mundo en sí mismo, ya que hay muchas técnicas para descomponer un sistema en componentes, dependiendo de tu contexto y experiencia puedes conocer lo básico o varias técnicas y métodos. Pero al mismo tiempo en la matriz hay elementos como el “Principio de Responsabilidad Única” que es mucho más específico y acotado, además de mucho más básico. Tampoco me hace sentido especificar todas las técnicas y métodos exitosos que hay para diseñar componentes/módulos y asignarlas a distintos niveles porque la aplicación de cada una depende mucho de tu propia formación y experiencia.

Con todo esto, creo que el framework puede ser útil.

¿Cómo usarlo?

En primer lugar el framework se puede utilizar para auto-evaluarse a nivel individual, por equipo, o incluso a nivel proyecto, y en base a esto plantear una estrategia para ir cubriendo y mejorando distintas habilidades.

Es obvio que también se puede utilizar en organizaciones de tamaño mediano a grande como referencia para establecer un programa de mejora en métodos y prácticas de desarrollo, aunque aún en éste caso hace sentido que el seguimiento sea por equipo o proyecto.

Algo que debes tomar en cuenta es que, en su versión actual, el framework puede contener P&P que no son aplicables al contexto de donde estás trabajando. Por ejemplo hay algunos principios que solo aplican bien a lenguajes y diseño orientados a objetos, pero no a funcionales.

El proceso de usarlo sería más o menos el siguiente:

  • Realizar una auto-evaluación de cada una de las P&P, utilizando el modelo de Dreyfus. Si la evaluación es auxiliada por alguien que domine esa disciplina, es mucho mejor, ya que entonces la evaluación no estará tan sesgada.
  • Plantearse objetivos de mejora para el siguiente o los siguientes periodos de revisión. Un objetivo podría ser mejorar o incluso adquirir cierta práctica o principio. No puedes plantearte ser experto en algo de un día para otro. Utiliza el modelo de Dreyfus como guía. Los periodos pueden ser iteraciones, releases, meses, semanas, etc. dependiendo de la manera en que el grupo actualmente utiliza para hacer revisiones (si es que las hay). Es muy importante plantear objetivos viables, que el equipo o persona esté convencido que se pueden lograr considerando todos los otros factores que están alrededor del trabajo en curso.
  • Hazlo parte de tu trabajo normal. Para que realmente suceda, todas las partes involucradas tienen que ser conscientes que se tiene que dedicar tiempo a estudiar, discutir y aplicar cada P&P. No va a ocurrir solo porque se dijo que se quiere que ocurra. Dado que es algo que no está considerado en la forma existente de trabajo, particularmente en las fases iniciales será necesario apartar tiempo explícitamente para esto.
  • Apóyate de mentores en cada tema. Todo es más fácil con la guía que tiene experiencia en un tema dado. Si no lo hay, no es impedimento, pero hay que estar conscientes que habrá situaciones donde surjan dudas y en primera instancia ninguna respuesta que aporte el equipo será suficientemente convincente. En esos casos atrévete a experimentar y sacar tus propias conclusiones, pero no dejes de buscar activamente con quien validar tus ideas y resultados.

Lo más importante a tomar en cuenta es que este framework es solo una guía para crecer y mejorar como desarrolladores de software, no un sistema de mandamientos. Por esta misma razón, bajo ninguna circunstancia debería ser utilizado como un mecanismo para penalizar a una persona o equipo.

¿Quieres ayudar?

A medida que explores el framework notarás que la mayoría de los P&P no están detallados. Esto fue porque después de generar esta versión, como se dieron las cosas en mi trabajo de aquel entonces, ya no me dieron tiempo de completar la documentación, que se sustituyó por pláticas y talleres específicos a distintos temas. Después me involucré en otros proyectos que me quitaron recursos para documentar y la gente optó por preguntarme directamente cuando tenía alguna duda.

La idea de abrirlo públicamente es precisamente la de que lo pueda usar quien lo vea útil y que de igual manera pueda participar en completarlo.

Las formas en las que esperaría ayuda son:

  1. Retroalimentación de cualquier parte/aspecto del framework.
  2. Mover todo a un sistema de colaboración y publicación más adecuado.
  3. Actualizar la matriz. Quitar cosas que no sean tan relevantes o sean ambiguas y agregar cosas que en estos 3 años han hemos visto que son de verdadera importancia. Todo este tipo de modificaciones deberíamos estar abiertos a discutirlas de manera constructiva.
  4. Completar/mejorar las descripciones de cada práctica y sus referencias.
  5. Introducirlo a tu equipo/organización y darnos retroalimentación sobre cómo es recibido y su efectividad al aplicarlo.

Respecto al punto 2, definitivamente creo que hay que mover el contenido de texto a un wiki o sistema similar y tenerlo versionado en un repositorio, pero respecto a la matriz tengo mis dudas de que el lugar conveniente para tenerla sea una matriz en Markdown o algo similar. Se aceptan propuestas en cualquiera de estos temas.

Conclusiones

Ser un buen desarrollador de software no es fácil. Es un camino largo, lleno de situaciones inesperadas, aciertos, tropiezos, oportunidades y vaivenes. Tener una guía sobre qué competencias son relevantes y en qué orden irlas adquiriendo parece no ser mala idea.

Si llegaste hasta aquí lo más probable es que estos temas sean importantes para ti y de verdad espero mucho tus comentarios y retroalimentación :)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade