Habla mi vecino de blog, Sergio Vazquez sobre que hacer para convertirse en un buen programador. Para mi la clave sin duda esta en que te apasione la actividad de escribir código, pero esto solo es una precondición. Además hay que hacer un motón de otras cosas, empezando por asumir que no se puede llegar a ser un buen programador sin escribir millones de lineas de código. Tengo mis serias dudas sobre si se puede ser buen jefe de proyecto, arquitecto, o analísta sin haber escrito mucho código.
Entre los comentaríos a ese articulo, yo recomiendo los dos libros que más me han influido como programador, y que creo que me han convertido en mejor programador.
‘Code Complete’ de Steve McConnell‘The pragmatic programmer’ de Andrew Hunt y David Thomas
A parte de esto uno de los comentarios, firmado por gogoz, viene a decir que como vas a ser un buen programador, si te dan un análisis ‘que da pena’. Bueno, pues aquí va lo que yo haría, justo depués de protestar (los que me conocen saben que protestar e intentar dar soluciones son dos de mis grandes aficiones, por ese orden).
Empezaria por explicar al analísta que el análisis no es adecuado y dejarle claro los motivos por los que no lo entiendes. Un buen analísta entendería que si el destinatario de un análisis no lo entiende o lo acepta es porque no es un buen análisis.
Lo segundo, explicarle que el único que puede estimar con precisión lo que va llevar implementar algo es la propia persona que lo va ha implementar. Esta demostrado que si quien va a realizar la tarea no participa en la estimación está tiene mucha probabilidad de ser erronea. La bibliografía sobre gestión de proyectos de software esta llena de justificaciones a esto, así que no me voy a extender.
Tecero, como probablemente el autor de un mal análisis no va a entender nada de lo anterior, pues simplemente trataria de hacer el mejor trabajo posible en la situación en la que te encuentras, sin caer en la desmotivación. Empezando por tratar de mejorar el diseño, solo las mejoras obvias, el 20% de mejoras que proporciona el 80% de mejora. Y no me preocuparia demasiado por las restricciones de tiempo, incluso el análista que no es muy habil sabe que no ha proporcionado estimaciones de tiempo realistas.
Por último, si la situación se repite, empezaria a enviar curriculums. Aunque parezca mentira hay empresas donde las cosas funcionan de manera diferente y los analístas realmente saben hacer análisis.
En relación a este tema, es muy interesante el articulo de Joel sobre como mejorar las cosas siendo un simple peón.
Tengo que decir que en la mayoría de los casos, como bien dices, es muy dificil ser un buen programador si no cumples tres requisitos que a mi entender son indispensables:
Pasión por lo que haces.
Años de experiencia creando código a tus espaldas.
Y sentido crítico a tu propio trabajo.
Todo se puede mejorar, no existe la solución perfecta y eso lo debemos tener siempre presente.
A quien no le ha pasado que al ver código escrito por el varios años atrás (o incluso meses) a pensado, ¿cómo puedo haber escrito esto?
Otra cosa muy distinta es el potencial para poder llegar a ser un buen programador, esto también es un problema de estimación de tiempo y que muchas veces se confunde con lo primero.
Veo que todo lo que comentáis está bien, pero la realidad suele ser mucho más duro.
Estamos hablando de malos análisis o de estimación erróneas, pero el principal problema es que no hay muchos programadores buenos. Es un bien bastante escado y pocas veces valorado. Cuesta mucho encontrar gente preparada y buena para los proyectos. Sí, hay mucha gente, gente que más o menos va cumpliendo, pero no cualquier programador te puede hacer una estimación correcta o un análisis/diseño.
El responsable de proyectos debe conocer a su grupo de trabajo, conocerlos bien, sabiendo sus puntos débiles y fuertes, y así podrá saber hasta dónde puede llegar cada uno.
Por cierto, no quita que esté de acuerdo con la mayoría de los puntos que se han comentando.
Uno de los puntos que ha parecido muy interesante es de «Pasión por lo que haces». Seguro que todos conocéis a más de uno para el cual una vez que suena la sirena, la informática deja de existir o que considera «hablar de trabajo» al hecho de hablar de algo relacionado con informática.
A mí no sería la primera persona que me lo dice 🙂
o como dijo Libertad de Mafalda …
«una pulga no puede detener una locomotora, pero puede llenar de ronchas al maquinista»
yo creo que siempre hay soluciones (salvo para la cuadratura del circulo), y que es mejor afrontar un problema con una solucion (que tal vez este errada) que simplemente quejarse y no hacer nada al respecto.
Interesante punto de vista 😀
Saludos
Siempre que imparto un curso sobre gestión de proyectos de software, con independencia de la empresa
gogoz ha tomado la solución que tu has dicho: enviar curriculums, porque está hasta los webs de ver analisis que no son analisis sino mercadotecnia para los clientes. Así como de analistas que son agronomos, periodistas, matematicos,… de todo menos analistas, pues, como bien dices, un mal analista JAMAS reconoce sus errores, pues equivaldría a decir «soy comercial, no analista, no valgo para esto», y, aunque es verdad que hay empresas donde los analisis existen, son las menos, pues lo que prima en la mayoría de las pequeñas pymes es dinero dinero dinero y no la calidad, además, ya nos tienen a los programadores que salimos de FP que les hacemos el trabajo sucio. Lo dicho, ¡hasta los webs!
Quería mencionar, aparte de code complete, otro libro de mcConnel que me encanta aunque es algo viejo y dificil de encontrar y se trata de Rapid «Development: Taming Wild Software Schedules» donde aparecen los «36 errores clásicos».
Si no lo haz leído, búscalo y dale un vistazo.