Recientemente he leído este artículo muy interesante sobre la forma de «subir de nivel», como un desarrollador de software. La lectura de este artículo me recordo algo que me ha sido persistente durante un tiempo desde que llege a Google: que hay una enorme brecha de habilidad y cultura entre los «desarrolladores» y «científicos de la computación». El consejo de Jason para incrementar de nivel en el citado artículo es muy práctico: escribir código en ensamblador, escribir una aplicación móvil, completar los ejercicios de SICP, ese tipo de cosas. Este es un buen consejo, pero ciertamente no todos en los que me gustaría que la gente de mi equipo gastara su tiempo haciendo con el fin de ser verdaderos líderes técnicos. Ya sea que puedes escribir JavaScript todo el día o conocer las entradas y salidas de las plantillas C++, a menudo tiene poco que ver con si eres capaz de captar el más grande, más abstracto, menor problema bien definido y ser capaces de avanzar con ellas.
Para eso se necesita un conjunto muy diferente de habilidades, que es donde empiezo a trazar la línea entre un informático y un desarrollador. Personalmente, me considero primero un Informático y segundo un ingeniero de software. Yo probablemente no soy el hombre adecuado para producir miles de líneas de Java en un plazo breve, y que me maldigan si estoy totalmente alineado a las reglas de herencia de C++. Pero esto no es por lo que Google me contrató (¡espero!) Y me apoyo en gran medida de que algunos programadores increíbles que entienden estas cosas mejor que yo.
Ten en cuenta que no soy la definición de un Informático como alguien con un doctorado – aunque ayuda. Hacer un doctorado te enseña a pensar críticamente, a estudiar la literatura, hacer un uso efectivo de diseño experimental, y para identificar los problemas sin resolver. De ninguna manera se necesita un doctorado para hacer estas cosas (y no todo el mundo, con un doctorado puede hacerlo, tampoco).
Algunas observaciones sobre la diferencia entre los informáticos y programadores …
Piensa en grande vs Consiguelo Hecho
Una cosa que me puso un poco loco cuando empecé en Google fue la rapidez con las que se mueven las cosas, y la frecuencia de las soluciones que se ponen en marcha que son necesarias para seguir adelante, aunque no son totalmente generales o totalmente pensadas. Viniendo de una formación académica, estoy acostumbrado a pasar años insistiendo mucho en un solo problema hasta que haya una única solución bella y general que se puede hacer frente a una enorme cantidad de escrutinio (en su mayoría en el proceso de revisión por pares). No es así en la industria – que tenemos que movernos rápido, por lo que a menudo es necesario para resolver un problema lo suficientemente bien como para pasar a lo siguiente. Algunos de mis colegas de Google han sido, sin duda impulsados por mi insistencia en conseguir algo «bien» cuando ellos deberían (y de hecho deben) seguir adelante.
Otro aspecto de esto es que los programadores suelen estar satisfechos con algo que resuelve un problema en concreto y bien definido y que pasa las pruebas unitarias. Lo que a veces no preguntan es «¿qué puede mi acercamiento no-hacer?» No siempre hacen un buen trabajo de medición y análisis: Prueban algo, parece que funciona en unos pocos casos, están terriblemente ocupados, por lo que siguen adelante, verifican y van por lo siguiente. En el ámbito académico podemos pasar meses haciendo la evaluación del desempeño sólo para obtener algunos gráficos bonitos que demuestran que un enfoque técnico determinado, funciona bien en una amplia gama de casos.
Prototipo de usar y tirar vs solución robusta
Por otro lado, una cosa en que los científicos de la computación a menudo no son buenos es en el desarrollo de código con calidad. Sé que todavía estoy trabajando en ello. La broma es que la mayoría de los académicos escriben código tan endeble que se derrumba en un montón de bits tan pronto como pasa la fecha limite del papel. Programar código que es verdaderamente robusto, funciona bien, es fácil de mantener, esta bien documentado, bien probado, y usa todas las mejores prácticas aceptadas, no es algo que los académicos están capacitados para hacer. Me gusta trabajar con los ingenieros de software hardcore en Google que no tienen ningún problema de señalar los errores totalmente obvios en mi propio código, o lo que sugiere un enfoque más limpio, más elegante de alguna página de mi código que he presentado para su revisión. Así que hay mucho que los científicos de la computación pueden aprender acerca de la escritura «real» de software en lugar de prototipos.
Mi equipo de Google tiene una buena mezcla de gente, tanto desarrollo y científicos, y creo que es esencial para lograr el equilibrio adecuado entre el desarrollo rápido de software eficiente y sobrepasar los límites de lo posible.
Fuente: Volatile and decentralized
