Aptitudes que un programador profesional debe desarrollar

Alejandro De Luca
Mar 10, 2016 · 9 min read

A partir de la experiencia de trabajar en el área de desarrollo y, especialmente con desarrolladores nóveles, he descubierto ciertas características en común que suelen tener.

Hay mucho talento y potencial. También muchas aptitudes a mejorar. Algunas son técnicas y se aprenderán a lo largo del tiempo ya sea de una institución como puede ser la universidad, a través de la experiencia en un empleo o dejando fluir la curiosidad innata que todos tenemos.

Sin embargo, hay otro tipo de aptitudes que van más allá de lo técnico y que deben incorporarse de a poco. Son las que en definitiva terminan marcando la diferencia entre un desarrollador profesional y un aficionado.

A medida que los vayan leyendo, verán que muchas de estas aptitudes van más allá del trabajo en desarrollo y que pueden aplicarse no sólo a otras áreas de sistemas, sino también a cualquier otro tipo de empleo.

Comencemos.

Autonomía

La autonomía implica la no dependencia de otro colega para realizar las tareas asignadas. Son los programadores junior los que suelen tener este inconveniente, debido a la falta de experiencia y conocimientos técnicos.

La dependencia puede estar dada por carencia de conocimientos técnicos o de los procesos vinculados al desarrollo o incluso de las herramientas que se utilizan, pero también por falta de confianza en la resolución de las tareas.

Solo la experiencia puede dar autonomía a un programador. No obstante se puede acelerar. Esto puede lograrse asignándole responsabilidades y brindándole confianza. No se puede esperar que alguien se maneje solo si no se le da la oportunidad de hacerlo.

Responsabilidad en la entrega

Una entrega puede ser la realización de una tarea simple como tocar una sola línea de código. O también puede ser la realización de todo un proyecto complejo. El receptor del trabajo puede ser un colega, un superior o un cliente.

La responsabilidad en la entrega comienza con el cuidadoso análisis de los requerimientos, el enfoque para resolver el problema en sí mismo, la codificación de la solución y el esquema de pruebas al que se la somete.

Respecto al último asunto, el nivel de exigencia de las pruebas puede variar según el receptor de la entrega. Si se trata de un colega, las pruebas deben cubrir un mínimo requerido de intensidad y si es posible ser automatizadas y acompañarse con el código. Si se trata de un superior, a todo esto debiera sumarse un poco más de esfuerzo y tiempo.

Cuando el receptor es el cliente final, las pruebas deben ser completas y la exigencia, máxima. Deben contemplarse las principales alternativas y deben probarse cada una de ellas (de ser posible) para ver, en efecto, que suceda lo esperado.

En ningún caso puede realizarse una entrega sin poner a prueba el trabajo realizado.

La forma más fácil de reducir los problemas en la solución es resolver el problema a conciencia. Es decir, sabiendo que se está realizando el trabajo adecuado, con el esfuerzo intelectual que requiere, respetando los estándares y teniendo en cuenta la extensión de la aplicación.

En otras palabras, no resolver el problema de forma inadecuada para ahorrar tiempo o esfuerzo, sabiendo que esto puede traer problemas a futuro en el corto o largo plazo.

Proactividad

Esta característica se vincula con la capacidad de autoasignarse responsabilidades. De no depender de otra persona para poner manos a la obra.

Un programador proactivo se manifiesta reclamando tareas cuando se encuentra ocioso. Pero también lo hace cuando propone nuevas estrategias para resolver los problemas, cuestiona procesos de desarrollo, o asume con su propia visión la responsabilidad de mejorar el producto.

La comunicación es un elemento clave en la proactividad. El programador proactivo necesita comunicarse con los demás miembros del equipo para proponer algo nuevo o para asignarse tareas. Pero también con el usuario del sistema o el product owner, para responder inquietudes sobre cómo debe ser el producto que está desarrollando.

Es por esto que las personas más desenvueltas, sociables y con un nivel de timidez mínimo tienen un punto a favor en cuanto a proactividad.

En síntesis, un programador proactivo nunca va a estar sin nada para hacer. Siempre encontrará una tarea para asignarse.

Autoeducación

Me gusta definir autoeducación como el proceso que ocurre en el medio entre recibir una tarea cuya resolución es completamente desconocida y la resolución de la misma.

No se pueden dominar absolutamente todos los conocimientos técnicos. Pero se puede desarrollar la capacidad para adquirirlos de forma rápida. El conocimiento está ahí, en internet. Es cuestión de aprender a asimilarlo por propia cuenta, sin necesidad de otras personas, cursos, profesores o de instituciones educativas.

El dominio del idioma inglés es fundamental para abrir el abanico de opciones y tener un volumen de información mucho mayor para poder leer y procesar.

Para poder desarrollar esta veta autodidacta se necesita tener previamente suficiente autonomía. Hay que atravesar la experiencia de no tener la respuesta a un problema durante horas, días, semanas… Para luego, investigando, encontrarla, sin necesidad de recurrir a nadie. Este tipo de experiencias templa el espíritu de autoaprendizaje que todos llevamos dentro.

A veces es mejor descubrir la solución por cuenta propia.

Lo más importante de la autoeducación es entender que no termina nunca. Siempre hay algo nuevo por aprender. El momento en que un programador cree que ya aprendió todo lo necesario, ese es el momento en que perdió la capacidad de auto enseñarse.

No hay que aferrarse a ninguna tecnología por comodidad. La tecnología avanza todos los días y lo que se está usando en este momento puede que sea historia antigua el año que viene. Este es uno de los mayores defectos de los viejos programadores que prefieren morir abrazados a COBOL, PASCAL, Fortran o RPG.

Hay que adaptarse. ¿Cómo? Estudiando continuamente lo que viene, siguiendo de cerca a los profesionales que están en la vanguardia.

Referido a este punto se encuentra uno de los problemas que tienen las universidades. Siempre corren de atrás a las últimas tecnologías. No llegan a tiempo para cambiar los programas de enseñanza. Por eso, no queda más remedio para el programador que capacitarse por cuenta propia.

Orden

Nos referimos a la organización interna. La administración de las tareas y el tiempo que un programador dispone para realizarlas.

Un programador debe saber bien en qué punto del proyecto se encuentra en cuanto a plazos. Debe tener asignadas en su mente una serie de tareas con prioridad, que van más allá de la metodología con que se trabaje.

Y vinculado a la metodología, por supuesto que debe respetarla, puesto que es la forma de comunicar con el resto del equipo el estado de las tareas que tiene asignadas.

Todo esto, que puede llamarse “orden interno” no es suficiente. El orden debe ser transparente y poder percibirse desde afuera. Esto da visibilidad sobre el proyecto a los profesionales que lo administran.

El orden también otorga velocidad. Cuando uno no tiene que pensar cuál es el siguiente paso a realizar, ahorra tiempo y gana en dinamismo.

Apertura mental

La apertura mental está ligada a la capacidad de aceptar cambios, adaptarse, comprender que las cosas pueden no ser como uno siempre las espera. Y que muchas veces las tareas pueden realizarse de distinta forma, incluso con otras herramientas.

En este ítem entran las estúpidas guerras de sistemas operativos o de lenguajes de programación. Se pueden encontrar extensos hilos en foros de debate sobre esto. Donde alguien intenta decir que una herramienta es mejor que otra.

¿Es acaso mejor un tenedor que una cuchara? Comparar distintos tipos de herramientas es para mediocres de mente cerrada. Un programador profesional (o cualquier profesional de sistemas) debe comprender esto.

Puede haber gustos y bromas al respecto, pero creer realmente que la herramienta que uno domina es mejor que otra sólo refleja soberbia y elitismo.

El elitismo aísla y no permite el trabajo en equipo. Confina en la soledad más profunda el potencial de un individuo e impide la sinergia de los grupos de trabajo. Nadie quiere a un sabelotodo en su equipo.

La humildad es la contracara de la soberbia. La capacidad para admitir errores y aprender de ellos. Reconocer que las cosas se pueden hacer de otro modo.

Podemos aprender de nuestros errores, pero también de los de los demás. Es por eso que hay que estar abierto a la comunidad de desarrolladores. A todas ellas, sin menospreciar a ninguna.

Enfoque en resolución de problemas y análisis lógico

Muchos podrán pensar que esta característica es parte del conjunto de cualidades técnicas que un programador incorpora. Pero yo lo veo mucho más allá. Casi como una forma de vida.

Hay personas que son prácticas, que resuelven problemas, que avanzan y que obtienen resultados, aunque a veces no sean los mejores. Después hay otras, que se diluyen al encarar un problema, que se van por las ramas, que divergen.

El principio de la Navaja de Ockham resume este ítem. En igualdad de condiciones, la explicación más sencilla suele ser la correcta. No constituye una ley absoluta, pero si es una buena idea para tener presente a la hora de resolver problemas.

El análisis lógico surge de seguir con lógica o simplemente con sentido común el camino desde la identificación del error hacia qué lo provoca y luego hacia una solución efectiva.

Creatividad

Todo sistema comienza en una hoja en blanco. Hay necesidades y requerimientos. A partir de ellos se trazan diagramas, que luego se convierten en código de programación. Partimos de la nada y llegamos a algo concreto. Creamos.

La creatividad aparece en el proceso de construcción. Se manifiesta claramente al hacer diseños y diagramas previos a la codificación. También al plantear la resolución de un problema con distintos algoritmos.

Pero la creatividad también ayuda a resolver bugs porque permite distanciarse un poco del problema y observarlo con otro enfoque.

La creatividad es (hasta el momento) una de las cosas que nos diferencian de las máquinas. Un programador carente de creatividad no es más que una computadora que programa a otra computadora. No genera valor. No tiene nada adicional que ofrecer.

Comunicación

Siempre es bueno saber. Pero saber es mucho mejor cuando se tiene facilidad para explicar lo que se sabe.

La comunicación es cada vez más importante en nuestros días. Nos comunicamos todo el tiempo, con todo el mundo. En el caso de los programadores, con los clientes, usuarios, analistas, ingenieros, administradores de sistemas y también con otros programadores.

¿Cómo explicar un problema? ¿Cómo explicar lo que está realizando el programa? ¿Qué palabras usar? Seguramente si hace tiempo que trabajan en sistemas se han dado cuenta que hemos creado un lenguaje propio. No es lo mismo hablar con un cliente que con otro programador.

Pero no sólo se trata del lenguaje empleado, se trata también de ponerse en el lugar del otro e intentar crear un lazo inicial, un punto de partida, para poder transmitir lo que se quiere comunicar. Parece sencillo, pero no lo es y es bastante común encontrar programadores junior con gran capacidad para analizar problemas pero no para poder explicar lo que está ocurriendo a nivel técnico ni tampoco para bajar a un nivel más simple la explicación al usuario.

También en el área de la comunicación entra la redacción con todo lo que ello implica. Y especialmente la redacción de correos electrónicos en ambientes profesionales.

Autoconocimiento

Como diría Jack Sparrow: “está lo que un hombre puede hacer y lo que un hombre no puede hacer”. Conocerse a uno mismo es saber de lo que uno es capaz de realizar y de aquello que está fuera del alcance, al menos por ahora.

Comprometerse a llevar adelante una tarea que no se puede cumplir es una cualidad no profesional. Es un gran problema porque esa persona puede quedar encasillada como alguien irresponsable.

Por eso es mejor conocer los límites y aventurarse a superarlos siempre haciendo un análisis previo de las tareas a realizar. Para eso hay que estudiar, mantenerse actualizado y proyectar.


Por último quiero agregar que tuve guardado este artículo por mucho tiempo y que cada tanto le cambiaba algunas partes. El tiempo me fue mostrando más características que describí. También me hizo poner más énfasis en algunas partes.

No sé si es la lista definitiva de cualidades a desarrollar. Seguro que con el tiempo encuentre otras y algunas de las que enumeré aquí me parezcan triviales.

Pero bueno, la perfección no existe así que decido liberar el artículo para que sea libre.


Si te gustó este artículo te invito a que me sigas en mi nuevo proyecto Crónicas Freelancer donde encontrarás más contenido como este.

Agradecimientos: Vanesa Cillo (@_vpower), por sus aportes y revisión

Experiencias y pensamientos de un programador

Una serie de artículos relacionados con la programación y el mundo del desarrollo de software, desde el punto de vista de un programador.

Thanks to Vanesa Cillo.

Alejandro De Luca

Written by

Web developer #php #zendframework #zf2. Ronin. Autodidacta. Linuxero. Creador de @mentesliberadas. Tomo mucho café, escribo y odio los yo-yo's.

Experiencias y pensamientos de un programador

Una serie de artículos relacionados con la programación y el mundo del desarrollo de software, desde el punto de vista de un programador.