Portada
mis comunidades
otras secciones
#10:
Debería haber una asignatura que enseñara a usar un buscador.
Hoy en día es mas importante saber hacer la pregunta que conocer la respuesta. Si sabes preguntar correctamente la respuesta la tienes casi siempre a un par de clics.
Yo flipo con la de compañeros de trabajo que pierden media mañana en un problema que se solucionaba haciendo una búsqueda de 4 palabras clave en el Google.
Al principio me daba vergüenza hacerlo pero ahora ya no, si alguien me viene con una pregunta que no sé responder inmediatamente hago la búsqueda en Google, con él delante, y en la mayoría de las ocasiones leemos la respuesta juntos en el primer o segundo enlace.
La mayoría se lo toman bien, aunque a algunos les da una risa histérica y otros tantos te dicen que has tenido suerte (y eso que nunca uso ese botón! )
Hoy en día es mas importante saber hacer la pregunta que conocer la respuesta. Si sabes preguntar correctamente la respuesta la tienes casi siempre a un par de clics.
Yo flipo con la de compañeros de trabajo que pierden media mañana en un problema que se solucionaba haciendo una búsqueda de 4 palabras clave en el Google.
Al principio me daba vergüenza hacerlo pero ahora ya no, si alguien me viene con una pregunta que no sé responder inmediatamente hago la búsqueda en Google, con él delante, y en la mayoría de las ocasiones leemos la respuesta juntos en el primer o segundo enlace.
La mayoría se lo toman bien, aunque a algunos les da una risa histérica y otros tantos te dicen que has tenido suerte (y eso que nunca uso ese botón! )
#7:
... Después de darle muchas vueltas, probé a detener el servicio "Microsoft Reporting Services", y el error dejó de producirse. El tipo dijo: "¿Pero por qué ese servicio trata de conectarse a SQL Server? No lo entiendo", a lo cuál le respondí con otra pregunta: "¿Usas el servicio de Reporting Services o lo vas a usar en un futuro?". "No" - respondió. "Entonces me da igual saber por qué trata de conectarse, dejamos el servicio apagado y problema solucionado"...
That's the Microsoft way!
That's the Microsoft way!
#5:
Hay que empezar por el principio:
¿Ha probado a apagar y encender?
¿Ha comprobado que está correctamente conectado?
¿Ha probado a apagar y encender?
¿Ha comprobado que está correctamente conectado?
#12:
Doy fe de la veracidad del punto 10. Yo suelo llamar a la última hora de la jornada la hora tonta porque después de todo el día programando no doy más de mí. Siempre que puedo la dedico a tareas que requieren poco esfuerzo intelectual. Muchas veces me ha pasado volverme loco buscando un bug y al día siguiente resolverlo en apenas 5 minutos.
Por otra parte el punto 5 me parece peligroso. El hecho de solucionar un problema sin averiguar su causa puede hacer que vuelva a aparecer en cualquier momento.
Por otra parte el punto 5 me parece peligroso. El hecho de solucionar un problema sin averiguar su causa puede hacer que vuelva a aparecer en cualquier momento.
#30:
Ante todo empieza por los metodos mas faciles y si fallan, pasa a lo dificil.
En una ocasión tuve que ir a un buque portacontenedores al que le fallaba la automatización, esto es, el sistema que coordina el sistema de control de velocidad del buque con la sala de máquinas y el motor del barco. Tras unos chequeos iniciales confirmé que, efectivamente, no recibía en puente el feedback de velocidad del motor.
Como llevaba tarjetas de recambio del sistema(placa madre, placa de proceso, placa frontal) me dije que iria cambiando los componentes hasta que diera con el componente que fallaba. Una vez lo encontrara, se dejaba la tarjeta nueva y santas pascuas. El encontrar el fallo concreto ya es cosa del fabricante.
El caso es que cambiar estas tarjetas, debido a como esta instalado el sistema en el cuadro cuesta mas que hablar con Diós. Cambié una tarjeta y nada. Cambié otra y nada. Cambié la tercera y nada. Vaya, tal vez el problema esté en el sistema de cámara de máquinas (que es gemelo al de puente, y usa las mismas tarjetas). Pues nada, a desmontar las tarjetas nuevas y dejar las originales, que, a priori, funcionan bién.
Para resumir, en cámara de máquinas se repitió la misma historia, y ya eran las 3 de la madrugada y tenía 200 km hasta casa. Así que le dije al jefe de máquinas que mas se perdió en Cuba y que mañana más.
Al día siguiente bien tempranito(estos barcos no suelen estar en puerto mas de 24 horas) vuelvo al barco. Y me pongo a pensar. Y reconstruyo mentalmente todo el recorrido de la señal de velocidad desde los tacómetros en la rueda inercial del motor al actuador, de ahí al regulador y de ahí via comunicación serie hasta la automatización.
Y en eso que me pongo a repasar los cables en cuadro de cableado tras la cabina de cámara de máquinas, busco el cable concreto en el bornero y todo parece estar en orden, cojo el cable en cuestión, le doy un pequeño tirón... y se sale del bornero!!!.
El puto cable estaba suelto y era lo que estaba produciendo todo el problema, para cuya resolución solo necesité un puñetero destornillador.
Moraleja: El primer paso para resolver el problema no necesita herramientas. Consiste en pensar.
En una ocasión tuve que ir a un buque portacontenedores al que le fallaba la automatización, esto es, el sistema que coordina el sistema de control de velocidad del buque con la sala de máquinas y el motor del barco. Tras unos chequeos iniciales confirmé que, efectivamente, no recibía en puente el feedback de velocidad del motor.
Como llevaba tarjetas de recambio del sistema(placa madre, placa de proceso, placa frontal) me dije que iria cambiando los componentes hasta que diera con el componente que fallaba. Una vez lo encontrara, se dejaba la tarjeta nueva y santas pascuas. El encontrar el fallo concreto ya es cosa del fabricante.
El caso es que cambiar estas tarjetas, debido a como esta instalado el sistema en el cuadro cuesta mas que hablar con Diós. Cambié una tarjeta y nada. Cambié otra y nada. Cambié la tercera y nada. Vaya, tal vez el problema esté en el sistema de cámara de máquinas (que es gemelo al de puente, y usa las mismas tarjetas). Pues nada, a desmontar las tarjetas nuevas y dejar las originales, que, a priori, funcionan bién.
Para resumir, en cámara de máquinas se repitió la misma historia, y ya eran las 3 de la madrugada y tenía 200 km hasta casa. Así que le dije al jefe de máquinas que mas se perdió en Cuba y que mañana más.
Al día siguiente bien tempranito(estos barcos no suelen estar en puerto mas de 24 horas) vuelvo al barco. Y me pongo a pensar. Y reconstruyo mentalmente todo el recorrido de la señal de velocidad desde los tacómetros en la rueda inercial del motor al actuador, de ahí al regulador y de ahí via comunicación serie hasta la automatización.
Y en eso que me pongo a repasar los cables en cuadro de cableado tras la cabina de cámara de máquinas, busco el cable concreto en el bornero y todo parece estar en orden, cojo el cable en cuestión, le doy un pequeño tirón... y se sale del bornero!!!.
El puto cable estaba suelto y era lo que estaba produciendo todo el problema, para cuya resolución solo necesité un puñetero destornillador.
Moraleja: El primer paso para resolver el problema no necesita herramientas. Consiste en pensar.
Comentarios
Debería haber una asignatura que enseñara a usar un buscador.
Hoy en día es mas importante saber hacer la pregunta que conocer la respuesta. Si sabes preguntar correctamente la respuesta la tienes casi siempre a un par de clics.
Yo flipo con la de compañeros de trabajo que pierden media mañana en un problema que se solucionaba haciendo una búsqueda de 4 palabras clave en el Google.
Al principio me daba vergüenza hacerlo pero ahora ya no, si alguien me viene con una pregunta que no sé responder inmediatamente hago la búsqueda en Google, con él delante, y en la mayoría de las ocasiones leemos la respuesta juntos en el primer o segundo enlace.
La mayoría se lo toman bien, aunque a algunos les da una risa histérica y otros tantos te dicen que has tenido suerte (y eso que nunca uso ese botón! )
#10 Supongo que ya la conoces pero esta página es crema: lmgtfy.com
#14 No no no, el problema no es que no sepan que deben usarlo sino que usándolo son incapaces de encontrar lo que buscan.
Hace falta enseñar a buscar.
A elegir las palabras clave, a usar palabras negativas para excluir resultados inútiles, a buscar en dominios específicos para casos concretos. Si quieres la solución oficial microsoft añade el site:microsoft.com, por ejemplo.
A descartar resultados con un vistazo, por ejemplo no es lo mismo clicar en un foro de Java, que en una página tipo experts-exchange o en la página de ayuda de office de Microsoft.
Cada enlace te dará un enfoque al mismo problema y sin clicar ya deberías saber si ahí puede o no estar la respuesta.
#15 Y fundamental, no buscar en español...
#14 #15 #21 Y si encuentras un enlace a páginas del estilo StackOverflow, es altamente probable que des con la solución
#10 Siempre fue más difícil saber la pregunta que conocer la respuesta ( http://es.wikipedia.org/wiki/El_sentido_de_la_vida,_el_universo_y_todo_lo_dem%C3%A1s )
Por el lado serio, el artículo me parece un desastre. Toda una oda a la magia negra como forma de resolución de problemas.
En los sistemas razonablemente bien diseñados es tan fácil descubrir la causa de los problemas como solucionarlos.
Además, al descubrir la causa del problema vas aprendiendo cómo funciona todo, para comprender toda una nueva clase de potenciales problemas nuevos. Si solucionás un bug sólo bajando servicios al azar, perdiste tiempo, solucionaste, pero no aprendiste nada que te ahorre tiempo en el futuro.
Hay que empezar por el principio:
¿Ha probado a apagar y encender?
¿Ha comprobado que está correctamente conectado?
#5 ¿Has probado de darle unos golpecitos?
#5 Hay que empezar por la primera ley: "Funciona mejor si lo enchufas".
... Después de darle muchas vueltas, probé a detener el servicio "Microsoft Reporting Services", y el error dejó de producirse. El tipo dijo: "¿Pero por qué ese servicio trata de conectarse a SQL Server? No lo entiendo", a lo cuál le respondí con otra pregunta: "¿Usas el servicio de Reporting Services o lo vas a usar en un futuro?". "No" - respondió. "Entonces me da igual saber por qué trata de conectarse, dejamos el servicio apagado y problema solucionado"...
That's the Microsoft way!
Doy fe de la veracidad del punto 10. Yo suelo llamar a la última hora de la jornada la hora tonta porque después de todo el día programando no doy más de mí. Siempre que puedo la dedico a tareas que requieren poco esfuerzo intelectual. Muchas veces me ha pasado volverme loco buscando un bug y al día siguiente resolverlo en apenas 5 minutos.
Por otra parte el punto 5 me parece peligroso. El hecho de solucionar un problema sin averiguar su causa puede hacer que vuelva a aparecer en cualquier momento.
#8 Cuántas noches, hasta el amanecer intentando solucionar algo, al día siguiente te despiertas y en 10 minutos lo tienes
OPS: alguien ya opinó igual que yo en #12
Esto debería estar lo primero de la lista: A veces la mejor solución a un problema es irse a dormir
Ante todo empieza por los metodos mas faciles y si fallan, pasa a lo dificil.
En una ocasión tuve que ir a un buque portacontenedores al que le fallaba la automatización, esto es, el sistema que coordina el sistema de control de velocidad del buque con la sala de máquinas y el motor del barco. Tras unos chequeos iniciales confirmé que, efectivamente, no recibía en puente el feedback de velocidad del motor.
Como llevaba tarjetas de recambio del sistema(placa madre, placa de proceso, placa frontal) me dije que iria cambiando los componentes hasta que diera con el componente que fallaba. Una vez lo encontrara, se dejaba la tarjeta nueva y santas pascuas. El encontrar el fallo concreto ya es cosa del fabricante.
El caso es que cambiar estas tarjetas, debido a como esta instalado el sistema en el cuadro cuesta mas que hablar con Diós. Cambié una tarjeta y nada. Cambié otra y nada. Cambié la tercera y nada. Vaya, tal vez el problema esté en el sistema de cámara de máquinas (que es gemelo al de puente, y usa las mismas tarjetas). Pues nada, a desmontar las tarjetas nuevas y dejar las originales, que, a priori, funcionan bién.
Para resumir, en cámara de máquinas se repitió la misma historia, y ya eran las 3 de la madrugada y tenía 200 km hasta casa. Así que le dije al jefe de máquinas que mas se perdió en Cuba y que mañana más.
Al día siguiente bien tempranito(estos barcos no suelen estar en puerto mas de 24 horas) vuelvo al barco. Y me pongo a pensar. Y reconstruyo mentalmente todo el recorrido de la señal de velocidad desde los tacómetros en la rueda inercial del motor al actuador, de ahí al regulador y de ahí via comunicación serie hasta la automatización.
Y en eso que me pongo a repasar los cables en cuadro de cableado tras la cabina de cámara de máquinas, busco el cable concreto en el bornero y todo parece estar en orden, cojo el cable en cuestión, le doy un pequeño tirón... y se sale del bornero!!!.
El puto cable estaba suelto y era lo que estaba produciendo todo el problema, para cuya resolución solo necesité un puñetero destornillador.
Moraleja: El primer paso para resolver el problema no necesita herramientas. Consiste en pensar.
La culpa siempre es de JVM marditas mñaquinas virtuales
Via y entradilla: http://barrapunto.com/article.pl?sid=10/10/19/2328248
Este tipo tiene un problema grave, programa en Java con SQL server...
¿Have you tried to turn it off and on again?
Otra anécdota interesante es cuando a mi hermano en la empresa le dijeron que se había filtrado un error en el sistema de un cliente, el cuál tenía unas horas para resolver. Sin posibilidad de conocer cuál era el origen del problema, porque el sistema ya se había entregado con sus códigos fuente, debía encontrar una solución, que introducirían de "contrabando" en otro trabajo, que resolviera el asunto. Debía funcionar a la primera, ya que no había posibilidad de testearlo primero porque no había acceso a los archivos del cliente y debía hacerlo de forma que el cliente ni siquiera se enterara que el problema había existido.
Hace muchos años hice una aplicación en Java que tenía que realizar un cálculo para cada hora de cada día del año. El programa empezaba con las 00:00h del 1 de Enero, e iba incrementando hora a hora hasta que acababa a las 23:00h del 31 de Diciembre. Al ejecutar el programa e ir incrementando hora a hora, llegaba un momento en el que se realizaba el cálculo dos veces para la misma hora. Yo no entendía qué podía estar pasando, ya que el programa funcionaba bien, pero en un momento concreto del tiempo (el 29 de Octubre de 2000) se duplicaba la hora. Después de dos días persiguiendo el fallo, me levanté muy enfadado de la silla y grité en alto "¿Pero qué demonios pasa el 29 de Octubre?". Para mi sorpresa, un compañero me miró y me dijo muy tranquilo: "ese día es el cambio de hora". Claro! No había caído en la cuenta de que el 29 de Octubre de ese año era el día en que se retrasaba la hora, por lo que a las 3h de la madrugada volvían a ser las 2h... y de ahí el hecho de que se duplicase. Mi compañero había dado en dos segundos con la solución al problema que yo llevaba buscando días..
¿Y el día que se adelanta la hora no le salía una de menos que compensase el cálculo? Seguiría estando mal, pero no debería salirle en un caso una hora de más y en el otro no una hora de menos... aunque a saber como estaba eso si para buscar el año en una cadena buscaba un 20 a pelo... (cof, cof, expresiones regulares, cof, cof).
Buena recopilación de lo que uno aprende después de 25 años dándose cabezados con los ordenadores...
Se les olvidó el método Enjuto...
“Como se fue vino” (en el peor día de su vida).
No me acaba de gustar el punto 5... pero entiendo su motivación. En cualquier caso, añadiría algo que me parece crucial: Antes de dejar el tema "solucionado" y pasar a otra cosa.... DOCUMENTARLO.
Seguro que a mucha gente le suena hacer algo en la empresa, que el programa deje de funcionar inexplicablemente, y tras preguntar a alguien que te diga "aah, es que si haces esto, esto, y esto peta, no sabemos por qué", y te preguntas "¿y qué tal escribirlo para que la gente no haga eso, eso y eso, entonces?"
Entré a menearlo porque es muy bueno y ya lo habían hecho.
#2 Es lo que tiene leer http://identi.ca por Jabber y estar suscrito a@barrapunto
Doy fé de que son buenos consejos.
En especial el de ser humilde y pedir ayuda, porque muchas veces sólo con el esfuerzo de contarle a alguien el problema ya se te enciende la bombilla, y otras veces estás tan obcecado que no ves más allá de tus narices.
Todo problema será resuelto con un golpe en el costado derecho de la pantalla causando otro problema a largo tiempo que a su vez será resuelto con otro golpe.
Y la de ¿Usa el debugger? Porque el debugger es una cosa de esas que está ahí escondidas... que todo el mundo ha oído hablar de él pero que nadie utiliza...
Falta "Pegar fuerte en un costado de la máquina".
Fácil. No es inexplicable.
Los de sistemas han vuelto a cargarse algo cambiando algo de producción porque les ha dado la gana, o no han sido capaces de hacer una intervención siguiendo los 10 puntos especificados perfectamente uno por uno, y han decidido que el paso 9 se podía hacer antes que el 8, a pesar de estar subrayado que las dependencias no eran opcionales.
Lo siento, sé que sois mayoría los de sistemas de aquí, pero es que hoy me la han vuelto a liar (y ya van... y por gente de sistemas de distintas empresas).
yo siempre usaba una madre que se llama debugger, si no funcionaba me levantaba me iba a fumar un cigarro regresaba y volvía a usarlo, ahora ya no fumo, solo me salgo a caminar y regreso a usar el debugger
el problema del 20 de Setiembre de 2010 y el del sumar uno cada vez que cambia la hora es lo que llamo tratar de resolver algo "parchando". Se utilizó una solución ineficiente a un problema estúpido y el resultado fue un mamarracho.
Igual aún no descubro cómo hace mi madre para que el Word se tare de forma indescriptible.
Me acuerdo una vez, en la parada del colectivo, que escuchaba a unas chicas hablar de que en el trabajo de una tuvieron que llamar al técnico de nuevo para que les resolviera el problema. Pero ella y otra sabían perfectamente lo que era y no le quisieron decir para que el jefe no se enterara... Me imagino las que habrá pasado el pobre tipo para descubrir el porqué se corrompían los datos y lo que las chicas no le quisieron decir es que para apagar la compu "más rápido" la desenchufaban y ya.
Falta una: ningún administrador de sistemas se levanta por las mañanas pensando en cambiar las contraseñas de tus aplicaciones ni de tu usuario.
Sobre el ejemplo del consejo 4. La JVM de Sun (supongo que el resto también) está llena de bugs, pero el 99.9% de las veces es culpa del programador. Lo que pasa es que tras horas de revisar todo cada vez tienes más necesidad de culpar a otro. Cuando sospeches de un bug en la VM o en cualquier librería o middleware siempre hay que actuar como indicas en el consejo 1. Hay que crear un ejemplo lo más reducido posible que reproduzca el fallo. Si lo consigues reproducir el siguiente paso es leerte a fondo la documentación proporcionada por el fabricante y asegurarte de que usas el producto del modo correcto. Muchas veces entendemos incorrectamente la utilidad de cada función o damos por sentado cosas que no son ciertas. También a veces pretendemos usar una funcionalidad para una cosa para la que no fue pensada y nos encontramos con obstáculos no descritos en la documentación.
Vale que 10 es un número bonito, pero me da la impresión de que en los artículos tipo "10 consejos para..." algunos están metidos con calzador.
El primero que debe conocer el cliente es que no se le ocurra decir
Esto antes funcionaba, yo no he tocado nada
Orange es una experta en cuanto a consejos...
Orange ofrece 20Mb gracias a sus protones
Orange ofrece 20Mb gracias a sus protones
twaud.io¿Tu no serás funcionario? Estos tienen muuuuuucho tiempo para solucionar sus errorcitos...
En el mundo real, los que no disponemos de tanto tiempo, usamos algo más misterioso: la intuición, que remedio...
"Ejemplo: La semana pasada un compañero de trabajo experto en tecnología J2EE (un arquitecto de los buenos) estaba buscando la solución a un problema con la herramienta Maven. Llevaba más de dos horas buscando en google y no encontraba nada. Me pidió que le echase una mano, y en cinco minutos (buscando los términos correctos en google) dimos con la solución."
Autofelación
Meneo y remeneo. Muy interesante.
Otro ejemplo, el sábado "día de las chapuzas y reparaciones" intenté reparar una lampara que había dejado de funcionar, la desmonté pieza a pieza, sólo me faltaba desmonta la bombilla y al final se me ocurrió que el problema podía se externo a la lampara, así que busque otra lampara para enchufarla en el enchufe y Eureka no funcionaba, el culpable era el enchufe, satisfecho estuve el resto del sábado montando la lampara. El próximo sábado toca desmontar el enchufe.
¿Ha probado apagar y volver a encender?