Portada
mis comunidades
otras secciones
#1:
La respuesta protocolaria puede variar dependiendo del entorno y la cultura de empresa, pero suele ser algo parecido a "Porque me estaba follando a tu puta madre"
#13:
#4 #6 En la realidad en la que todo va por tiempos y costes la pregunta sobre como lo has solucionado es mas importante que cuanto has tardado.
Porque yo te puedo apañar un mojon en 5 minutos para que vuelva a fallar mañana o tardar 1 dia y que jamas vuelva a fallar, ademas de documentarlo para que el siguiente que se pueda encontrar algo parecido sepa solucionarlo y no se vuelva a perder tiempo.
Pero supongo que eso es la diferencia entre metodologia de trabajo estructurada o hacer chapucillas
Porque yo te puedo apañar un mojon en 5 minutos para que vuelva a fallar mañana o tardar 1 dia y que jamas vuelva a fallar, ademas de documentarlo para que el siguiente que se pueda encontrar algo parecido sepa solucionarlo y no se vuelva a perder tiempo.
Pero supongo que eso es la diferencia entre metodologia de trabajo estructurada o hacer chapucillas
#2:
por todo el puto tiempo que tuve que asistir a reuniones inútiles donde explicaba cosas evidentes a personas incapaces de entenderlas...
#12:
#1 ¿Cómo era aquello? Henry Ford recibió una factura firmada por Charles Steinmetz por un importe de 10.000 dólares. El empresario, a pesar de agradecer el buen trabajo realizado por el ingeniero, devolvió la factura a General Electrics y solicitó una nueva y detallada. Steinmetz respondió enviando de nuevo la factura a Ford con el siguiente detalle: «Marca de tiza en el generador: 1 dólar. Saber dónde hacer la marca 9.999: dólares. Total a pagar: 10.000».
#44:
2 días estuve yo con una incidencia, de las más locas que me ha tocado vivir. Una reserva de 50€ a la cual se le aplicaron unos gastos de cancelación de millones de €. Probamos en desa: OK. Probamos en PRE: OK. Probamos en PRO con la tarjeta del jefe: OK. Irreproducible.
Repasamos los datos, debug cambio de variable a cambio de variable, reproducimos todo tal cual sucedió. Nada, sin error. Yo que solía despachar los Jiras en 2-3 horas máximo...Eso ya era personal.
Al final, cómo un jodido diamante en mi coco me viene a la mente lo único que no estábamos reproduciendo igual a cómo sucedió: el momento en el que cancelamos. Y no me refiero a la hora, si no al día.
La reserva se canceló el último domingo de marzo, ese para el que el cambio de hora le quita 60 minutos. La función que calculaba el número de noches para ese día estaba mal, ya que nos daba un día de 0'9 y pico, que con el parseInt le quitaba la parte decimal y...50/0 noches=todo lo que cabía en el jodido BigDecimal.
Al final, lo que tenía que haber sido desde un principio, tirar de función de Calendar para la diferencia de días y delegar responsabilidades. 2 líneas de código. Pero el gustazo de encontrar aquello no me lo quita nadie.
Repasamos los datos, debug cambio de variable a cambio de variable, reproducimos todo tal cual sucedió. Nada, sin error. Yo que solía despachar los Jiras en 2-3 horas máximo...Eso ya era personal.
Al final, cómo un jodido diamante en mi coco me viene a la mente lo único que no estábamos reproduciendo igual a cómo sucedió: el momento en el que cancelamos. Y no me refiero a la hora, si no al día.
La reserva se canceló el último domingo de marzo, ese para el que el cambio de hora le quita 60 minutos. La función que calculaba el número de noches para ese día estaba mal, ya que nos daba un día de 0'9 y pico, que con el parseInt le quitaba la parte decimal y...50/0 noches=todo lo que cabía en el jodido BigDecimal.
Al final, lo que tenía que haber sido desde un principio, tirar de función de Calendar para la diferencia de días y delegar responsabilidades. 2 líneas de código. Pero el gustazo de encontrar aquello no me lo quita nadie.
#4:
A mí no me parece una pregunta razonable.
De hecho, preguntar de esa manera. en muchas ocasiones simplemente es un ataque o una manera de cuestionar un trabajo. Trabajo cuestionado normalmente por alguien bastante ignorante.
La pregunta correcta es:
¿Qué has hecho para que funcione?
De hecho, preguntar de esa manera. en muchas ocasiones simplemente es un ataque o una manera de cuestionar un trabajo. Trabajo cuestionado normalmente por alguien bastante ignorante.
La pregunta correcta es:
¿Qué has hecho para que funcione?
#27:
#19 Pos mira meu, voy a intuir que me hablas de consultoria y yo ya no trabajo de consultor, soy cliente final, no tengo mucho que vender soy el responsable de sistema peeero la diferencia de que te llamen especificamente a ti (y paguen una tarifa de consultor senior especializado carilla que va a ser al final lo que usarás tu para justificar tu sueldo a la consultora) y no a otro, pasa por demostrarle al cliente que solo te tienen que llamar una vez para las cosas y se quedan solucionadas de manera medianamente elegante, estable y documentada. 12 años de consultor estuve en base a esa premisa y es lo que suelo exigir cuando tenemos que depender de proveedores externos. No somos Google.
#45:
#19 #27
Bueno, no todo es Google, pero a partir de cierta experiencia uno empieza a encontrarse empresas que no son cárnicas.
Luego cada uno acepta o rechaza lo que quiere, yo cobro aceptable para mi ciudad, pero podría cobrar un 20% más en una cárnica, controlando a panaderos que pican código (cosa que rechace).
La realidad, he llegado a echar 20 líneas de código en una semana y ser felicitado.
La razón? Una persona se pegó un mes para hacer lo mismo, metió código en muchas partes y muy fragmentado y no consiguió que funcionara.
Desde entonces pierdo entre una y dos horas diarias resolviendo problemas de terceros que no tienen nada que ver con mis proyectos.
Al final toda empresa quiere un programador lento, pero que su código no reviente en producción y que el novato que venga detrás, entienda.
Si además no es un puto borde, nadie le va a poner peros a su velocidad.
Bueno, no todo es Google, pero a partir de cierta experiencia uno empieza a encontrarse empresas que no son cárnicas.
Luego cada uno acepta o rechaza lo que quiere, yo cobro aceptable para mi ciudad, pero podría cobrar un 20% más en una cárnica, controlando a panaderos que pican código (cosa que rechace).
La realidad, he llegado a echar 20 líneas de código en una semana y ser felicitado.
La razón? Una persona se pegó un mes para hacer lo mismo, metió código en muchas partes y muy fragmentado y no consiguió que funcionara.
Desde entonces pierdo entre una y dos horas diarias resolviendo problemas de terceros que no tienen nada que ver con mis proyectos.
Al final toda empresa quiere un programador lento, pero que su código no reviente en producción y que el novato que venga detrás, entienda.
Si además no es un puto borde, nadie le va a poner peros a su velocidad.
#9:
En ese caso se borran la líneas, se guarda, se cierra el fichero y se le dice: tienes 3 días para hacerlo, suerte (probablemente desconozca el control de versiones)
Comentarios
La respuesta protocolaria puede variar dependiendo del entorno y la cultura de empresa, pero suele ser algo parecido a "Porque me estaba follando a tu puta madre"
#1 contratado!!! Lástima que mi empresa no sea de informática.
#10 No acepto ofertas de trabajo asi al tun tun, soy un profesional bastante demandado en mi campo y necesito una foto de tu madre primero
#14 Últimamente estás on fire ioputa!!!
#17 Lo que estoy es aburrido como una puta ostra haciendo tiempo pa cerrar chiringuito, q los usuarios estan de vacas y aqui no contesta ni dios
#18
Pues ya llevas unos cuantos epicos, yo por lo menos me descojono, mi favorito es de los seguratas de Melbourne, dios, que grande ese.
#20 ¿Podría indicarme o mostrarme ese épico desbarre del señor Skaworld? Siento curiosidad por saber de los seguratas de Melbourne.
#18 Pues los míos están todos dando faena. Que se piren joder.
#17
#14 Amos que tiene que ser de MILF para arriba... A ver si así hay suerte.
#14 jajajajaj no esperaba menos de tí.
#34 AAAAA que alguien me saque los ojos!!!
#57
#34 eso sustituirá a la ballena en mis pesadillas.........dios santo......
#14 es un campo de remolachas?
#1 ¿Cómo era aquello? Henry Ford recibió una factura firmada por Charles Steinmetz por un importe de 10.000 dólares. El empresario, a pesar de agradecer el buen trabajo realizado por el ingeniero, devolvió la factura a General Electrics y solicitó una nueva y detallada. Steinmetz respondió enviando de nuevo la factura a Ford con el siguiente detalle: «Marca de tiza en el generador: 1 dólar. Saber dónde hacer la marca 9.999: dólares. Total a pagar: 10.000».
#12 off topic Me hubiera gustado saber cómo se las arregló Steinmetz para localizar este fallo sin destripar el bobinado. En esta época no había frecuencímetros, ni osciloscopios ni sondas de temperatura ni... Claro que era un genio. Y lo valía, porque sino este generador habría acabado averiándose.
#12 #73 He escuchado tantas versiones diferentes y hasta contradictorias de esa misma anécdota que empiezo a dudar de que realmente llegase a suceder...
#90 Yo la escuché con un tornillo.
Apretar tornillo, un dolar, saber qué tornillo apretar, 9.999.
#73 Teniendo la palabrita magica ya tienen los lo mas dificil, con una palabra tan precisa es facil busca y tener resultados.
https://www.meneame.net/search?q=steinmetz
#68 Para cosas que necesiten hora no se deberia usar UTZ? que siempre es la misma sea verano o invierno y en todo el mundo. Luego se añade la diferencia horaria local.
#44
#69 En un articulo de prensa, para la misma cantidad de texto puede haber mucha diferencia de investigación, para sacar una foto puede hacer falta viajar a otro continente y esperar horas o dias para encontrar el momento.
Para cambiar una pieza a veces hace falta desmontar medio motor para llegar a ella. Para limpiar el ventilador del portatil yo he tenido que desmontarlo entero.
#60 Hay salido unos cuanto ejemplo en meneame a lo largo del tiempo, que gente que hay automatizado una tarea y han sido despedidos no por vagos, sino porque su tarea ya no hace falta que lo haga él.
Toda buena accion sera convenientemente castigada.
#91 UTC
#12 Go to #3
#1 Y la reaccion a esa respuesta variara segun el tiempo que hayas tardado en escribir esa linea.
#48 Es un poco el concepto de TDD, no? Piensa primero en lo que es necesario, crea el número de tests correcto para que los UACs cumplan su cometido. Ahora simplemente, una vez comprendido el problema, haz el mínimo código necesario para que esos tests pasen.
Recuerdo una vez que estuve una puta semana con legacy code para un tema de OAuth entre diferentes aplicaciones dantescas de un monstruo de empresa que llevaba con ese código la tira de años... una puta semana... creo que la solución fueron 8 líneas de código. 0 bugs en producción. Nadie me preguntó por qué había tardado tanto. Ahora escucho esas putas preguntas del CEO constantemente, "why would you spend so much time?" Respuesta --> #1
por todo el puto tiempo que tuve que asistir a reuniones inútiles donde explicaba cosas evidentes a personas incapaces de entenderlas...
#2
#2 como persona incapaz de entenderlas te aviso de que me has ofendido
#40 Si eres incapaz de entender lo que dicen tus subordinados entonces no deberías estar en ese puesto...
#50 yo estoy enchufado
#62 Era obvio en cuanto soltaste "incapaz de entender"
#2 A parte de la broma, también te puedes llevar dos días para quitar una línea (caso real), pero claro hasta que llegas a la conclusión de que eso es lo que hay que hacer y no poner 100 líneas nuevas y que además al solucionar tu problema no creas 20 nuevos pues...
A mí no me parece una pregunta razonable.
De hecho, preguntar de esa manera. en muchas ocasiones simplemente es un ataque o una manera de cuestionar un trabajo. Trabajo cuestionado normalmente por alguien bastante ignorante.
La pregunta correcta es:
¿Qué has hecho para que funcione?
#4 en los mundos de yupi si, en la realidad en la que todo va por tiempos y costes no.
#4 #6 En la realidad en la que todo va por tiempos y costes la pregunta sobre como lo has solucionado es mas importante que cuanto has tardado.
Porque yo te puedo apañar un mojon en 5 minutos para que vuelva a fallar mañana o tardar 1 dia y que jamas vuelva a fallar, ademas de documentarlo para que el siguiente que se pueda encontrar algo parecido sepa solucionarlo y no se vuelva a perder tiempo.
Pero supongo que eso es la diferencia entre metodologia de trabajo estructurada o hacer chapucillas
#13 suerte vendiéndole esa moto a la mayoría de empresas, no hay tantas google que valoren eso, es triste si, pero es lo que hay, por eso la referencia a los mundos de yupi.
#19 Pos mira meu, voy a intuir que me hablas de consultoria y yo ya no trabajo de consultor, soy cliente final, no tengo mucho que vender soy el responsable de sistema peeero la diferencia de que te llamen especificamente a ti (y paguen una tarifa de consultor senior especializado carilla que va a ser al final lo que usarás tu para justificar tu sueldo a la consultora) y no a otro, pasa por demostrarle al cliente que solo te tienen que llamar una vez para las cosas y se quedan solucionadas de manera medianamente elegante, estable y documentada. 12 años de consultor estuve en base a esa premisa y es lo que suelo exigir cuando tenemos que depender de proveedores externos. No somos Google.
#19 #27
Bueno, no todo es Google, pero a partir de cierta experiencia uno empieza a encontrarse empresas que no son cárnicas.
Luego cada uno acepta o rechaza lo que quiere, yo cobro aceptable para mi ciudad, pero podría cobrar un 20% más en una cárnica, controlando a panaderos que pican código (cosa que rechace).
La realidad, he llegado a echar 20 líneas de código en una semana y ser felicitado.
La razón? Una persona se pegó un mes para hacer lo mismo, metió código en muchas partes y muy fragmentado y no consiguió que funcionara.
Desde entonces pierdo entre una y dos horas diarias resolviendo problemas de terceros que no tienen nada que ver con mis proyectos.
Al final toda empresa quiere un programador lento, pero que su código no reviente en producción y que el novato que venga detrás, entienda.
Si además no es un puto borde, nadie le va a poner peros a su velocidad.
#45 la velocidad te la aportan los años y ser metodico, a base de encontrar problemas y la solución óptima vas puliendo tu velocidad a medida que los vas aprendiendo a sortear, pero para aprender a hacerlo bien al principio necesitas tiempo (y si la cosa es nueva más tiempo)
Pero repito... Un cliente al q le chulees con errores o espaguetis no va a llamarte específicamente, uno que ve el trabajo más o menos bien si, y mi experiencia en ese mundillo fue que me la suda el objetivo de la empresa, mi objetivo es que el cliente me vuelva a solicitar específicamente. A lo largo de mi carrera tuve más de 20 empresas que me pedían por mi nombre y nunca he estado desasignado gracias creo a eso, a largo plazo compensa
#19 Cada día son más, y por norma general tienen más éxito. Los mundos de yupi eran hace 15 años, ahora los mundos de yupi son creer que la forma de trabajar más adecuada es la anterior de hacer la ñapa más rápida para salir del paso y tardar casi el mismo tiempo en hacerla que en explicársela a un jefe que no hace gestión porque está muy ocupado haciendo microgestion de los empleados. Y son los mundos de yupi porque cuando esa empresa caiga solo tendrás en el currículum "experto en ñapas", y las Googles que ya te digo que cada día son más tienen grandes exigencias de nivel técnico, pero les importa poco que sepas justificarte al jefe porque sus jefes gestionan el proyecto de verdad, no hacen de perros guardianes de los programadores
#52 son mas, ¿son la mayoría? ¿son capaces de absorber la fuerza de trabajo creciente en el sector? porque esto es como el dinero, que 4 privilegiados puedan vivir de rentas no nos convierte en un país de millonarios.
#55 En el mundo en el que me muevo si, son mayoría. Incluso conozco a gente de consultoras que ya no usan el método antiguo, aunque en las consultoras siempre va a haber jefes jerárquicos mirando lo que hacen los programadores, algunas ya los han apartado de la microgestion. En España, colapsada por las consultoras, el cambio está siendo más lento. Pero en algún momento tendrán que plantearse por qué cada vez son menos competitivos.
Lo que digo es que es un tipo de trabajo en extinción, que los dinosaurios que se han pasado 15/20 años en una o dos de esas consultoras se creen que no hay otra forma de trabajar, pero son ellos los que están obsoletos y en mayor riesgo de quedarse fuera del mercado.
#13 Peor aún arreglar un desastre de bug sin cambiar una línea de código, dejar a los desarrolladores mascadita la solución definitiva y tener después que explicar en comité por qué los servidores funcionan tan mal y la aplicación falla. Palabra de BOFH
#21 No te equivoques. Los servidores no funcionan mal porque los desarrolladores sean unos inútiles. Entienden que el problema de rendimiento es por diseño y no por carga tanto como tú.
El problema es que lo que era una prueba de concepto medio copiada de stackoverflow se acaba convirtiendo en lo que va a producción porque "total, solo es el MVP y tiene que estar listo mañana, en la actualización del siguiente sprint lo corregiremos". Y obviamente no.
#72 No en varios casos que me han tocado. Ese caso es de desarrollador inútil, que no sabe copiar de stackoverflow. Entonces resulta que allí donde su brillante hilo recién creado ha de usar un pool común de conexiones, crea un nuevo pool de conexiones para ese hilo. Agregue carga de producción al sistema y se quedará sin puertos de conexión. "La culpa es de los de sistemas que le ponen pocos puertos al linux para que la aplicación falle". Que algunos no entienden de herencia más allá del pantalón que les dejó su hermano.
#77 Pues sí, en ese caso si es de inútil.
Aun así, si eso no te pasa también con tus juniors es (seguramente) porque apenas tendrás (es un puesto con muchísima menos rotación).
Entiendo que pasen ese tipo de cosas cuando la empresa necesita un senior pero no puede pagarlo y prefieres contratar 3 chiquillos recién salidos del ciclo superior que no saben ni lo que es la recursividad porque te cuesta igual y son 3
#79 Hay miles de escenarios. En el caso que te cuento lo más triste es que son seniors, project leads y demás. Gente capaz de llegar a Director de Proyectos o a la quiebra de la empresa, lo primero que ocurra
#80 Yo eso estoy más acostumbrado a verlo en la parte de gestión de equipos.
En el lado técnico lo que me da la sensación que abunda entre la gente con experiencia es un ego tremendo, que se acaba traduciendo en una interminable concatenación de huidas hacia delante.
#84 En el lado técnico lo que me da la sensación que abunda entre la gente con experiencia es un ego tremendo
"Los hijos de uno nunca son feos". Y ya está, que corrija otro, que a mí me da la risa porque mi parte esta bien.
#79 En cuanto a rotación, estuve en una empresa donde los sysadmin salían corriendo a los seis meses; cada año dos rotaciones completas. La gente hablaba de uno que duró casi dos años allí con rango de leyenda
#6 En esa realidad lo importante no es que sean dos líneas sino que resuelva un problema.
#31 si tu empresa vende una solución a 6 meses vista y tu necesitas 1 año para desarrollarla en condiciones, mas te vale ser un lince convenciendo a tu jefe de ello, que al fin y al cabo es a lo que se refiere el envío.
#35 No, habla de que lo entregas en 6 meses pero hay muy pocas líneas.
Incluso en tu caso. ¿Qué es más caro que entregar un proyecto 6 meses tarde? Entregar la tiempo pero lleno de errores y tener que afrontar las consecuencias de dichos errores.
Por otra parte, si se vendió un proyecto a 6 meses vista y tarda un año, el primer sospechoso es el que lo vendió. Si no tienes capacidad de reacción ante retrasos, no asumas compromisos que puedan retrasarse.
En ese caso se borran la líneas, se guarda, se cierra el fichero y se le dice: tienes 3 días para hacerlo, suerte (probablemente desconozca el control de versiones)
2 días estuve yo con una incidencia, de las más locas que me ha tocado vivir. Una reserva de 50€ a la cual se le aplicaron unos gastos de cancelación de millones de €. Probamos en desa: OK. Probamos en PRE: OK. Probamos en PRO con la tarjeta del jefe: OK. Irreproducible.
Repasamos los datos, debug cambio de variable a cambio de variable, reproducimos todo tal cual sucedió. Nada, sin error. Yo que solía despachar los Jiras en 2-3 horas máximo...Eso ya era personal.
Al final, cómo un jodido diamante en mi coco me viene a la mente lo único que no estábamos reproduciendo igual a cómo sucedió: el momento en el que cancelamos. Y no me refiero a la hora, si no al día.
La reserva se canceló el último domingo de marzo, ese para el que el cambio de hora le quita 60 minutos. La función que calculaba el número de noches para ese día estaba mal, ya que nos daba un día de 0'9 y pico, que con el parseInt le quitaba la parte decimal y...50/0 noches=todo lo que cabía en el jodido BigDecimal.
Al final, lo que tenía que haber sido desde un principio, tirar de función de Calendar para la diferencia de días y delegar responsabilidades. 2 líneas de código. Pero el gustazo de encontrar aquello no me lo quita nadie.
#44 Y lo peor es que nadie medio importante valora/comprende todo ese esfuerzo...
#44 Los bugs relacionados con el tiempo son todo un clásico. Me has recordado esta lista de pifias relacionadas:
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
#44 ¿Qué lenguaje es ese que no te da una excepción de formato al parsear 0.9 como entero y, especialmente, ninguna excepción al dividir por cero?
Porque es legacy code y me ha costado 2 dias entenderlo para encontrar el lugar correcto donde poner esas 2 puñeteras lineas
#7 Pero ese código hace 1 mes era El brand new code que refactorizaba el legacy code anterior
#15 SI hay que explicarte como se solucionan bugs estás haciendo perder el tiempo a quien tiene que solucionarlos.
SI es un empleado tuyo o confías en él o no confías. Si confías dejale trabajar y si no despidele.
#49 fíjate hasta que punto las cosas no son así que existe ese articulo, y ni siquiera es español (por aquello del empresauriado patrio), y poco te costará encontrar en este mismo sitio experiencias de primera mano que no van por el camino que indicas, repito que la realidad ≠ mundos de yupi.
Porque esto es una puta mierda hecha por monos de feria borrachos y debes dar gracias a dios que yo pueda entender como funciona por dentro ya que no se lo deseo ni a tu persona que vivas esta maldita experiencia atroz.
1 minuto para apretar el tornillo, 8 horas para encontrar el tornillo a apretar.
Respuesta que los idiotas que piensan que la programación es poner datos en un Excel, suelen entender.
Me compadezco del pobre que tenga de PO/PM a alguien que hace ese tipo de preguntas. Que en 2020 aún se sigan haciendo... Y no es cuestión de no saber por qué las cosas llevan un tiempo u otro, es cuestión de confianza en el equipo y en tu gente. Si haces esa pregunta, automáticamente estás socavando un poco la confianza.
#23 Está bien que se hagan las preguntas pero el asunto es como se preguntan las cosas. "Solo has añadido dos líneas, ¿por qué has tardado dos días en hacerlo?" es una mala pregunta. Demuestra lo poco que se valora el trabajo y al trabajador y lo mucho que se desconoce acerca del entorno.
"Otra pregunta mucho mejor sería, ¿Qué cosas has hecho para diagnosticar y solucionar este problema?".
#36 otra pregunta sería: "¿Cuál era el problema?" y te contesten, "No se, pero con esas líneas funciona".
Recuerdo una vez trabajar 4 horas para cambiar un 3 por un 4 por un error. Era código de otra empresa, que me dieron porque les fallaba. Después de corregirlo, les mandé el código de nuevo para cargarlo en su repositorio, y un ticket de 4h de trabajo. De hecho creo que directamente les dije que hicieran el cambio ellos depués de probarlo yo en mi equipo.
Por suerte era una empresa decente, que entiende que hay que saber que ese cambio arregla el problema, que el cambio estaba comprobado que funcionaba y que no provocará otros fallos. Eso y que era una empresa con grandes proyectos abiertos pocos problemas económicos.
// ****************************
// ****************************
// ** Mostramos Hola Mundo **
// ****************************
// ****************************
echo "Hola Mundo";
Ahí van 7 líneas de código. Si eso le pasa por no hacer las cosas bien
#78 eso fallaría. No cierras /* con */ no?
solucionar el problema 5 minutos, encontrar el problema 1 hora, explicar porque he tardado una hora y 5 minutos al $boss 50 minutos.
E=mc2 son solo 3 letras.
Por qué se tardamos milenios en darnos cuenta?
A la persona que pregunta habría que despedirla ipso facto. Sólo alguien muy ignorante puede evaluar el conocimiento por volumen de símbolos.
#46 Has encapsulado todo el envío en una frase.
Como pequeño chascarrillo, cómo se enfrentan los futuros ingenieros, físicos y matemáticos a la prepotente frase de los libros o profesores de matemáticas "dejamos la demostración como ejercicio para el lector":
- Ingeniero: corre un programa de ordenador a fuerza bruta, encuentra el patrón y se queda con la intuición que da el mismo.
- Físico: "¿qué he de demostrar? "
- Matemático: "Bah, para otro día". Al siguiente día, sale en lista de ejercicios para entregar.
#46 La respuesta está contenida en los decimales de Pi.
También todas las respuestas incorrectas y otras cosas diversas. El problema es saberlo distinguir.
Por desgracia, hasta que no llevamos un tiempo desarrollando o en un puesto cercano al desarrollo no nos damos cuenta de que escribir código es lo de menos.
Vas a pasar más tiempo leyendo código que escribiéndolo. Vas a pasar más tiempo testeando que escribiendo código. Vas a pasar más tiempo documentando que escribiendo código.
Además, darle importancia al número de líneas cuando en los lenguajes de alto nivel de hoy en día una simple variable puede ser una función que contenga toda la aplicación es simplemente ser ignorante.
#69 estoy de acuerdo en casi todo, en londr documentar, según mi experiencia soy el único que documenta en mi empresa
Porque tienes que hacer 50K millones de pruebas, 200 GTest, 500 GMocks y mientras haces todo esto haces un git pull y te bajas código nuevo y tienes conflictos, o sacas la recortada y vas disparando contra compañeros y colaboradores o te tiras unas cuantas horas más. Según qué entornos los tiempo son 5% programando, 95% creando las pruebas y luchando contre el entorno del sistema.
#29 en mi trabajo 5 minutos programando 55 esperando que la máquina responda. Así durante ocho horas
#74 Para mi esas situaciones son desesperantes.
#81 imagina mi ánimo. Si no fuera por la pandemia estaría buscando otro trabajo
#83 No te llegas imaginar lo de acuerdo que estoy contigo.
#92 eres compañero mío?
#93
No.
#95 como lo sabes?
#83 ¿Y porqué no estás buscando otro trabajo YA? Que la mayoría de las empresas (serias) empiezan a ofrecer 100% remoto.
#97 no es por eso, no me veo haciendo entrevistas ahora
#74 Trabajar con máquinas con menos recursos (memoria, micro...) es algo desesperante y que además le cuestan una pasta a la empresa; es algo que no puedo llegar a entender.
"Pero si es solo un botón"
#22 ay, la clásica con el de UX, que el tarda 2 segundos en añadir algo al diseño y los programadores tardan horas, o días.
#24 Ayyy, el UI/UX
#22 viví un "it's just a form!" en el que hubo que invertir unas 10 personas durante 6 u 8 meses.
Relacionada: http://menea.me/129e
Por la misma razón por la que un cohete espacial que vale millones se puede ir al carajo por solo una línea de código.
Es de lo primero que me enseñaron cuando era junior. No tengas prisa a coger el teclado.
Antes de picar una simple línea de código piensa muy y muy bien la solución entera...
Mi máximo para añadir un par de líneas fué un mes.
Contexto: el programa de control de caja de cierto banco, que impreso en una pila de papel tenía 85 cm de altura. Escrito mitad PL1 y mitad en assembler.
Nadie sabía lo que hacia ese monstruo, por lo que sus sucesivas modificaciones habían complicado aún más entender que pasaba ahí dentro. Las modificaciones solían consistir en un goto hacia nuevo código que hacia la cosa nueva y luego otro goto a donde se supone que hay que estar cuando se ha acabado. Así el código antiguo seguía vivo por si había que volver a él. Ahora hay que imaginar la modificación de una modificación de una modificación. Muy bonito todo.
La mayor parte del tiempo estuvo dedicada a asegurarse de que no se rompía nada más.
#15 El problema es cuando dices que te va a llevar 2 o 3 días, subes lo que has hecho y es pasar de true a false una mierda y te dicen que como has podido tardar 3 días en eso, que menuda tocada de huevos y eso pasa el 99% de las veces porque tu jefe no es programador.
#51 O estar una semana intentando replicar un bug y que no salga, y al final es que el cliente tiene las mayúsculas puestas y el soft distingue entre mayúsculas y minúsculas, y te dice.. ahh, es que el password lo tengo todo en mayúsculas y por eso las dejo puestas. El bug es una tontería pero cuando no puedes ni replicarlo es un infierno.
"Because I took the time to investigate the real cause of the issue, not just looking at the symptoms"
Con poner esa, ya. Programar es una tarea de investigación.
#30 Muchas veces yo le llamo arqueología de código.
Las profesiones científicas son así. El que no entiende y lo ve desde fuera cree que si un tío está 8 horas al día pulsando como un loco un botón según van cambiando unas luces, está trabajando duro y bien. Sin embargo una persona brillante puede que esté durante un mes sentando, pensando y haciendo cálculos para optimizar esa tarea, y al final resulta que con las dos líneas que ha creado se multiplica por 100 la productividad, y de una forma muy sencilla. Obviamente esto en una empresa española sería motivo de despido, le echarían por vago.
Este tipo de optimizaciones es muy habitual en matemáticas, un ejemplo sería el de la multiplicación, que con una simple operación de cuatro líneas se ahorran cientos de sumas, y se reduce cientos de veces el tiempo en realizarlas y la posibilidad de equivocarse.
Cuando sucede eso hay que, al menos, informar que la solución va a llevar un tiempo.
#5 El tiempo en arreglar un bug no se puede saber de antemano.
#11 "Because the issue was reported with a vague description of how to recreate it."
"Because the reported issue was related to functionality, I'm not familiar with."
"Because I investigated if there were other ways of getting to the same problem, not just the reported reproduction steps."
"Because I took the time to verify if there were other parts of the code that might be affected in similar ways."
A no ser que se sea una persona que va dando bandazos y funcione con el prueba y error, con eso que se indica se sabe que se va a tardar un tiempo, no digo que sepa exactamente que va a tardar 2 días, pero seguramente sabia que no era cosa de media hora.
Por aquí arriba han comentado lo de explicar cosas a gente que no las entiende, cuando en un equipo/empresa el único que sabe de que va el tema y consideras que los demás no entienden lo que intentas explicar, el problema eres tu, no el resto del mundo, averigua como hacerte entender.
El código más horrible que tuve que trabajar era uno en el que tardaba media hora en compilar.Cada vez que cambiabas una linea tenías que esperar meida hora para mostrarte los errores de compilación.
Yo a veces le dejo a deber a la empresa. Despues de dos semanas de desarrollo, el codigo acaba con 200 líneas menos.
Más de una vez he publicado partes grandes de código que al final era una mala solución y sabía que lo iba a desechar, para a continuación publicar el bueno
¿Sólo dos días?, ¿cuantos test cases tenía? Lo mismo hasta fue demasiado rápido.
Un problema con esto es que un compañero chapucero puede presentar una solución en la mitad de tiempo y modificando cien líneas, aunque no haya entendido bien lo que estaba tocando y deje un pufo a futuro. Pues este tío, para muchos jefes, es lo más.
#1Pues nada. Se revisa otra vez un poco el código, se cambian dos lineas bien elegidas sin documentar ni comentar los cambios y se le devuelve al listo de turno diciendole que haber cuanto tarda el en arreglarlo.
Porque para que un avión funcione todo tiene que estar perfectamente calibrado, pedazo de subnormal.
Hello
World!!!
Joder, esto está lleno de programadores !!!. A mi siempre me ha parecido una tontería equiparar el número de líneas con el trabajo realizado, hay gente que programa una línea sí y otra no para verlo más claro, ¿qué trabaja el doble ?. Además no hace falta que sean dos líneas, que falte una coma ya vale para joder un proyecto entero....
Total factura = 1000 euros
Tornillo = 0.1 euros
Saber que tornillo tocar = 999.9 euros