Matriz de Competencias de Programación

La semana pasada, encontré una página interesante, describiendo:

Program Competency Matrix

El autor, Sijin Joseph, explica el origen de la matriz en su his post:

Habiendo trabajado con programadores con una extrema varianza en sus habilidades, algunas veces siento que hay un gran falta de buenos programadores, pero cuando pieson sobre eso un poco más, me doy cuenta que no hay un corte claro, algunos de los programadores tienen áreas fuertas y si uno los destina a las tarea en esas áreas fuertas ellos tienden a desenvolverse bien. Así que comencé a pensar acerca de cómo podemos evaluar a un programador, he aquí el resultado…

Como pueden ver en la página, la matriz tiene cuatro niveles repartidos en columnas, y filas agrupadas en categorías:

  • Ciencia de la Computación
  • Ingeniería de Software
  • Programación
  • Experiencia
  • Conocimiento

Me gusta toda la matriz, déjenme mostrar algunas de mis filas preferidas, sus niveles, y mi auto evaluación:

Conocimiento – Blogs

  1. Ha oído que existen pero no tiene tiempo para dedicarle.
  2. Lee blogs técnicos, de programación, de ingeniería de software y escucha podcasts regularmente.
  3. Mantiene un blog con artículos útiles y herramientas que ha ido coleccionando
  4. Mantiene un blog con opiniones personales y pensamientos sobre programación que comparte con los demás

Yo estoy cerca del 4.

Conocimiento – Libros

  1. La serie Unleashed series, aprenda en 21 d[ias, en 24 horas, la serie for dummies…
  2. Code Complete, Don’t Make me Think, Mastering Regular Expressions
  3. Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer, Mythical Man month
  4. Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, Art of Computer Programming, Database systems , de C. J Date, Thinking Forth, Little Schemer

Me faltan algunos libros, pero de nuevo, estoy más cerca de 4.

Conocimiento – Herramientas

  1. Limitado a IDEs primarias (VS.Net, Eclipse etc.)
  2. Conoce algunas alternativas a las herramientas populares.
  3. Buen conocimiento de editores, depuradores, IDEs, alternativas de código abierto, etc, etc. Por ejemplo, alguien que conoce muchas de las herramientas que lista Scott Hanselman en su lista de power tools. Ha usado herramientas de ORM (Object Relational Mapping).
  4. Ha escrito herramientas, scripts, gana puntos si fueron publicadas.

Bien, me veo entre 2 y 3, pero he escrito y publicado herramientas, así que también me siento cerca de 4.

Conocimiento - Conocimiento interno de la plataforma

  1. Cero conocimiento interno de la plataforma
  2. Tiene conocimientos básicos de cómo la plataforma trabaja internamente
  3. Profundo conocimiento del funcionamiento interno de la plataforma, puede visualizar cómo la plataforma toma un programa y lo convierte en código ejecutable.
  4. Ha escrito herramientas para mejorar o proveer la información sobre el funcionamiento interno de la plataforma. Por ejemplo, desensambladores, decompiladores, depuradores, etc.

Estoy en 3.

Experiencia - Años de experiencia profesional

  1. 1 año
  2. 2 a 5 años
  3. 6 a 9 años
  4. 10 o más años

Absolutamente en 4, pero creo que ya merezco otro nivel…. 30 años son un montón… :-)

Programación – Organización del árbol de código fuente

  1. Todo en una sola carpeta
  2. Separación básica de código en carpetas lógicas.
  3. Sin dependencias circulares, binarios, librerías, documentos, builds, código de terceras partes, todo organizado en sus carpetas
  4. Disposición física del árbol de código corresponde a la jerarquía lógica y a la organización del programa. Los nombres de directorios dan una idea del diseo del sistema.

Veo que estoy entre 3 y 4.

Programación – Organización del código en un archivo

  1. No hay evidencia de organización en el archivo
  2. Los métodos estan agrupados lógicamente o por accesibilidad
  3. Código es agrupado en regiones, bien comentado con referencias a otros archivos de código fuente
  4. El archivo tiene un encabezamiento con la licencia, un resumen, bien comentado, uso consistente de los espacios en blancos. El archivo se ve hermoso.

Hmmm…. Me pondría en 2.

Programación – Comunicación

  1. No puede expresar pensamientos/ideas a sus pares. Pobre ortografía y gramática.
  2. Los pares pueden entender lo que dice. Buen ortografía y gramática.
  3. Puede comunicarse efectivamente con sus pares
  4. Puede comprender y comunicar pensamientos/diseño/ideas/especificaciones de una manera no ambigua, y puede ajustar su comunicación según el contexto

Me gusta esta fila. Estoy cerca del 4 (en españo), me reparto en 1 y 2 en inglés hablado, y entre 2 y 3 en inglés escrito. El autor de la matriz comenta en esta fila:

Este es un criterio frecuentemente descuidado pero crítico para juzgar a un programador. Con el incremento del outsourcing en las tareas de programación a lugares donde el inglés no es la lengua nativa, este tema se ha vuelto más importante. Conozco varios proyectos que fallaron porque los programadores no pudieron entender cuál era la intencion de una comunicación….

Ciencia de la Computación – Programación de Sistemas (de base)

  1. No conoce qué es un compilador, enlazar o intérprete
  2. Conocimiento básico de compiladores, enlazadores, intérpretes. Entiende qué es un código de assembler, y cómo funcionan las cosas a nivel de hardware. Algún conocimiento de memoria virtual y paginado.
  3. Entiende las diferencias de modo kernel vs modo usuario, multi threading, primitivas de sincronización y cómo son implementadas, puede leer código de assembler. Entiende cómo funcionan las redes, entiende de protocolos de red y programación a nivel de sockets.
  4. Entiende toda la pila de programación, hardware (CPU + memoria + cache + interrupciones + microcódigo), código binario, assembly, enlazamiento estático y dinámico, compulación, interpretación, compilación JIT (Just In Time), recollección de basura (garbage collection), heap, stack, direccionamiento de memoria…..

Cuando escribí este artículo en inglés, me evalué en 3. Ahora pienso que estoy tranquilamente en 4.

Ingeniería de Software – Testeo automático

  1. Piensa que todo el testing es el trabajo del tester
  2. Ha escrito tests unitarios automáticos y arma buenos casos de tests unitarios para el código que escribe
  3. Ha escrito código a la manera de TDD (primero el test, luego el código)
  4. Entiende y es capaz de armar tests automáticos funcionales, de carga, de rendimiento y de interfaz de usuario

Estoy en 3, habiendo trabajado un poco en 4.

Bueno, hay muchas más filas a evaluar. Pero no es sólo importante evaluarnos cómo estamos hoy. Si Ud. se preocupa por la mejora continua, debe evaluar su nivel actual en cada fila, planear cómo incrementar cada nivel, aun en los que tiene 4, y revisitar esta evaluación regularmente. Busque ayuda en sus compañeros de trabajo, y en otros programadores. Pista: ocúpese de la fila con el nivel más bajo, primero.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com

This entry was posted in 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>