Buen código y el arte de programar
Para el Desarrollador Senior John Cooley, programar es simple. Pero el producir buen código es un arte, y lograrlo es un trayecto de toda la vida. Conversamos con él en la sede de EEUU de Engineering para conocer su opinión acerca de su trabajo y de qué va el desarrollo de software de manufactura en Engineering.
P: En breve, dinos qué haces.
R: Mi rol es tradicionalmente como desarrollador de backend. Tengo especialización de nicho en integración de sistemas, particularmente integración ERP a MES. Probablemente hago el mejor trabajo y me divierto lo más posible siempre que intento traducir un conjunto de datos de un sistema a otro, a la vez que descifro las similitudes entre ellos.
Eso es en lo que soy bueno, pero cada proyecto es diferente. Y una gran parte de mi trabajo consiste en ser apto para llegar a una situación en la que no tienes conocimiento previo, luego tener que investigar y usar los recursos existentes para intentar encontrar una buena solución. Otro gran requerimiento del trabajo es un determinado nivel de confianza y la ausencia de miedo cuando trabajo en algo altamente especializado o técnico que no se ha visto o tocado anteriormente. No sé si todo ello encaja fácilmente en un rol laboral.
P: ¿Por qué programar? ¿Cómo terminaste en el mundo virtual del código?
R: Mi primera experiencia con la programación fue alrededor de los 14 años. Esto fue en la era anterior a MySpace, así que si deseabas tener presencia en web, tenías que tener tu propio sitio web. Siendo un joven adolescente, había hiper-estimado la opinión sobre mi arte personal, acerca del cual yo estaba muy apasionado. Así, decidí aprender HTML para crear mi propio sitio web. Y desde entonces, he continuado enseñándome a programar como un extra. Comencé con tablas y marcos HTML y progresé franco hasta el lado de servidor con programación PERL y PHP. Todo autodidacta. Vaya que si lo disfruté.
Al comenzar con la universidad, tenía vocación por la Biología. A la mitad del primer semestre de mi primer año, tuve el claro discernimiento de que me encantaba aprender acerca de Biología, y sin embargo no amaba trabajar en ello. Justo al percatarme de que la Biología no era lo mío, ya me encontraba administrando mi propio servidor, en mi dormitorio, albergaba mis propias páginas web, y pensé que ese sería el camino correcto para mí. En un principio, estaba indeciso entre Ingeniería Eléctrica y Computación. Ambas me interesaban. En Ingeniería Eléctrica, puedes hacer lo que sea. Esto es, puedes integrar tu propia computadora de así quererlo, pero tomaría muchísimo tiempo y funcionalmente, sería inútil. Finalmente yo disfrutaba más de la computación, porque obtenía una mejor proporción de resultados formidables a esfuerzo aplicado. Encontré un ambiente en el que prosperé y jamás volteé atrás.
P: Cada desarrollador tiene su sistema de creencias. ¿Cuál es el tuyo?
R: En el sentido más estricto, programar es realmente simple, y creo que cualquiera lo puede hacer. Pero la auténtica dificultad para programar, y que es un viaje de toda la vida, es el producir buen código. Se han escrito más libros de los que podría admitir una biblioteca entera sobre lo que es y no es buen código. Para mí, “Buen Código” es como el concepto taoísta de la iluminación; no está claro si eso se puede logar en una sola vida o carrera…
P: Entonces, ¿cómo se puede producir “buen código”?
R: No creo que la programación sea una ciencia estricta. Sin duda hay un aspecto artístico y creativo. Siempre pienso en programar como mitad arte y mitad ciencia.
En los primeros días de la programación, digamos los 1960 y 1970, una indicación razonable de tu habilidad para programar se relacionaba directamente con tu experiencia y conocimiento de las Matemáticas, y cuán adepto/a eras con esa disciplina. Ahora, al usar paradigmas más modernos como la programación orientada a objetos, un indicador más sólido de tu éxito es tu habilidad para pensar abstractamente, formar jerarquías entre los conceptos y realmente comprender qué similitudes y diferencias tienen, el categorizar cosas de forma que estas tengan lugar en tu programa. Eso es más fácil cuando hablas acerca de un objeto físico, pero es mucho más difícil de hacer con un concepto abstracto.
Siendo programador, siempre luchas por escribir y diseñar software que facilitará tu trabajo en el futuro, en vez de complicarlo. Puede ser que escribas algo extremadamente abstracto y genérico, un conjunto de herramientas que se puedan aplicar a cualquier cosa, pero el resultado será algo grandísimo, intrincado y complicado. Se requerirá de mucho esfuerzo para aplicarlo a cada requerimiento individual. O, puedes escribir algo mucho más especializado, pero entonces corres el riesgo de no poder satisfacer a un requerimiento nuevo y entonces tener que dar marcha atrás, re-escribir y re-estructurar tu programa. Al final del día, tu trabajo y tu meta siempre deberán de ser encontrar un balance entre estas dos cosas.
P: ¿Cómo te aseguras de continuar creciendo como desarrollador?
R: Especialmente al inicio de tu carrera, sin importar el enfoque que asumas, las cosas inevitablemente saldrán mal. Pero aprendes de tus experiencias e intentas adaptarte al avanzar. Creas controles y contrapesos orgánicamente a lo largo de tus errores. Cada éxito y cada fracaso crea un nuevo conjunto de herramientas a utilizar y una nueva colección de inconvenientes a evitar. Básicamente, recuerdas el dolor. Y la próxima vez que escribes código, tomas esas lecciones aprendidas del pasado y las aplicas. Entre más experiencia tienes, más te ayuda a crecer y hacerte un mejor desarrollador. Esto te impulsa hacia un el justo medio funcional.
P: ¿Cómo ayudas a los clientes?
R: No hay tamaño que se adapte a todos los diseños, ni hay diseño que satisfaga todos los requerimientos. De existir un Santo Grial de la programación, no se contaría con cientos de marcos y lenguajes. Habría 1 libro con 1 respuesta. Y de ser ese el caso, ¡mi trabajo no sería necesario! Gran parte de mi trabajo consiste en emplear mis habilidades, experiencia, conocimiento y la información que está disponible y aprovechar la totalidad para determinar cómo todo eso se integra en aquello que el cliente que tengo enfrente, me dice que requieren.
P: Háblanos acerca de tu trabajo en Engineering y tu equipo aquí.
R: Lo mejor acerca de trabajar en Engineering para mí: todo es diferente en cada proyecto único. Aquí he estado por 3 años, pero esto se ha sentido como si hubiera tenido 8 trabajos diferentes en ese tiempo. Cada proyecto al que te integras aquí es usualmente con una compañía totalmente nueva y con un conjunto completamente nuevo de clientes. Gran parte del tiempo esto también significa un nuevo equipo de empleados de Engineering, a quienes no habías tenido oportunidad de conocer y trabajar con ellos. Cada cliente es un lienzo en blanco, otro rompecabezas a resolver. Siempre estás alerta. Jamás es algo monótono. Es emocionante, desafiante, y te da la oportunidad de aprender y crecer continuamente en tu trabajo. Yo no lo quisiera de ninguna otra forma.
Conozca a John Cooley
Dónde naciste/creciste: Lake Forest, Illinois
Tu educación: Licenciatura en Ciencias de la computación de la Universidad de Bradley
Tu puesto: Consultor Analista Senior
Tu práctica @ Engineering: Manufacturing Operations
La ubicación de tu oficina: Chicago, IL, EEUU
Por cuánto has trabajado @ Engineering: más de 3 años
Tus áreas de experiencia: Desarrollo de software y aplicaciones, integración de sistemas de manufactura, diseño de sistemas
