Puede parecer una pregunta razonable, pero hace algunas suposiciones terribles: líneas de código = esfuerzo, líneas de código = valor, todas las líneas de código son iguales. Nada de eso es cierto. ¿Por qué un arreglo que parece tan simple cuando se observan los cambios realizados tomó dos días para completarse?
|
etiquetas: programación , bugs 
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?
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
"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.
Pues ya llevas unos cuantos epicos, yo por lo menos me descojono, mi favorito es de los seguratas de Melbourne, dios, que grande ese.
Respuesta que los idiotas que piensan que la programación es poner datos en un Excel, suelen entender.
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.
Con poner esa, ya. Programar es una tarea de investigación.
"Otra pregunta mucho mejor sería, ¿Qué cosas has hecho para diagnosticar y solucionar este problema?".
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.
World!!!
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.
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.
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.
Antes de picar una simple línea de código piensa muy y muy bien la solución entera...
SI es un empleado tuyo o confías en él o no confías. Si confías dejale trabajar y si no despidele.
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
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.
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.
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.
infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about
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.
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.
Tornillo = 0.1 euros
Saber que tornillo tocar = 999.9 euros
// ****************************
// ** Mostramos Hola Mundo **
// ****************************
// ****************************
echo "Hola Mundo";
Ahí van 7 líneas de código. Si eso le pasa por no hacer las cosas bien
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
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.
"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.
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
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.
También todas las respuestas incorrectas y otras cosas diversas. El problema es saberlo distinguir.
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.