Esta imagen me hizo reír, es tan cierta [...] Como nota relacionada de algún modo con la imagen, creo que todos los cursos de introducción a las ciencias de la computación deberían incluir temas como los fundamentos del control de versiones, una introducción a un sistema de gestión de proyectos ágil y trabajar como parte de un equipo o grupo, y al menos un pequeño proyecto en grupo en el que realmente tengas que poner en práctica estos principios y colaborar con el fin de completar la tarea [...]
Comentarios
Y además las tres caras que no salen en la foto están sin pintar.
#2
#2 Ya sacaremos un parche... ¿algo hay que facturar el año que viene no? Además, el beneficio está en el soporte...
#2 es la versión beta y va para una empresa publica, cuando paguen se le dará la parte definitiva.
#5 #12 #16 #25 Sólo por vuestros comentarios, me alegro de haber enviado ésto
#2 Epic!
#2 Y el cubo al más mínimo giro se deshace en pedazos, siendo casi imposible de montar de nuevo. Después, la empresa pide que resuelvas un cubo de Rubik esférico.
#2 En realidad, no sabemos si los colores son los correctos. Solo había una plantilla en la que se veía esquematizada una cara en blanco y negro, lo que ves es un ejemplo que hizo el programador para salir del paso, que al final acabó quedándose como versión final.
Ja, el comentario de #2 es tan bueno como la imagen.
Bueno, ahora ya en serio, ojalá me hubieran enseñado en la facultad a manejar un sistema de control de versiones, o a trabajar en equipo.
Real como la vida misma
Primer día de trabajo:
-Buenos días ¿por dónde empiezo?
-Mira trabajamos con estos cubos.
-Ah muy bien, pero ya veo que tenéis cubos montados ¿cómo lo habéis hecho?
-Ni idea, eso lo montaron hace años unos tíos que sabían mucho y que les explicaron cómo había que montarlos, como ahora ya no están y no hay ningún tipo de documentación lo que hacemos es poner celo en las piezas que se caen.
#33 me ha pasado n veces
Gestor: Hay que tener el cubo, pero haciendo bien las cosas, no las mierdas de siempre.
Programador: 10 minutos resolviendo el cubo
Gestor: ¿como lo llevas? ¿no has terminado todavia?
Programador: me queda poco, en 2 minutos lo tienes.
....
Jefe: Programador, estas poco implicado, tus compañeros hacen el cubo en 15 segundos. Puedes dar mas.
Programador: Pero eso es a brochazos, acabara siendo un infierno el proyecto.
Jefe: Y que quieres que haga si el cliente me dice que tiene que estar en 1 minuto, no firmo el contrato?
Programador: A partir de ahora, saco la brocha.
Resultado: Los programas y servicios que todos conocemos.
#42 Es un problema real de los proyectos a medida. Un proyecto a medida de calidad requiere mucho tiempo, pero el cliente lo quiero como mucho en 3 meses. Si tu le dices 1 año, otro proveedor le dirá 3 meses. Da igual la calidad, el cliente lo quiere ya.
Al final tienes que hacer las cosas rápido, mal y coste de mantenimiento es tan alto que los beneficios son ínfimos o pierdes dinero. Es el problema de los desarrollos a medida y no de productor estándar.
En realidad no es tan así, en la facultad te enseñan lo que son las piezas, para que sirven y te explican la esencia del cubo y de sus colores, en el trabajo necesitan el cubo en 2 segundos pero en realidad tu nunca habías visto uno montado y lo más fácil que se te ocurre es pintarlo, con el tiempo uno aprende que el cubo en realidad no existe que es tu mente la que hace que se doble la cuchara.
Proyecto valoración 3000 horas + 500 de estabilización, horas reales para realizar el proyecto 1800 + 200 para estabilización. Y luego se preguntan porqué hay desviaciones y solo aparecen chapuzas por los proyectos...
#8 Lo peor es que todas las horas que faltan se hacen igual, pero sin cobrar y fuera de horario de trabajo: si sales a las X, te tienes que quedar hasta las X+3 porque si no el proyecto no sale y la culpa es TUYA y no del que hizo la planificación inventándose literalmente los tiempos.
No es por trolear, pero donde han pintado la cara amarilla en realidad tendría que ir la blanca.
#13 Eso se lo explicas al analista.
#14 Eso se lo explicas al jefe de proyecto
/cc #13
#13, #14, #15 Eso se lo explicas al cliente, que te jura que ellos llevan años usando una versión que tiene esa cara amarilla. Les envías 30 correos, les enseñas fotos de un montón de modelos y ellos siguen diciendo que su versión es amarilla, y lo quieren amarillo... a la semana de entrar en producción te encuentras una incidencia crítica, porque la cara debe ser blanca.
#16 ¡Pero qué dices hombre! ¡El cliente nunca se equivoca y siempre sabe lo que quiere!
#13 No tienes ni puta idea. Es la que debería ser azul que la han pintado de verde
En mi ex-curro en vez de una brocha hubiesen usado un tenedor (porque siempre se ha hecho así).
Para los que sabéis inglés, os recomiendo el hilo en reddit sobre la imagen: http://www.reddit.com/r/funny/comments/pj7le/i_gained_a_new_perspective/
Hablando literalmente de cubos de rubik:
Lo curioso es que con dedicarle un par de horas a memorizar cuatro reglas basicas y a practicar eres capaz de resolver un cubo en menos de 10 minutos (lo cual hablando de cubos es hacerlo lentísimo) y una vez sabes, tardas menos en hacerlo que pintando las caras (busca pinturas, abrelas, limpia pinceles, dejalo secar...) Eso sin tener en cuenta que con el tiempo serás más rapido y podrás aprender reglas mas sofisticadas que te harán mucho mas veloz.
Como ejemplo, yo tengo un cubo penco, que se atasca a menudo, y ni siquiera me he aprendido todas las secuencias basicas para resolverlo por capas, he aprendido como resolver mas o menos la mitad de los casos posibles en cada paso, cuando se me da uno que no he memorizado, repito 2-3 veces el que si memoricé, y tardo entre 3 y 5 minutos.
Hablando de ingenierías:
Hay de todo, lo peor que puede pasarle a un ingeniero es terminar quemado por la incompetencia, prisas y chapuzas que se ve obligado a sufrir.
Freidme a negativos, pero me parece una imagen-refugio de chapuceros, sinceramente.
Vale que hay timings, bugs, diseñadores tocapelotas y SQA mas tocapelotas aun, pero esa es razón para tratar de hacer las cosas bien desde el principio, no para refugiarse en el chapucerismo.
Lo que me dice la imagen es que prima la rapidez, con lo que se alienta el chapucerismo.
Pero dejemos algo claro: tu eres el técnico. Si tu dices que una cosa va a tardar algo de tiempo, ningún jefe debería ponértelo en duda. Y si te lo pone, el que 'pinta el cubo rubik' no eres tu. Tu sabes moverlo, pero te dan la brocha para que lo pintes, no la buscas tú. Tu obligación ahi es decirle: 'mañana, cuando quieras volver a hacer el cubo rubik, te va a ser imposible: las juntas estarán pegadas, y tendrás todos los colores cambiados. Yo hago lo que me digas, pero te estoy avisando que esto no se hace así a un nivel profesional, que es el que me exigís.'
Y digo esto, porque estoy cansado del 'si tu eres un crack, esto lo haces en una hora, machote', y otras sicologías baratas. Si no sabemos defender nuestro trabajo, nos van a atropellar siempre, y los timing nos fagocitarán.
Hoy mismo me han pedido que actualice una web, hecha hace 9 años, exportada directamente con los sectores de Imageready. Tablas. Colspans. Rowspans. Texto en imagenes cuarteadas. Una web asi es inadministrable. Es un cubo rubik con pintura desconchándose, pero metida entre los resortes de dentro, lo que la hace impracticable. 'Es añadir un enlace, esto en media hora lo tienes'.
Ninguna reforma laboral, ninguna crisis, va a hacer que deje de decir lo que he aprendido tanto estudiando, como trabajando. Cuando hicieron esa web, no pensaban en actualizarla en un futuro. Así que no le pidas peras al olmo.
#44 Tienes toda la razón, pero plantarle cara al jefe hoy en día puede ser peligroso. Tal vez ese sano "poder del técnico" que reclamas sólo esté al alcance de unos pocos, aquellos que son demasiado valiosos para ser sustituidos.
Para el resto de rascateclas, recomiendo pintar el cubo y no rechistar
#45 Y tu tambien tienes razón. Pero te voy a poner un ejemplo: un día llegó un chico nuevo a la empresa donde trabajaba. Le pedí que dejara una landing page tal cual salía en el diseño.
Lo primero que hizo fue ponerme una tabla como wrapper, envuelta en un div align="center", cuya función, era simplemente, centrar la página entera. Y la tabla, por 'defecto profesional', para meter el menu en celdas. Le expliqué que en la mitad de tiempo que tardó en envolverlo todo en 'eso', podria haber metido un en la clase wrapper que ya estaba creada en la css. Y que los menus no van en tablas, sino en listitas y , y palante.
Quizás esto es muy técnico, pero lo que él hizo es, precisamente, coger la brocha para pintar el cubo, cuando solo te faltan dos movimientos para completarlo del modo normal.
Lo puse a maquetar correos corporativos, que usan el HTML que él conoce: chapucerillo, pero útil en ese tipo de marcado.
Muchas veces pintamos con brocha porque, sentados, no alcanzamos a coger el pincel, y ¡levantarse es tan cansado!
Un saludo
#51 Esa asignatura que planteas existe, al menos donde yo estudié. El profe nos decía que teníamos que "aprender a trabajar en equipo"...
Aunque eso sí, quizás no es la escala que comentas (durante toda la carrera). Eso sería interesante también. Pero piensa que hoy la ingeniería informática es bastante más que desarrollo puro y no le puede dedicar media carrera. Por esto mismo yo creo que Ingeniería de Software debería de ser una carrera a parte.
#44 El problema es que quien te dice las cosas normalmente sabe de lo que habla. Y sabe que las cosas se harán mal, pero se han de hacer rápido.
Más de una bronca he recibido por "intentar solucionar el cubo", porque "has tardado mucho más cuando con un simple brochazo lo tenías, has perdido el tiempo".
http://media.tumblr.com/tumblr_lxzhka8Fqe1qh0893.jpg
¿18 días? OMFG! Esto más que viejo es un clásico retro!
#20 #21 Yo no lo había visto hasta ayer, tendré que dejarme el menéame y pasarme a reddit...
#22 Pásate al RSS tiiiiio!
Lo peor de todo no es que se pinte en lugar de resolverlo. Es que una vez hecho esto, nadie se preocupa de arreglarlo luego. No es que se haga "para salir del paso, y luego ya lo hacemos bien". No. Nunca llega el momento de "hacerlo bien", y los parches y las chapuzas se van acumulando hasta que llega un momento en que el sistema es inmantenible.
Es más: el grado de autosugestión de "los que están arriba" llega al punto de creer que esa era la buena solución, y que hacerlo bien hubiera sido una pérdida de dinero. Si se lo pintas te dan palmaditas en la espalda y te dicen "buen trabajo"; si en cambio hubieras hecho retrasarse la fecha de entrega y hubieras enviado el cubo correcto, te lo hubieran echado en cara (o te hubieran echado, directamente).
Es un gasto enorme en brochas y en pintura. El buen informático arrancaría todas las pegatinas y las volvería a pegar, sale más barato.
http://www.freakmarketer.com/wp-content/uploads/2007/10/proyectos01102007.jpg
Como sois unos vagos, os pongo la foto aqui y así no tenéis que leer el texto: http://i.imgur.com/Lus4Y.png (¿tengo que poner lo de ironic mode?)
No hace falta aplicarse solo a la programación, sino a muchos campos más.
Aaaaah, que bien que me dedico a la programación de software de ocio,
y no de consultoras.
Despues de un poquito de experiencia laboral, y de haber dado algunas clases en la carrera... el tema es algo largo de explicar, así que voy a resumir mucho: del dicho al hecho hay mucho trecho.
Podemos terminar la carrera, el máster o lo que sea pensando que somos muy buenos "en lo nuestro". Pero con la experiencia laboral nos vamos dando cuenta de lo cenutrios que somos. Tras 2 años, miramos un código y pensamos "¿¡pero esta mierda la programe yo!?". Transcurridos otros dos años, nos pasa exactamente lo mismo.
Conclusión: El movimiento se demuestra andando. Está muy bien tener todo el fundamento teórico de la carrera, pero hasta que no nos damos de hostias con la realidad no aprendemos. Así que la mejor forma de aprender es hacer cosas.
Tras estas experiencias, una de las cosas que siento es que durante la carrera los alumnos solamente se enfrentan a problemas de juguete. Personalmente, yo plantearía una asignatura que consistiese en realizar a lo largo de todo el curso un gran proyecto software, dividido en módulos y con pequeños equipos (2-4 personas máximo) dedicados a implementar cada una de las partes. Sería gracioso cómo los alumnos tratan asuntos bastante dejados de lado en la carrera como la organización en grupos de trabajo, comunicación entre grupos, coordinación de acciones... lo complicado sería establecer una forma de evaluar la asignatura, ya que probablemente el proyecto no se completase con éxito (:D).
#36 No creo que nadie piense que al acabar la carrera es la hostia y que no tiene nada que aprender. Por supuesto que aprendemos mucho en el trabajo, y que nos enfrentamos a problemas difíciles. Pero eso no es lo que se discute en la imagen.
La cuestión es si se intentan hacer las cosas bien o simplemente a aparentar, cuando por dentro todo está hecho un desastre y va a ser inmantenible en el futuro. Y dudo mucho que cualquier persona con una mínima experiencia laboral no tenga varias anécdotas de esas para contar. Todo lo contrario de la facultad, donde lo que se busca, por lo general, no es la apariencia, sino la corrección.
Lo de que los problemas de la facultad son "de juguete"... hombre, depende. No sé cómo serán ahora las prácticas, pero cuando yo la hice, las había que no eran tampoco ningún juguete. Algunos equipos se las curraban bastante y hacían proyectos realmente birgueros. Inversamente, en el mundo empresarial ves a veces a muchos informáticos implementando aburridos softwares de gestión (siempre lo mismo: alta/baja/modificación) o importadores de ficheros, que no les aportan nada. Hay de todo.
#36
Pues a mí me parece que o bien te enseñaron mierda o bien no aprendiste nada.
#36 Está muy bien tener todo el fundamento teórico de la carrera, pero hasta que no nos damos de hostias con la realidad no aprendemos. Así que la mejor forma de aprender es hacer cosas.
En mi humilde opinión, y simplificando mucho la cosa:
a) Hay conocimientos prácticos y conocimientos teóricos.
b) Los conocimientos prácticos son una herramienta fundamental para resolver problemas conocidos, se adquieren básicamente en la vida profesional y en poco tiempo se quedan obsoletos y hay que sustituirlos por otros.
c) Los conocimientos teóricos son una herramienta fundamental para resolver problemas nuevos, se adquieren básicamente en la vida académica y su vigencia puede durar literalmente siglos.
d) Si conviertes la vida académica en una simulación de la vida profesional, ganarás poco puesto que todo o casi todo ese conocimiento práctico extra se adquiriría de todas formas más tarde y se resentirá el conocimiento teórico, de manera que cuando aparezcan problemas nuevos no se tendrán herramientas para enfrentarse a ellos.
e) De hecho, a mi me parece que en el sector ahora mismo el nivel de teoría es ya lo bastante lamentable como para empeorarlo más.
Pero bueno, como dije, todo esto es EMHO, que tampoco quiero yo ahora empezar un flame.
#48 Cuidado, que igual me has malentendido.
Estoy totalmente a favor de la base académica, por eso estamos (o estabamos) formando INGENIEROS, no PICACODIGOS. Pero en una ciencia tán aplicada como la informática siento que a veces hay demasiado trecho entre lo que se aprende en la carrera y lo que se hace en la realidad (puede que sea porque en muchos casos en españa no se trabaja de ingeniero). Y lo digo como alumno, profesor y trabajador.
Fijaos en medicina ¿alguien duda de que los fundamentos teóricos son importantes? en absoluto, pero luego sigue un largo periodo de prácticas para afianzar esos conocimientos.
Además lo que planteo es una asignatura orientada a desarrollar habilidades fuera de lo estrictamente técnico y que se tratan poco en la carrera, como la gestión de proyectos, trabajo en grupo, coordinación, etc. ¿No son eso también conocimientos teóricos?.
Seguramente lo que más falta hace es un buen sistema de prácticas en empresa o de proyecto final de carrera, integrado en el plan de estudios, y que le proporcione a los alumnos justo al final de su formación ese empujoncito que les falta, y no se convierta en un "hazme la web de la empresa gratis".
#51
Estoy totalmente a favor de la base académica, (...). Pero (...)
Además lo que planteo es una asignatura orientada a desarrollar habilidades fuera de lo estrictamente técnico y que se tratan poco en la carrera, como la gestión de proyectos, trabajo en grupo, coordinación, etc. ¿No son eso también conocimientos teóricos?.
Esos temas se pueden estudiar a nivel teórico, pero lo que planteas es ir directamente a la parte práctica de los temas, sin pasar por la teoría. Lo mismo que sucede ahora mismo directamente "en modo real". No veo que aportaría, a parte de quitarle tiempo a conocimientos que no se adquieren simplemente por el ejercicio práctico.
#36 El problema es cuando la hostia con la realidad consiste en "esto es muy caro hacerlo bien, el negocio está en bajar el precio absurdamente, explotar a los trabajadores y entregar una mierda pinchada en un palo".
¡Qué hartada a reír!¡Qué bueno, si es que lo clava! Yo como mucho hice unos pinitos en ActionScript y es que me limité a hacer algo aparente y que funcionara "bien", pero una vez te ponías a hacer pruebas hacía aguas por todos lados
. Ni me imagino lo que debe ser un proyecto de programación de verdad.
"...La programación es un tabajo fácil y muy cómodo, que hacen "frikis/pikateclas"... y pretenden hacernos creer que se llama ingenieria..."
Joer esto es viejo de narices...
submitted 18 days ago
me siento tan profundamente identificado con todos vosotros :______(
En mi trabajo anterior la pintura la tendria que traer yo de casa, y de pincel y brocha ni hablemos... con los dedos...