http://local.joelonsoftware.com/mediawiki/index.php/Riesgos_de_las_Java-escuelas

Uff! Un poco más y me equivoco y lo pongo en otro tema … ese el de ‘ingeniería del software’ … perdón, perdón

“The company has maintained a 100 percent employee retention”

Que crack.

Esa sería una buena métrica a aplicarse por las empresas.

Me gustó mucho el artículo de Spolsky sobre la contratación de programadores. El tema de los punteros y la recursividad es un clásico de los programadores de C. No puedes programar C como toca sin conocer estos aspectos. Hay otras muchas cosas “divertidas” que la mayoría de programadores no saben (sobre todo temas de concurrencia y relacionados).

Desde luego no tengo dudas sobre que la gestión de proyectos no es una ciencia. De hecho la mayoría de técnicas que usan, las sabe cualquiera que haya estudiado cualquier carrera con cierto componente de “management”. El prolema es que algunas métricas de complejidad son difíciles de interpretar para una persona que no sea una experta en la tecnología que tiene por debajo.

Mira que me gusa poco la comparativa pero, cualquier arquitecto/aparejador/jefe de obra tiene el mismo problema para saber cuándo terminarán sus albañiles la obra. La unica manera de ser preciso es conocer al equipo y tener datos reales de problemas anteriores de complejidad similar.

También me hizo gracia el tema de “piensa antes de programar”. Sí, claro que sí. por supuesto y siempre, pero… ¿Cuántas veces no has empezado un programa escribiendo algo que haga algo y luego has ido mejorándolo? Depende del día, del problema, del programa.

¿Sabes por qué eres bueno y te das tanta cuenta de los desastres de los demás? porque llevas muchos años en esto (con interés, con dedicación, me refiero) y hay cosas quasi instintivas que sólo se adquieren con los años.

No digo que haya que lanzarse a picar código sin saber que es lo que quieres lograr y una idea de como quieres hacerlo, pero el pretender “hacerlo bien” a la primera, es pecar de ingenuos. Pasado un cierto punto, cualquier reflexión sobre como debe funcionar un software, se vuelve puramente especulativo: Para avanzar hay que ver el producto funcionando. No queda otra que “ensuciarse las manos” y escribir una primera versión o un prototipo.

Creo que, como al escribir, la manera más fácil y eficiente, es hacer borradores e ir mejorándolos. (No creo que nadie hubiera podido escribir meneame - en su sestado actual - a la primera).

Otra cosa que cada día aprendo una y otra vez, es que a programar se empieza con lápiz y papel, y habiendo pensado todo un par de días antes.

¿Donde está el límite entre profesión y ciencia en esto de la informática?