Video del #devHangout con @ftalavera, @taichi2000 y @davidlaym en @devacademyla


(David Lay) #1

El día 13 de abril, tuvimos el agrado y honor de ser invitados por devacademy.la para conversar en su programa sobre un tema que nos apasiona: software craftsmanship. Les dejo un link al blog con más detalles sobre la entrevista y al final, el video de la sesión.

PD: Javier Chacana estaba también considerado para participar pero lamentablemente no pudo asistir.


(Germán G.) #2

Lástima que el audio quedó muy saturado. Habrá forma de “limpiar” el sonido del video?

Por otra parte, felicitaciones! Aunque viene de cerca. Creo que deberíamos grabar otro video en ChileÁgil hablando de Software Craftsmanship y publicarlo en youtube.

¿Qué tal?


(Guillermo Schwarz) #3

Está super bueno.

Es de los programadores de 45 años, no me ha dado resultado… de hecho creo que no es un problema de edad, sino de qué tanta responsabilidad tienes… un gerente de programación o de arquitectura debería ser necesario.

Hacer las cosas mal todavía se considera una buena idea de negocio.

Si el proyecto está mal hecho es culpa del gerente, siempre, si el gerente no tiene reglas de cómo construir, si no lee el código, si no revisa y corrige, no es un jefe, es un cliente.

En mi opinión XP perdió porque Kent Beck cambió las reglas. Al principio era nada de horas extras. Luego lo cambió por sólo una semana al mes y máximo 2 horas diarias.Una vez que “water down” las reglas, se vuelve nada, la gente se salta las reglas.

“Reutilizable dentro de lo posible” <— mismo problema, hay que ser “extremo” por eso se llama extreme programming.

En Chile, el artesano es penca porque es como ir a pomaire, es muy rústico.

Pero anda a Francia y allá son todos artistas. Desde el chef al peluquero.

Uncle Bob lleva 40 años… no es tan viejo… a menos que haya empezado a los 15 años.

TDD is dead:

El código bonito. El mismo argumento que se daba en 1994… jajaja… las malas ideas no mueren.

Gente soberbia: Hablemos de la gente de finanzas que cuando el gobierno dice que los van a regular, dicen que no importa porque van a diseñar maneras de evadir esos controles. Eso es soberbia. ¿Qué soberbia podría tener un programador si es casi un perro entrenado encerrado en un cubículo? Con suerte podríamos tener un poco de respeto, al nivel de un contador, con suerte. Pongamos las cosas en contexto.

¿Porqué no podría un programador ascender técnicamente dentro de una empresa? A principio de 1900 había gerentes de energía porque era necesario tener energía eléctrica para el funcionamiento de la empresa. La gerencia es un tema de “necesidad” desde el punto de vista de la empresa, de modo que en la medida que el software se haga más necesario, habrá más gerentes con conocimientos tecnológicos (es usual que se publiquen mensajes odiosos hacia los gerentes de tecnología en las publicaciones de negocios porque no se consideran verdaderos gerentes, sino nerds).

Ahora bien desde el punto de vista de alguien que programa, el gerente de tecnología no es verdaderamente alguien que “sepa”. ¿Porqué se da esta dicotomía?

La respuesta creo que viene por el lado de que si inventas algo que puede usarse en todas las empresas, lo lógico es convertirlo en un producto cerrado y venderlo. Si lo conviertes en open source perdiste la oportunidad de venderlo, a menos claro que sea un un producto tan complejo que el resto no pueda entenderlo, como JBoss. Entonces los “gerentes” son squellos que conocen las características de estos productos y los promocionan al interior de las empresas, es decir, un gerente de tecnología es un vendedor de software de otras empresas al interior de la empresa en la que trabaja. Bajo esta visión, los computines no son más que los proveedores de scotch para que las distintas piezas, compradas a distintos proveedores, funcionen en conjunto. Sabemos que no es así, hacemos fácilmente el 80% del trabajo y los productos el 20%, pero desde el punto de vista de los directores de las empresas es así.

La pregunta entonces es como hacemos para que los verdaderos geeks asciendan en la empresa sin perder su “geekness”. Eso tiene que ver con el open source, en mi opinión. Si los productos usados son cerrrados, no tenemos el control de lo que pasa, el vendor entrega una nueva versión y si tiene un bug, si quiere lo arregla, si no quiere, jodiste. Eso de “ellos dan soporte”, es una mentira, nunca me lo han dado, nii Oracle, ni IBM, ni Microsoft, no les importa, no les preocupa, lo que les importa es vender, si el software no te funciona, ese es tu problema.

¿Entonces cómo hacemos que un tipo ascienda? Lo he conversado con los dueños de las empresas y ellos no quieren que ascienda, porque para ellos el ascenso significa que tomen su puesto. Porque dentro de su punto de vista sólo hay 3 roles:

a) Rol vendedor: habla tonteras, pero por su actitud, habla el mismo lenguaje que el cliente. Por definición si el cliente supiera, no compraría. Es decir, si supieras como fabricar un BMW, no lo comprarías, obvio. Entonces hablar desde el mismo nivel de ignorancia del cliente es una ventaja porque el cliente se siente acompañado. Hay beneficios que quieres como cliente, ¿cómo se hace eso?, eso lo entienden los geeks. Entonces vamos burlándonos de los geeks como una manera de defenderse psicológicamente y ese lenguaje el cliente lo entiende perfectamente.

b) Rol arquitecto: El tipo que entiende la tecnología, conoce y elige las tecnologías y es capaz de explicarlas. Si no las conoce, las investiga rápidamente.

c) Rol mano de obra: El tipo no conoce las tecnologías pero está capacitado para aprenderlas. Es capaz de repetir 200 veces lo que le acaban de enseñar.

Y obviamente está el dueño que no sabe nada de lo anterior y se convierte en un cliente más, pero organiza al resto en base a amenazas.

Ese punto de vista, aunque tiene sentido en el mundo reducido en el que viven, desmotiva a los empleados porque se sienten rodeados de monos entrenados. Los niveles en Microsoft:

  1. Aprendiendo en un proyecto. Todavía no se aprende 100% el estándar de programación y no cumple consistentemente con sus propias estimaciones.
  2. Ya sabe programar en el proyecto que está.
  3. Ya aprendió a programar al menos en 3 proyectos.
  4. Conoce los estándares de programación de al menos 5 proyectos y es capaz de proponer nuevos estándares. Consistentemente se demora menos que sus propias estimaciones.
  5. Es capaz de dar recomendaciones para mejorar el desempeño de cualquier equipo de trabajo, para que esos equipos lleguen a su nivel.
  6. Es reconocido dentro de la empresa. (lo buscan para resolver problemas dentro de la empresa, da charlas y participa de grupos de estudio).
  7. Es reconocido en la industria. (lo buscan para resolver problemas dentro de la industria, da charlas, escribe libros).

Esto es importante porque las evaluaciones y las estimaciones tienen siempre que basarse en cosas que se puedan medir y no en opiniones o favoritismos, ya que eso desmotiva a los empleados. Esto es muy común en los bancos, alguien hace algo y se va, un grupo minúsculo se convierten en guardianes de la información creada, las personas son promovidas por conocer el grupúsculo y obtener gratuitamente esa información, que la presentan como propia.


(felipetv) #4

guillermo te desafio a escribir todo lo que dijiste , que esta muy bueno en tweets!


(Guillermo Schwarz) #5

LOL

Felipe, que buena idea. Te desafío a hacer un programa que haga justamente eso.

?para que? No se. Supongo que es entretención… Nerd…


(Lennon Shimokawa) #6

Gracias Javier, David, Felipe y Germán por compartir con nosotros!
Si quieren participar en un próximo #devHangout me mandan un tweet a @lshimokawa y @devacademyla y lo programamos.

Es siempre un gusto colaborar con ChileAgil!


(Guillermo Schwarz) #7

Sí, sería bueno tener otro hangout y que sea con los 3 mosqueteros haciéndole preguntas a Uncle Bob.

Me imagino que le preguntaran qué pasa con TDD, si hay que usarlo “poquito”??? … Ya me imagino la respuesta del tío Bob. ;-D