A todos los informáticos les ha pasado alguna vez que les hayan dicho: "Tu trabajo no es duro, duro es picar piedra en Mordor". Puede que ese trabajo en concreto sea más duro, pero veamos algunos aspectos de trabajar picando código que lo convierten en un trabajo duro.
|
etiquetas: programacion , desarrollo , coding , informatica 
Esas personas te lo resolveran haciendo una chapuza. Y te lo digo yo, que lo he viso que no trabajo de programador. Soy responsable de proyecto, pero en la empresa tenemos un equipo de informática que hace soluciones internas para la empresa. Un día, al decirle a uno de ellos que yo también era informático, me dijo: "Ah, entonces tú si que no entenderás. La gente se queja porque tal programa es lento, pero esto es porque (explicación técnica de mierda)". A lo que le respondí: "¿Y no sería mejor si en vez de esto hicieses esto otro?". Respuesta: "Sí. Sí, así también podría funcionar".
Aquel tío, como tu dices le saca las castañas del fuego a la empresa, porque hace un software que funciona. Ahora bien, hizo un software que era innecesariamente lento, lo cual se traduce en HORAS perdidas por parte de algo menos del 70% del personal de la empresa (somos unos 400), que utilizaba aquel software. Y eso, para la empresa,…...
saluddd
ellos inmediatamente lo pondrán en la primera hoja del proyecto, para darse importancia pero a la ora de la verdad como
* los Test unitarios hay que hacerlo antes que poner una linea de código del programa ya que estos validan las subidas
* que se programa en pareja de programadores
* hacer reuniones periódicas y hacer participar al cliente
termina todo en agua de borrajas
1º el cliente no quiere se le moleste solo que haga el programa como el quiera pero se lo tiene que adivinar a distancia
2º 2 programadores mirando la misma linea de código?... uno por maquina y si vienen de una FPO con compromiso de contratación (juniors) que page pues mejor que mejor
3º no hay tiempo para perderlo en los test
4º lo peor cuando alguien dice Refactorizar ... todo el mundo loco hasta las 4 de la madrugada
pues el proyecto se entrega fuera de tiempo con millones de errores, con el cliente cabreado, el jefe cabreado y por alguna extraña situación los culpables son los ingenieros y los programadores
En ensamblador se hacían cosas mucho más rapido. (Y siguen siendo). Compara:
wiki.speccy.org/cursos/ensamblador/introduccion
microhobby.speccy.cz/mhf/179/MH179_47.jpg
No, no es código hexadecimal para pasar a binario. Son o más bien trucos, o cargadores en BASIC que llaman a POKES.
En el ensamblador se usan mnemotécnicos, y no es tanta locura como meter los opcodes a mano.
EDIT: A no ser, claro que está que el compilador de C optimice mejor que tú escribiendo en ASM
Y encima funciona en una máquina física.
Relacionada: www.meneame.net/story/feliz-50-aniversario-basic
El pseudocodigo como técnica pedagógica me parece muy buena. Un buen programador tiene que ser capaz de ejecutar el código en su cabeza, y el pseudo código te obliga a ello. Si no eres capaz de esto, mejor dedicate a otra cosa.
#14 Me refiero a esa filosofía de que un "picateclas" pica el pseudocódigo que le da el ingeniero. El que hace el código lo codifica y punto.
En cualquier caso no es una técnica muy buena porque no te muestra los errores salvo que alguien te lo corrija (y no suele suceder). Escribir un código en papel teniendo el PC delante es una estupidez y punto.
Una buena idea de programación, una consulta SQL bien hecha, un buen análisis pueden ahorrar meses de trabajo. Y cientos de incidencias.
Pero nada de esto se mide o se tiene en cuenta.
Esas personas te lo resolveran haciendo una chapuza. Y te lo digo yo, que lo he viso que no trabajo de programador. Soy responsable de proyecto, pero en la empresa tenemos un equipo de informática que hace soluciones internas para la empresa. Un día, al decirle a uno de ellos que yo también era informático, me dijo: "Ah, entonces tú si que no entenderás. La gente se queja porque tal programa es lento, pero esto es porque (explicación técnica de mierda)". A lo que le respondí: "¿Y no sería mejor si en vez de esto hicieses esto otro?". Respuesta: "Sí. Sí, así también podría funcionar".
Aquel tío, como tu dices le saca las castañas del fuego a la empresa, porque hace un software que funciona. Ahora bien, hizo un software que era innecesariamente lento, lo cual se traduce en HORAS perdidas por parte de algo menos del 70% del personal de la empresa (somos unos 400), que utilizaba aquel software. Y eso, para la empresa, es una verdadera fortuna.
No es un trabajo para mentes privilegiadas, si llevamos las cosas al extremo es fácil ridiculizar la opinión contraria. Pero no es algo que pueda hacer correctamente cualquiera sin la formación adecuada, si no, tenemos las webs que tenemos (como las gubernamentales, que hacen llorar a cualquier buen informático, yo cuando tengo que hacer la declaración me lamento por partida doble, por pagar a hacienda y por tener que utilizar esa basura de sistema), cuyos responsables te dirán que funcionen aunque estén mal diseñadas y mal programadas.
Si los salarios son bajos es porque la mentalidad del empresario es como la tuya: ¿Si puedo tener las cosas mal por 700€, para que tenerlas bien por 1500€? Si alguien responde con un ejemplo como el anterior, en el que la empresa perdería dinero la respuesta es la segunda parte de la mentalidad del empresario español: Si mis empleados pierden horas, no es problema, basta con que se queden a hacer más horas (sin cobrar, claro)
He visto cosas que no creeríais...
La programación como en todo se puede hacer bien o mal. Existen verdaderos cracks, como en todo, pero el tamaño de la mayoria de los proyectos es tan grande que resulta imposible ser un crack en general. Quiero decir. Para ser un crack generalmente no solo has tenido que perder mil millones de horas, tambien debes comprender y saber todos los recovecos de un lenguaje en particular.
Eso de ser un crack en la informatica me lo han dicho mucho los informaticos de carrera, y no puedo estar mas en contra. Actualmente si eres un crack en un determinado lenguaje puedes alegrarte.
Uno puede ser un crack pintando al oleo, cocinando un huevo o esculpiendo un David. Pero en informatica igual que en otros muchos sectores no es solo cuestion de tener una mente privilegiada. Conozco grandes informaticos que no saben maquetar con CSS, o gente que es Dios en C y que cuando tiene que programar con una API de no se que servicio se vuelven locos.
Seria alucinante que la informatica fuesen solo ideas bien escritas, una¡ esquema bien organizado y ya esta. Lo cierto es que en la mayoria codigos el volumen de bugs, problemas de base y en definitiva inestabilidades es tan grande que resulta imposible convertirse en un crack. A no ser claro, que vivas con tus padres durante 7 años mientras le das al teclado en el garaje de tu casa. Y eso no es lo que suele ocurrir. Lo normal es acabar a los 23 programando en una gran empresa. A los 34 te das cuenta de que no has aprendido y te has convertido en un programador mediocre. Mediocre en el fondo de tu corazon, para tu jefe seras el crack por programar a toda pastilla.
Una vez hablando con un programador recien salido de la carrera le comente que estaba metido en un proyecto por mas de 3 años. Cuando le pregunte si sabia PHP su respuesta fue algo como "va... yo se programar... en una semana le cojo el tranquillo". Esa es la mayor mentira de la programación.
Este punto de vista lo podeis ver en las grandes empresas, esas que tocan un poco de todo. Esas que hacen reuniones todas las semanas.
#22 toda la razon del mundo, pero no creo que sea por lo que dices. Yo simplemente lo achaco a que el publico no sabe de informatica, igual que quien crees que te esta arreglando el ordenador. Hasta que el mercado no exija buena informatica no habra buenos informaticos. Para que pagar 6.000 por una web si por 1000 me la hace el vecino. Y peor aún son las empresas, para que pagar a una plantilla todo el año si por 500 un subcrontratado me soluciona la papeleta.
Me ha gustado tu comentario. El valor añadido a esos 50.000 es la clave.
De hecho en España, aunque los proyectos sean en su mayoría mierdas, hay un buen nivel entre los programadores. Aquí casi que se nos rifan.
La informática se ha ramificado mucho con muchas especialidades. Es imposible abarcarlas todas bien.
Y como dice #35 hay muchas formas de hacer que los pitfalls que hacen de la programación un trabajo mental muy duro, sean menos duros, como por ejemplo TDD. Yo, en mi proyecto, disfruto como un enano trabajando porque prima la calidad, se cumplen los plazos, todos tenemos voz, y creemos en que hay buenas prácticas que hay que seguir... No es España, por si alguien lo dudaba
cualquier chaval te arregla un portatil, te da una solución de software (mejor o peor), te crea una página web ...
Generalizar lleva a conclusiones erróneas, una pagina web es una pagina estática creada con una plantilla de 30$ de themeforest o es la web de la aeat? o es una aplicación web para ayuntamientos para gestionar toda la parte económica?
Una solución de software es encontrar un programa en softonic que se aproxima a lo que buscas o es un software creado a medida a tus necesidades?
Hacer un proyecto web es en general complicado, lo que pasa es que en web/programación se ofrecen soluciones opensource gratuitas que sirven para determinadas areas/situaciones y donde es relativamente fácil encontrar soporte y código gratuito o barato debido a su amplia difusión.
Ahora bien, que el hijo de tu vecino te instale un wordpress con una plantilla molona no quita mérito a que un wordpress esta hecho por programadores de verdad y la plantilla más de lo mismo. Y sin embargo te lo ha hecho alguien que no tiene ni puta idea de bases de datos, patrones de diseño, programación ni maquetación web.
Pero una cosa es una web sencilla y otra es una solución a medida donde hace falta un trabajo de consultoría, análisis, arquitectura de la solución, diseño implementación y test.
Lo que pasa que en este mundillo debido a la naturaleza misma de lo que es un trabajo puramente intelectual encuentras soluciones gratuitas (hechas por gente que son profesionales de la programación) y hay soporte y código (p.ej en stackoverflow) que valdrían una pasta en otras profesiones/situaciones y que son completamente gratis.
Es decir, a modo de ejemplo, tu puedes utilizar una plugin de jquery p.ej para poner popups en tu web, te bajas todo el código(que lo ha hecho alguien que no es el hijo del vecino y ha estudiado y sabe lo que hace). Pero si no tienes ni pajolera ideas de como esta hecho y funciona (tienes unas bases mínimas de programación web en el lado del cliente) , a la mínima que haya un problema o necesites alguna pequeña modificación necesitaras saber lo que estas haciendo.
Otro ejemplo es alguien con un poco mas de nivel (un hijo de vecino 2.0) ya sabe algo mas te crea algo en php, pero te mete todo el código en un solo fichero, mezcla sql html css javascript, pero no pasa nada, es algo pequeño y funciona.. pero llega un día en que van pidiendo mejoras y modificaciones y ese fichero ya ocupa 5000 lineas y no hay forma de meterle mano. No hay documentación, no se entiende nada, el programa con 20 registros funcionaba bien, pero ahora que hay 15000 el rendimiento es inaceptable...Cual es la solución?... aguantar como puedas con esa solución e ir creando una bien hecha y documentada para cuando este acabada y testeada darle una patada en el culo y simplemente desechar el código espagueti que ahora no sirve para nada. Al cliente se le puede vender la moto como quieras, pero en realidad ha estado pagando el mismo software como mínimo dos veces, pero el nunca lo sabrá.
un albañil, un aparejador, un encofrador, y un arquitecto. se sabe bien sus funciones y si ves una pared que esta doblada sabes que es cosas del albañil o si ves una puerta que no va a ningún lado en un edificio es que el arquitecto no supo ver que eso era una 10th planta y no tiene acceso al jardín de la planta baja.
estos aplicado en la generación de software donde te pueden poner
[centros deportivo]*---------1[pelotas] (cada centro deportivo tiene 1 pelota una pelota esta en muchos centro deportivos)
y el analista y diseñador (arquitecto de software) se pasa por alto. el programador se lo pasa también por alto. si hay un Betatester en la empresa (lo normal es que no lo hay) se lo pasa por alto tamicen el cliente se lo va encontrar de enfrente si o si y este se enfadara y lo primero que van es por el programador y si es muy grave este terminara fuera, siendo culpa del analista cuando planteo los requisitos o cuando se diseño
eso si un error de diseño detectado en producción es lo mas costoso de reparar
lo mejor es cuando el cliente te dice yo me dedico a ........ y quiero un programa que me lleve eso ...... por 500 euros
Aparte, es como comentan #19 o #20, chapuzas las puede hacer todo el mundo. Todo el mundo sabe freir un huevo, hacer un agujero en la pared, coser un botón, hacer un café, vender una camiseta... de ahí a que se haga correctamente y de forma eficiente hay un trecho, y para eso se pagan profesionales. Y el "kilo" de profesional no puede estar al mismo precio que el de un "chapuza".
Datos para tomar la decisión: Trabajé dos años como desarrollador en una cárnica. Actualmente, como profesor, no tengo plaza de funcionario, tengo 90 días de vacaciones/año. Salgo a las 17:00 del trabajo y cobro 1,7k€ 14 pagas, pero profesionalmente ya no puedo subir más y quizás en el sector de la informática pueda ascender hasta puestos altos con buenos sueldos.
¿Qué me recomendáis? Tengo 34 años
Gracias
Es que no entiendo por qué un buen informático tiene que saber de CSS. En fin.
Algunos sois la hostia, os puede venir aquí Alan Turing en persona y decirle que es un mierda por no saber PHP.
Me encantaba resolver problemas y resolver los ejercicios, pero picar código me quitaba la vida.
Todo mi respeto a la gente que se pasa 8 o más horas haciéndolo en el trabajo, o peor aún, por hobby.
Es lo bueno de las carreras duras, aunque no sirvan para trabajar de lo tuyo, te permiten adquirir hábitos de estudio y capacidad de autoaprendizaje, cosa que te facilita las cosas de cara al empleo público(aunque no tenga nada que ver con lo que has estudiado).
Es tan cierto que duele
Eso llevado al extremo lo vi en una cárnica. Sé que no es noticia decir, esto, pero acababa de salir de la universidad y quedé espantado porque pretendían meter hasta economistas a programar tras un curso chusco. Su puta madre...
Han pasado tantos programas chapuzas por mis manos que he cogido fobia a todo lo que lleve un sistema informático instalado en su mecanismo. He visto cosas que aparentemente funcionan, pero que aún no me explico como no han explotado. A algunas poco les falta y otras cómo me temía las he visto explotar en directo, una pena que no me diese tiempo a meter mano en ellas.
Y entonces me entran los miedos. Cada vez que saco dinero del banco me pregunto si el programa del cajero lo hicieron buenos programadores o no, si el cajero no se va a tragar mi tarjeta por culpa de un bug, o si cuando pulso las teclas y tarda mucho en responder es porque el sistema esta sobrecargado de verdad o porque el programa es una chapuza.
Lo mismo cuando entro en webs y veo que son lentas, con comportamientos raros, y entonces me da por revisar su código fuente y veo miles y miles de líneas de código HTML y JavaScript para simplemente mostrar una chorrada de contenido en mi navegador. ¿Todo eso era necesario? ¿Es programación chapuza? ¿O es efecto "FrontPage"?
¿Y cuando modernizan software? No sé porque mi mente asocia como que el software viejo es mucho más robusto que cualquier cosa nueva. Quizás porque en mi mente corre la idea de que antiguamente los programadores eran auténticos paladines de la programación que amaban su trabajo, eran concienzudos y lidiaban hasta con el último byte que C/C++ les permitiese. Mientras que en las nuevas generaciones los desarrolladores son un popurrí de gente sin ningún tipo de amor a la programación haciendo burger-software con lenguajes .NET y Java. Y no quiero que se me malentienda, que valoro mucho .NET, Java y los lenguajes de alto nivel con gestión de memoria automática, totalmente necesarios hoy en día.
La modernización siempre es necesaria, pero menudo miedo me da, sobretodo si hay una gran consultora detrás del trabajo.
Me gustaría tener a mano estadísticas reales pero apostaría mi mano del ratón a que más del 50% del software que usamos a diario es software chapucero, lento y lleno de bugs.
Pero lo alarmante es cuando empiezo a pensar en el software crítico, ese que llevan los aviones, hospitales, etc...
#16 tiene toda la razon, por 600e yo no me pringaria con los cabeza buques q hay por el mundo "liderando" "equipos" o proyectos.
pd: alguno dentro de ellas se comporta = q una estafa multinivel, saben q la empresa es pura mierda por lo q su unico cometido es subir lamiendo esa mierda para pillar un % a fin de mes.
No conozco ni un solo profesor que quiera volver a la privada. En cambio la mayoría de informáticos se están buscando un plan B.
Si aun así tienes el gusanillo de probar en el sector, haz algún proyecto de 2 meses como freelance.
Después nos cuentas.
Si lo haces por vocación y te da igual el aspecto económico, metete en algun proyecto de software libre, ve formandote por tu cuenta o empieza a desarrollar algun proyecto propio, aunque es muy dificil ganar dinero con eso si tu dedicación no es exclusiva.
Lo de CSS estaria en mi opinión más cerca del diseñador que del propio programador. Es cierto que hay que "escribir" y tener un mínimo de orden y modularidad, pero es algo independiente a las tareas de programación en si.
Yo conozco diseñadores gráficos y enmaquetadores web que no tienen ni idea de C, que mal está el sector...
"Cuando le pregunte si sabia PHP su respuesta fue algo como "va... yo se programar... en una semana le cojo el tranquillo". Esa es la mayor mentira de la programación."
Esa frase es completa, absoluta, irremediable, indistinguible, tautológica... mente cierta. Joder, que es PHP, si estuvieses hablando de un framework de la leche, programación a bajo nivel, hardware, tiempo real, multihilo... pues tendrías razón.
Pero un buen programador que se ha peleado con C, con python, caml... en una semana se sabe y entiende todos los recovecos de PHP. No por nada, sino porque en esto de la informática (tecnologías en general) las cosas grandes (como un lenguaje, llámalo PHP, JavaScript, Java, C#...) no se hacen al tuntún, sigue todo una lógica y motivación estricta y documentada. Una vez entiendes lo que hay debajo, el resto tira por lógica. Ya me dirás tu que superhack de PHP no se localiza en 2 minutos de stackoverflow...
A lo mejor lo que pasa es que tú no entiendes esa lógica que hay detrás y, como no te ves capaz de controlar un lenguaje, de alto nivel y "sencillo" como lo es PHP, en una semana, consideras que nadie puede ser más que tu.
O que la frase se ha instaurado y ya la usa gente que no debería, también puede ser que hayas tenido malas experiencias por eso.
Y claro que habra chavales o empresas outsourcing (de Sudamerica, India o China) que te lo hagan más barato, pero si tu negocio luego tiene perdidas por fallos de la aplicación o la imposibilidad de hacer cambios te vas a acordar luego de ese dinero que te has ahorrado. Lo barato al final sale caro.
Hay que empezar a educar a la gente para que reconozcan la programación como la medicina: con diferentes especialidades en las que no puedes poner a cualquiera a hacer cualquier cosa.
En serio, creo que es mejor decir que eres "desarrollador en C" que solo decir programador, por pedante que pueda sonar.
El cliente pide una funcionalidad enorme.
Le obligamos a quitar la mitad, porque el 50% de lo que pide es innecesario, y se le construye el Proyecto mínimo viable. Es decir, el core de su producto.
Una vez está el proyecto funcionando, surgen necesidades reales.
Construimos las necesidades.
NUNCA las necesidades reales que han surgido a raíz del uso del programa son las mismas que pidió al principio.
El proyecto evoluciona y según se va usando se van construyendo unas cosas u otras. ESO es agilismo. Y el problema es que el cliente tiene que estar concienciado. Por eso entre otras cosas rechazamos clientes a veces. Hay clientes con los que no puedes hacer eso, por lo que no queremos trabajar con ellos (Podemos adaptarnos un poco, si ellos lo hacen también, pero no cambiamos la filosofía de trabajo nunca).
Además de que normalmente no es "sólo" php. Hay más elementos alrededor del entorno LAMP.
Expón más tu punto de vista y podremos discutirlo.
Lo cierto es que a mi me contrataron tras usar una frase muy similar en la entrevista, y demostré que era cierta. Claro que si llego a decir "si, llevo varios años trabajando con ello" tendría más puntos, eso es indudable.
Luego el framework que quieras añadir ya es más tiempo aprendiéndolo, está claro, tampoco una exageración si has utilizado otros similares.
Luego, los lenguajes de este tipo suelen crear una comunidad con un how-to y unos estándares propios (que no obligatorios), para eso te puedes leer en un par de días alguna guía de estilo que te agrade.
Leer código php y hacer cosas, parches y modificaciones.
Para eso no te hace falta ni una hora...
Estamos hablando de tener un callo en programación y unas nociones suficientemente avanzadas de informática (estructuras de datos en memoria, como funciona un compilador/intérprete...), si no las tienes pues necesitarás más tiempo. Y por supuesto, el que lleve 5 años tiene ventaja, pero son lenguajes y técnicas de programación tan jóvenes que no tiene sentido pedirlo, es como pedir que sea uno de los diseñadores del lenguaje/framework.
Un programador experto y uno novato pueden los dos entregar un programa a simple vista parecido y que funciona. El problema es que el programa que salió barato consume mas memoria, empieza a crear registros inútiles en la base de datos, en cuanto te sales de las condiciones óptimas muestra errores, si algún usuario introduce un dato inesperado se queda colgado, cuando quieres contratar a alguien para que actualice el código se da cuenta de que el código es ilegible y tienen que escribirlo de nuevo... son problemas que uno no puede ver si solo tiene una visión a corto plazo.
Aprender a programar en papel te obliga a que vos seas el compilador y pienses mejor en lo que estás haciendo.
¿Por que pagas 50.000 eurazos (que en nuestro caso puede ser bastante mas) por un tio? ¿Que valor añadido tiene? ¿Porque las empresas meten a gente como yo y otros en plantilla? Por la fiabilidad 24/7.
Si una página se cae, el formulario no va, los frontales de admisión del módulo comercial no recogen nada, no se cargan los ficheritos del banco por X motivo... Eso paraliza TODA la empresa.
Tu dices que no generamos pasta, pero creo que obvias el echo de que a día de hoy absolutamente toda la empresa funciona con los recursos que le proporciona un buen departamento TIC, si ese no tiene personal capacitado, absolutamente ningun empleado hace nada, claro que puede haber un chacho que te apañe las cosas un día ¿Pero te jugarías la facturación de un mes a que la solución de tu sobrino el friki funciona? ¿Y si falla que? Un departamento de informatica bien coordinado trabaja con tiempos de respuesta y se conoce al dedillo toda la infraestructura montada en la empresa, son profesionales y saben donde tocar, cuando y como, te ofrecen una velocidad de respuesta que una solución amateur no puede. Y esa velocidad de respuesta es pasta que justifica con creces su salario (vasmos yo vivo de esto y te puedo asegurar que no nos pagan porque sí).
Otro le pasaba un validador de HTML (tiny, creo que se llamaba, aunque el profesor nos pasaba el Tiny y luego el validador del W3C) a los exámenes de programación web y, al más mínimo mensaje que saliese, aunque fuese un simple "warning" de algo que estuviese deprecated pero que la aplicación siguiense funcionando igualmente bien. Y lo mejor de todo es que, por lo que nos contó el propio profe, el tiny tampoco era 100% fiable y podía "missear" cosas. O sea que podía ser que nosotros estuviésemos durante el examen matándonos a pasar el tiny a cada linea nueva que poníamos, para que luego sacásemos un cero igualmente aunque hubiésemos hecho el examen bien. Tócate los cojones. Aún recuerdo cómo ese mamón se reía de nosotros en los exámenes diciendo "recordad, validad a cada segundo aunque luego no os dé tiempo de hacer ni un tercio del examen, más vale sacar un 3 que sacar un 0". Puto desgraciado de mierda.
Luego teníamos otro que, antes de cada examen, nos ponía un "pre-examen" eliminatorio (que consistía en preguntas de cualquier tema que hubiésemos hecho desde el principio del curso) obligatorio y del cual teníamos que aprobar no sé si un 70% de las preguntas bien para que el profe "nos diese permiso" para hacer el examen real, le que contaba para la nota. Si suspendíamos el "pre", el examen real no nos lo puntuaba (ni siquiera se lo miraba) y por lo tanto no teníamos nota (porque el examen eliminatorio no contaba) así que acabábamos con un "no presentado", tal como si no hubiésemos acudido a hacer el examen.
Y habían muchas más jodiendas y abusos de poder por parte del profesorado de ese centro, pero no me quiero hacer pesado porque cada dos por tres estoy dando la brasa con el mismo rollo, pero es que lo de esa puta escuela me traumatizó de por vida. Lo que más me jode es que nada de lo que hacían servía para que programases mejor o aprendieses más (lo único que podías hacer era ponerles buena cara y lamerles el culo aunque por dentro les estuvieses deseando "ojalá te reviente una vena de la cabeza, pedazo de mierda" porque como te encarases a ellos y tratases de defenderte, estabas perdido). Solo lo hacían para subir la dificultad del ciclo de forma artificial y así tener una tasa de abandono alta, y así poder ir de "mira que escuela más buena somos, se nos va mucha gente porque tenemos un nivel de enseñanza altísimo y no todo el mundo puede seguirla".
Bueno, ya he acabado, ya podeis empezar a llamarme pesado, llorón, quejica de mierda, etc, que es lo que me acaba pasando cada vez que cuento esto. Pero lo advierto desde ya, me importa una mierda lo que me digan, así que no perdais vuestro tiempo, que me va a resbalar todo
Al final los lenguajes de alto nivel simplifican lo que se hace a bajo nivel. En vez de registros, tienes variables, y ya el compilador almacenara tus variables donde tenga que hacerlo. Tu hazte un simple bucle en C y otro en ensamblador, a ver en cual lo haces mas rapido.
Otro le pasaba un validador de HTML (tiny, creo que se llamaba, aunque el profesor nos pasaba el Tiny y luego el validador del W3C) a los exámenes de programación web y, al más mínimo mensaje que saliese, aunque fuese un simple "warning" de algo que estuviese deprecated pero que la aplicación siguiense funcionando igualmente bien, nos cascaba un 0 directo.
A vale, que lo haga yo. Pensaba que decías en tiempo de proceso.