¿Hola? ¡Soy el que postea fotos de bananas mellizas!
Desde que decidí no ser más troll (¡Estoy tratando!)
vengo notando mucha gente que toma lo que digo y escribo demasiado en serio. Este post
es un gentil recordatorio de que suelo postear muchas más pavadas que cosas interesantes. MUCHO más.
Así que si de golpe se te cruza "Epa, Roberto parece estar diciendo algo interesante",
primero acordáte de las bananas mellizas. Si todavía te parece interesante, dale
para adelante.
Miremos SLOC, que está desacreditada como medida de la productividad de
un programador, pero seguramente es una medida adecuada de lo que el
programador tipea.
Bueno, las estimaciones de código total producido en la vida de un
producto son muy variables (tomando las SLOC del producto y dividiendo
por la cantidad de hombres/día gastados), pero suelen oscilar entre
10 y 100 SLOC por programador por día. Seamos generosos y digamos 200.
Entonces 200 líneas en 8 horas. Eso es más o menos una línea cada dos minutos
y la línea promedio son unos 45 caracteres. Asumiendo que sabés escribir al
tacto (y si no sabés, qué vergüenza), te puede llevar 20 segundos.
Entonces, escribir, que es lo que muchos optimizan en su editor, lleva
menos del 15% de tu tiempo. ¿Y cuánto más rápido podés ser? ¿Podés sacar
esa línea en 10 segundos? Entonces acabás de liberar el 8% de tu día.
Y no creo que tu editor te ahorre la mitad del tiempo de tipeado.
¿Cuánto tiempo perdés con los ojos flotando por los sidebars, los botones,
las toolbars, etc?
Entonces sí, tipear más rápido es una optimización, pero tal vez es
prematura, porque ¿Qué miércoles estamos haciendo el otro 80% del
tiempo? ¿No hay nada que podamos hacer para que ese pedazo enorme de
tiempo sea más eficiente en vez del pedazo chiquito?
Creo que usamos gran parte de ese tiempo en tres cosas:
Leer código
Pensar qué código escribir
Arreglar el código que escribimos
la primera es fácil, necesitamos mejores lectores no editores. Es una pena
que la interface por default para mirar código sea un editor, con su constant
invitación a cambiar lo que deberíamos estar observando. Cre que hay una
oportunidad perdida ahí, en alguna parte, de tener una aplicación en la que se
pueda ver el código de maneras interesantes y originalaes, para entenderlo
mejor.
La segunda es más difícil, porque es personal. Yo camino. Si me ves caminando
con el editor abierto, estoy pensando. Después de que pienso, escribo. A mí
me sirve.
La tercera es la más difícil. Sí, el autocompletado sirve porque no tenés
tantos typos, pero hay enfoques más poderosos, como correr constantemente
test suites mientras editás. Cada vez que dejás una línea, lanzar los tests
afectados.
Eso es sumamente difícil de implementar porque tus herramientas deberían relacionar
tu suite de tests con tu código muy precisamente, para que veas que rompiste cosas
en el segundo que las rompiste, no un minuto después.
También se debería poder saltar a los tests con una tecla, para que puedas
arreglar los tests si estás cambiando comportamiento en tu código. Y por supuesto
significa que necesitás tests ;-)
Lo que me trar a una cosa que me pica hace mucho, que los editores tratan
al archivo como unidad de trabajo, que no tiene mucho sentido. ¿Cuando tuviste
ganas de editar un archivo? ¡Nunca! Querés editar una clase, una función,
un método, una constante, no un archivo. Saber eso era el genio del
antiguo Visual Basic, ignorado por todos los que lo miran condescendientemente.
Así que en vez de pavear con tu editor, hacéme una herramienta que haga lo que
necesito, por favor. La vengo esperando desde VB 1.0. Eso y un sandwich.
