Ejecutar o Diseñar Software

Rafael Casuso
May 6, 2016 · 6 min read

Programo una media de 9 horas diarias: 7 horas aprox. durante mi jornada laboral (descontando tiempo de reuniones, gestión de equipo, etc) y otras 2 de media cuando llego a casa. Amo la programación hasta el punto de dedicarle más del 80% del tiempo útil que paso despierto (aquí descarto tiempo en desplazamientos, descansos y comidas), soy Lead Front-End Engineer y Lead NodeJS Back-End Engineer en mi actual empresa, además estoy emprendiendo con mi propio producto y me obsesiona estar a la última en tecnologías, frameworks y librerías.

Dedico dentro de ese 20% restante de mi tiempo útil un porcentaje diario a la lectura de artículos y libros, tanto técnicos como de negocio, y al estudio de temas tanto técnicos como de negocio.

De un tiempo a esta parte, paralelamente a la evolución continua de mi perfil altamente técnico (a través de cursos y certificaciones) me he ido interesando por áreas como el User Experience, el Diseño de Producto y el Desarrollo de Negocio. El impacto de estas disciplinas en el trabajo diario de un Desarrollador de Software es tan elevado que el propio sentido común (o la reflexión intelectual) debería llevar a los desarrolladores de todo el mundo a interesarse profundamente por ellas, para no conformarse con el papel de meros ejecutores de lo que otros plantean.

¿Quieres ser un mero ejecutor toda tu vida?

Es la pregunta que debes hacerte si eres Desarrollador de Software, da igual si eres Senior o Junior. Es cierto que según la empresa en la que trabajes (más vertical u horizontal, más distribuida en grupos multidisciplinares o en secciones uniformes) y según el diseño de flujos de trabajo y procesos que emplee (aproximación en cascada o más incluyente) tu rol y tu aportación pueden cambiar sustancialmente. Pero hay un hecho innegable: poco podrás aportar, aunque te lo permitan, en áreas que no te has molestado en estudiar.

Es completamente lícito querer quedarse en el área técnica y no salir de ahí, desarrollar tu carrera sin salirse jamás del círculo virtuoso de la mejora técnica continua (o del estancamiento continuo, según los casos). Pero este camino suele ir de la mano con un desconocimiento profundo de las fuerzas rectoras que dirigen el desarrollo y, lo que es peor, a menudo incluso va acompañado de desprecio a todo lo que no sea puramente técnico o esté vagamente asociado con conceptos como Producto o Negocio.

¿Por qué el desarrollador medio sigue despreciando aquello que dirige su trabajo?

En pocas palabras: por desconocimiento. A los técnicos de alto nivel nos gusta vernos como Jedis, monjes dedicados al estudio y la reflexión, a la búsqueda de la perfección. Algunos dirán que bastante tienen con seguir la pista de toda la evolución técnica de su área de especialización como para además preocuparse de la “charlatanería” de UX, Producto o Negocio. Lo que hay de fondo es, lo repito, puro desconocimiento y ceguera intelectual (sea esta elegida o no).

Aquellos que nos interesamos por estas disciplinas no somos Jedis menos elevados, no somos monjes corruptos, ni estamos manchados por el Negocio. Somos profesionales más completos, más conscientes de todas las fuerzas que componen el Ciclo de Desarrollo de Software, podemos aportar más al resultado final, tenemos mucha más perspectiva; en definitiva: somos más valiosos.

Los técnicos partimos de la parte más intelectual del Ciclo de Desarrollo de un Producto de Software: la programación, una parte a menudo inaccesible para los otros agentes involucrados (quienes a su vez, también por desconocimiento, suelen despreciar a los desarrolladores o minusvalorar su importancia). Formarnos en el resto de áreas involucradas en él es mucho más sencillo para nosotros que para ellos. Aprovechémoslo.

¿Queremos perpetuar el modelo de roles opuestos o entrar en el Desarrollo de Software moderno?

Los Desarrolladores como la familia de los Capuletos y UX/Producto/Negocio como la de los Montescos es un modelo viejo, desfasado, inútil e ineficiente que no debemos perpetuar. Aspiremos a algo mejor, seamos más modernos, más inteligentes, más maduros. Luchemos contra la ignorancia de los Desarrolladores sobre el Producto y el Negocio y de la gente de Producto y Negocio sobre el Desarrollo. Alentemos el auge de perfiles modernos de carácter técnico con conocimiento y visión de negocio y de perfiles de negocio con interés y conocimiento técnico. Apostemos por equipos humanos multidisciplinares basados en la confianza, donde el contacto y las sinergias entre todos los agentes involucrados en el Ciclo de Desarrollo de Producto sea constante e inevitable. Desterremos la verticalidad, la aproximación en cascada, las secciones separadas, dejemos de distribuir a los equipos físicamente en zonas diferenciadas según su área.

Empecemos a pensar Productos, no en Proyectos, a tratar a las personas como eso, personas, no meros recursos. Formemos equipos por Producto, físicamente juntos, ineludiblemente condenados a entenderse y a disfrutar de ese proceso, no a sufrir las frustraciones derivadas de la falta de entendimiento, de los bandos, de los Capuletos y Montescos. Luchemos, en definitiva, contra la ignorancia y la falta de comunicación.

¿Por qué a menudo minusvaloramos las charlas no técnicas?

Hace poco tuve el gran honor de dar una charla en el JSDayES 2016 titulada Rise of the Bots sobre Robots de Software e Inteligencia Artificial. Tuvo una gran acogida y recibí un feedback espectacular. Contrastó bastante con otras charlas de caracter más técnico porque ahondaba en aspectos relativos al Diseño de Interfaces, al UX, a las posibilidades de Producto, alcanzaba el diseño de Arquitecturas de Alto Nivel y sólo al final llegaba a implementaciones técnicas con ejemplos de código (que por falta de tiempo no pude describir con detalle). A pesar del gran feedback recibido y de haber cumplido plenamente mi propósito de no dar una charla ladrillo y provocar interés en la audiencia sobre un tema de mucha relevancia presente y futura para el Desarrollo de Software, me quedé con la sensación de que algunos deseaban una charla mucho más dominada por ejemplos de implementación técnica.

El Jedi puro y técnico que hay en mí, pero que no es todo lo que soy ahora, hubiese querido alardear de conocimientos técnicos, mostrar una sucesión de conceptos, implementaciones, patrones, complejos esquemas de relaciones entre objetos y entidades relativas al diseño de inteligencias artificiales e interfaces conversacionales que hubiesen dejado a esa parte de la audiencia satisfecha y probablemente incluso saturada. No hubiera sido difícil hacerlo.

Pero no lo hice. Y si tuviera que dar otra vez esa charla no lo volvería a hacer. Preparé esa charla durante dos meses, con un versionado estricto, con un proceso constante de mejora continua, con el intento de simplificar conceptos complejos (que para mí es lo verdaderamente valioso y la medida del nivel de conocimiento), con incontables horas de repaso. La ensayé con dos grupos diferentes de desarrolladores. La releí y reescribí no menos de cien veces. Y ahora no cambiaría ni una coma.

Para mí no fue una mera charla. Fue una declaración de intenciones. Llegado a un punto de madurez profesional no me importa tanto que me digan cómo hacer algo (el cómo muta constantemente, BackboneJS, EmberJS, AngularJS, Meteor, React + Redux, Aurelia, ES5, ES6, ES7, ES8, you name it) sino que me inspiren el qué hacer y el por qué. A veces parece que a algunos sólo les importa que les digan cómo hacer algo (el extremo son las charlas que se pueden sustituir por tutoriales al alcance de una búsqueda de Google) y no entender el Producto que están haciendo y por qué. A mi, y a otros muchos, nos interesa tanto el cómo como el qué y el por qué. Pero si tengo que priorizar esas cuestiones relativas a un tema poco conocido y debo expresarlas en 30 minutos lo tengo claro. Me interesa mucho más el qué y el por qué, el cómo es a todas luces secundario. Me interesa inspirar, provocar interés, comunicar el motivo, el objetivo.

No se entienda con esto que no he dado, doy y daré charlas técnicas, ni que no las valoro ni las aprecio. Me fascinan en tanto en cuanto no sean meros tutoriales ni enumeración de características. Me parecen especialmente provechosas aquellas basadas en la experiencia en proyectos reales (justo las potenciadas en el JSDay con mucho acierto), que te muestran todo aquello bueno y malo que no ves en la documentación pública y que puede ayudarte a tu trabajo y a tus proyectos.

Valga este artículo para reivindicar aquellas charlas que, como la mía, pretendan dar una visión, un contexto, un qué y un por qué antes de entrar en el cómo.

Vivan las charlas elaboradas y provechosas, sean estas técnicas o no.

Rafael Casuso

Written by

Director of Software @wall_box. Former CTO @Stayapp. CEO @SnowStormIO. Senior Developer. Software Architect. Speaker. Writer.

More From Medium

Also tagged Tech

Also tagged Frontend

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