#18#10 Muchos de los que conozco de becarios, preparando oposiciones, emigrados a Madrid o currando en empresas como la mía. Ni uno en el paro, pero ninguno cobrando lo que debería según sus conocimientos
#11 ¿Crees que me apetece seguir arreglando código spaguetti? Naturalmente que lo he sugerido
#12 Efectivamente, es mucho mejor entregarles un montón de mierda en el plazo y luego tener que estar parcheando hasta la Segunda Venida (con el consiguiente cabreo de unos y de otros), mientras que los nuevos proyectos no tienen tiempo de hacerse bien porque estás parcheando los antiguos. Aunque no se dan cuenta, es una forma cojonuda de ahorrarse un euro y perder dos en el proceso.
No se trata de hacer una documentación exhaustiva de todo y siguiendo perfectamente tal o cual metodología, sino de hacer las cosas más o menos estandarizadas para que no tengas que perder una mañana tratando de entender la idea feliz de un compañero o dónde pelotas se ha declarado tal cosa (si es que se ha declarado) o pases dos horas haciendo un algoritmo chachiguay que realmente ya estaba hecho. Eso es lo que realmente diferencia a un ingeniero de un picacódigos: un mínimo de planificación en tu trabajo; que las cosas tendrán alguna clase de estructura, de cohesión y de lógica interna, y que no verás una enorme maraña ininteligible de código para corregir una mierda que calcula la puta letra del DNI (por poner un ejemplo extremadamente chorra)
#13 El problema es cuando contratas a gente que no es ingeniero y tampoco tiene ni puta idea de cual es su trabajo. Por ejemplo, yo he visto tablas con campo clave "nombrepersona": dos "María García" y la hemos cagado periquito.
Y luego cuando las cosas cascan la culpa no es del empresario sino del departamento de informática, que no puede (o mejor dicho, no sabe) hacer las cosas mejor porque carece de gente suficiente que sea capaz de ir más allá del picado de código
#11 ¿Crees que me apetece seguir arreglando código spaguetti? Naturalmente que lo he sugerido
#12 Efectivamente, es mucho mejor entregarles un montón de mierda en el plazo y luego tener que estar parcheando hasta la Segunda Venida (con el consiguiente cabreo de unos y de otros), mientras que los nuevos proyectos no tienen tiempo de hacerse bien porque estás parcheando los antiguos. Aunque no se dan cuenta, es una forma cojonuda de ahorrarse un euro y perder dos en el proceso.
No se trata de hacer una documentación exhaustiva de todo y siguiendo perfectamente tal o cual metodología, sino de hacer las cosas más o menos estandarizadas para que no tengas que perder una mañana tratando de entender la idea feliz de un compañero o dónde pelotas se ha declarado tal cosa (si es que se ha declarado) o pases dos horas haciendo un algoritmo chachiguay que realmente ya estaba hecho. Eso es lo que realmente diferencia a un ingeniero de un picacódigos: un mínimo de planificación en tu trabajo; que las cosas tendrán alguna clase de estructura, de cohesión y de lógica interna, y que no verás una enorme maraña ininteligible de código para corregir una mierda que calcula la puta letra del DNI (por poner un ejemplo extremadamente chorra)
#13 El problema es cuando contratas a gente que no es ingeniero y tampoco tiene ni puta idea de cual es su trabajo. Por ejemplo, yo he visto tablas con campo clave "nombrepersona": dos "María García" y la hemos cagado periquito.
Y luego cuando las cosas cascan la culpa no es del empresario sino del departamento de informática, que no puede (o mejor dicho, no sabe) hacer las cosas mejor porque carece de gente suficiente que sea capaz de ir más allá del picado de código