El blog de ASPgems

Siguiendo el día a día de ASPgems

Y tú, ¿programas o desarrollas?

Y tú, ¿programas o desarrollas?

De como empezar a programar y acabar desarrollando

 

Seguimos a vueltas con la diferencia entre ser un programador y un desarrollador.

 

En general, cuando hablas con la gente de la industria, es cierto que se percibe que hay una cierta diferencia, pero no queda clara cuál es.

 

En ASPgems pensamos que para ser un desarrollador, antes necesitas ser un programador, pero que con eso no basta. Un desarrollador tiene que saber programar. Pero sobre esa capa de conocimientos de programación hace falta añadir una serie de habilidades que hacen que un programador se convierta en desarrollador.

 

Un desarrollador trabaja en un entorno donde se construye software de una manera que se encuentra a caballo entre lo artesanal y lo industrial.

 

Esa parte artesanal es la que viene de nuestro “yo” programador. Nos ayuda a construir la funcionalidad que queremos, porque cada solución requiere una implementación y unas características diferentes que pueden llegar a ser difícilmente automatizables (al menos mientras las nuevas tecnologías no nos quiten el trabajo)

 

Sin embargo, cuando nos dedicamos a la construcción del software, ya sea como servicio o porque tenemos un producto, necesitamos tener un proceso (no nesariamente rígido), de la misma forma que otras industrias lo tienen (automoción, construcción, terminales móviles).

 

Todas estas industrias pasan más o menos por las mismas fases:

  • Diseño

  • Prototipado

  • Producción

  • Control de calidad

  • Entrega

  • Mantenimiento y soporte

 

La construcción de software

 

Esto es igualmente válido para la construcción de software. Pero el software, desde que se popularizaron las aplicaciones en internet, se diferencia del resto de industrias en algunos aspectos:
 
  • El software no será nunca un producto completo. Siempre hay que estar añadiendo y adaptando sus funcionalidades a lo que esperan los usuarios. ¿Te imaginas que tu coche pudiera hacerse un monovolumen de la noche a la mañana, simplemente porque lo necesitas? Con el software puedes… y debes.
     

  • El software puede estar parcialmente roto. Los usuarios toleramos que el software esté parcialmente roto. Esto es debido a que el coste de solucionar el error, en la mayoría de casos, es ostensiblemente más barato que prevenirlo. Esto, claro está, depende del error en sí. No es lo mismo que se contabilicen mal los likes de una publicación en una red social, que se dispense el medicamento equivocado al paciente que no es…

 

Con esto en mente, podemos entender que un desarrollador es un programador que se preocupa por los problemas de la industrialización del software:

  • ¿Cómo hago para prototipar rápido?

  • ¿Cómo me aseguro de que cuando el software falle (porque va a fallar) me entero de que ha fallado?

  • ¿Cómo me aseguro de entregar el software lo más rápido posible?

  • ¿Cómo me aseguro de que el software que entrego es de calidad?

  • ¿Cómo hago para integrarme en un equipo en el que todos tenemos diferentes tareas, pero el mismo objetivo común?

  • ¿Cómo hago para que mi código pueda cambiar mañana sin demasiado esfuerzo?

 
Es curioso cómo muchas veces me preguntan si conozco a un programador de tal o cual lenguaje, pero nunca me preguntan si conozco a un desarrollador que sepa de estas cosas. En mis oídos esto suena como “¿conoces a un ingeniero que sepa trabajar con la taladradora PowerEG3000?”. Y mi respuesta siempre es la misma: “¿para hacer qué?”. No es lo mismo hacer una autopista, que un coche, o una grúa. Pues del mismo modo no es lo mismo hacer una aplicación social en tiempo real, que un dashboard para el comité de dirección que utilice muchas fuentes de datos diferentes.
 

Además, cada día aparecen nuevas tecnologías que cambian la forma de desarrollar aplicaciones: big data, machine learning, las 10.000 librerías que existen en javascript para hacer desarrollo front… que pueden hacer que tu tecnología se quede obsoleta frente a la de nuevos competidores.

 

Con esto no digo que el saber o no de una tecnología no aporte valor.

 

Hay tecnologías que se parecen más entre sí que otras. Si sabes python no te costará mucho aprender ruby. Y lo mismo pasa con Java o C#. En cambio si no has trabajado nunca con un lenguaje de programación funcional, sacar el máximo partido de scala, o trabajar en un diseño reactivo, resultará bastante más difícil.

 

Lo que quiero decir con esto es que si tu principal variable de contratación o tu mayor diferencial como programador es una tecnología específica, estás errando el tiro. Las tecnologías nacen y desaparecen a un ritmo cada vez mayor. Gente que entienda y resuelva problemas, no hay tanta. Además, de todo lo que hacemos los desarrolladores, aprender un nuevo lenguaje es, posiblemente, lo más fácil de todo.

 

Con esta filosofía lanzamos ASPcamp. Frente a los bootcamps que te enseñan a programar (y que hacen muy buen trabajo) nosotros queremos acelerar tu aprendizaje para que te formes tu propio criterio y sepas resolver problemas. No utilizar herramientas específicas.

 

Seguiré hablando de estos temas en diferentes posts... al menos mientras considere que como industria, seguimos haciendo las cosas mal.

Añadir nuevo comentario

Artículos relacionados

Nuestra revista

View my Flipboard Magazine