¿La mayoría de los desarrolladores en algún momento de sus carreras rompen mal las cosas?

Es más común con su primer trabajo, pero si tiene la estructura y los sistemas correctos en su lugar, como el control de versiones del código, las solicitudes de extracción y las revisiones por pares para evitar cualquier problema potencial mediante los mejores procesos, debería suceder mucho menos, y tal vez ¿Nunca? Me doy cuenta de que a veces hay trabajos en los que ERES la estructura y nadie más sabe cómo construir los controles de seguridad necesarios, lo cual es mucho más difícil. Una buena manera de acoplarlo es tener un entorno de escenario para probar cualquier problema potencial. Programar actualizaciones de producción para después de horas, y tener a alguien disponible para hacer una prueba de humo después de que se realice una actualización es la mejor manera de hacerlo. Si no tiene estas cosas disponibles, debe crear su propio sistema de controles y equilibrios para acercarse lo más posible a esto, planificar previamente y minimizar el riesgo donde pueda. Creo que solo he tenido algunos errores importantes, pero cada vez que había copias de seguridad para salvarme, que se implementaron antes de que ocurriera el problema. Sé cómo te sientes, he estado allí. Aunque esto parece malo, también es su oportunidad de usar su ingenio genial para no solo escribir código, sino también diseñar formas para que su código se implemente de manera inteligente y transparente para que los usuarios no lo noten hasta que se den cuenta de que hay nuevas características . Hay muchos buenos recursos sobre cómo hacer este tipo de cosas mejor allí, y buenas personas que ayudarán. Es posible, y siempre lo hará mejor la próxima vez, así que use esta experiencia de aprendizaje para ser más increíble. ¡Buena suerte!

“Romper mal” a menudo está en los ojos del espectador. Por supuesto, si divulga los correos electrónicos o números de seguro social de sus usuarios al público, es malo. Pero entonces la pregunta es: ¿cómo es que un desarrollador tiene la oportunidad de hacerlo? Toda la organización está jodida. Un ser humano puede cometer un error, pero para que esto suceda, todo el sistema debe configurarse de modo que tales errores conduzcan a una gran falla.

Y de nuevo, todo está en los ojos del espectador. Recuerdo que una ingeniera (nacida en el extranjero) fue ridiculizada públicamente porque cometió un error ortográfico en algún lugar de la página web principal. La compañía tenía solo un ingeniero de control de calidad, por lo que puede adivinar cómo sucede todo.

Otro caso, se mejoró una expresión regular para filtrar las direcciones de correo electrónico; entonces un “arquitecto” descubrió que la expresión regular correcta es mucho más lenta que la incorrecta. En lugar de agregar más potencia informática (era Google), anunció que el desarrollador que escribió esa expresión regular no tenía experiencia y escribió algo ineficiente. Entonces, el código fue revertido, básicamente, roto.

Recuerdo otro caso cuando, de repente, las cuentas de los usuarios (en una red social entonces popular) comenzaron a superponerse. Los nuevos usuarios tienen acceso a las cuentas de los veteranos. ¿Cómo pasó? Cuando se numeraron los números de cuenta (para usar como identificadores oficiales), se borraron dos bits, por alguna razón bastante estúpida. Este error fue hecho por un individuo. Pero cuando se advirtió, todo el equipo simplemente ignoró la advertencia.

Lo que quiero decir: tales errores rara vez son el resultado de fallas individuales, sino más bien un esfuerzo de equipo y la ignorancia de los gerentes.

Es perfectamente normal. En los sistemas donde una falla puede causar daños, por ejemplo, en un sistema automotriz o médico o de vuelo, existen salvaguardas que evitan que los errores pasen, desde revisiones estrictas de códigos hasta pruebas de verificación detalladas, y un codificador solo se metería en problemas por introducir un error si habían pasado por alto estos procedimientos e impulsaron un cambio en la producción sin garantías. Eso es muy malo juju.

El peor resultado de un error que cometí fue cuando construí el sistema de reloj en tiempo real para un sistema de edición que habíamos construido. Funcionó bien hasta el 1 de octubre, cuando el “mes” que mi código leyó en el dispositivo del reloj resultó ser BCD en lugar de binario (puede ver la diferencia) y mi código fue y buscó el nombre del mes 16 de el año, y se estrelló cada una de esas máquinas en todo el país, módulo de zona horaria. Una corrección de 30 segundos para el código y una lección para leer la hoja de datos con más cuidado.

Esperemos que tu error no haya sido tan espectacular.

Demonios sí, en cualquier campo. Viene con el territorio. Como alguien más dijo, es un derecho de paso.

En el software, todos dejan un error desagradable en su código al menos una vez (generalmente más de una vez), o escriben “rm -rf *” olvidando que están conectados como root y en el directorio raíz.

En software, generalmente no es fatal. Si es, como, por ejemplo, un error en un piloto automático que vuela un avión a la ladera de una montaña, entonces muchas más personas han fallado que solo una persona.

Cuando se trata de algo crítico para la vida o la misión, debe haber muchos procesos para evitar daños graves, tanto accidentales como intencionales, revisiones de diseño, revisiones de código, pruebas, ejecuciones de senderos, monitoreo del sistema, etc. Si rompe algo mal, “el sistema” es tan culpable como tú, y debes sacar algunas lecciones de procesos y administración, tanto como las técnicas. (No quiere decir que no haya muchos entornos en los que se pueda romper algo mal, porque no existen salvaguardas. La mayoría de nosotros hemos estado allí, hecho eso, tal vez aprendimos algunas lecciones).

Ahora … considere un cirujano. Las fallas no solo son inevitables, sino que tienden a involucrar a personas que mueren bajo el cuchillo; y hay una buena posibilidad de que nunca sepas si mataste a tu paciente, o simplemente no pudiste salvar a alguien que no pudo ser reparado (y probablemente te demandarán por negligencia de cualquier manera).

Tuve un trabajo como ingeniero sénior que duró 4 semanas, y posiblemente fue una de las situaciones más humillantes, irritantes y frustrantes que he conocido. Llegué a ser honesto con mi experiencia, y la proliferación de ES6 / Babel había avanzado tanto que me llevó una eternidad simplemente poner en marcha las cosas.

En pánico, cometí errores descuidados en mi código, intenté trabajar los fines de semana para ponerme al día, y luego me dijeron con gracia “pensamos que ibas a ser tan inteligente como (inserte el nombre aquí), y estoy realmente sorprendido”. Esto fue después de venir de un trabajo anterior en el que mis colegas respetaban lo que traje a la mesa y pudimos trabajar juntos para facilitar la incorporación de los demás. No en este caso, era un sumidero o eventualmente una situación de hundimiento; que funcionó para lo mejor.

Nosotros mismos nos rompemos a veces. Presión para ser tan bueno, tan talentoso, tan rápido y tan bien informado como sus compañeros pueden ejercer presión sobre usted que resulta en errores.

Dicho esto, un departamento de ingeniería que no implementa una estrategia de Solicitud de extracción> Desarrollar parece un poco desordenado, especialmente si nadie puede atrapar la compilación en cualquier sistema de CI que se esté construyendo.

Todos hemos hecho algo igual o peor antes, por lo que todavía no soy grande en el trabajo de base de datos 🙂

TODOS cometen errores horrendos algunas veces, eso es absolutamente 100% normal.

Pero la mayoría de las empresas ponen al menos un par de capas de protección allí.

1. Debería haber revisiones paritarias del código antes de que se registre en el “tronco” principal. Esto debería detectar problemas obvios.
2. Debe haber un departamento de control de calidad que ejecute (como mínimo) un conjunto de pruebas de regresión en el producto final antes de que el “tronco” se copie en “producción”. El repositorio de “producción” debe estar bloqueado para que los programadores no puedan cambiarlo … solo el jefe del departamento de control de calidad debería poder hacerlo.

Con cualquiera de esas cosas en su lugar, no habría arruinado la producción, o al menos otra persona compartiría su responsabilidad.

Si su empresa no tiene ninguno de esos dos pasos, puede ser proactivo y sugerirlo.

Una vez solicité a una empresa (¡y obtuve una oferta de trabajo de ellos!) Enumerando muchos de mis errores.

La medida de una persona no es si se equivocan o no. Todos lo hacemos.

La medida de una persona es cómo manejan sus errores. Busco tres cosas.

Si tienes tu error, eso es bueno. Disculparse, reconocer su culpa y asumir la responsabilidad de solucionarlo. Aunque personalmente, tiendo a tratar de ser dueño de todos los problemas que surgen, ya que nos lleva más allá del juego de la culpa y en la etapa de arreglarlo mucho más rápido que si busco quién tiene la culpa. Estoy seguro de que quienquiera que sea se está pateando más fuerte de lo que podría de todos modos, pero si dan un paso adelante y lo poseen, eso también es bueno.

Si luego toma medidas para resolver y mitigar el problema, está bien. ¿Arreglaste el error? ¿Manejó las consecuencias del error y ayudó a los clientes afectados? ¿Documentarlo, enviar alertas, bloguear la solución alternativa, notificar a los departamentos de soporte que puedan tener preguntas sobre este tema y darles una respuesta de ejemplo, etc., etc.?

Si toma medidas para evitar que el problema se repita, eso demuestra que le importa la calidad de su trabajo, en lugar de ser fatalista al respecto. ¿Sugirió cambios en los procedimientos de flujo de trabajo para evitar que esto vuelva a suceder? ¿Documentaste esos cambios? ¿Los sigues?

Si lo poseía, lo reparaba y se aseguraba de que no volviera a suceder, entonces no se equivocó: descubrió algo nuevo y se lo enseñó a su equipo.

Sí, es bastante común.

Alguien una vez configuró mal el servidor web de Facebook (apache si no se equivoca) y el código fuente fue volcado al usuario, en lugar de ser interpretado por PHP.

CloudFlare tuvo un error al enviar las respuestas incorrectas a los clientes incorrectos recientemente, les tomó un tiempo detectarlo. En este caso, el error estaba en una biblioteca de terceros.

Hay muchos casos por ahí, la Prueba de Unidad / Prueba de Integración, etc. resuelve este problema parcialmente, pero puede / sucederá eventualmente. Somos solo humanos después de todo.

Ley de murphy.

A2A

Oh diablos si.

Definitivamente me he equivocado, bastante masivamente .

Accidentalmente eliminé 1500 registros de clientes de datos financieros.

Gracias a Dios fue recuperable de la copia de seguridad.

Pero en serio, realmente la jodí (sí, usé la palabra F en Quora).

Multimillonarios dólares F-up.

Recuperado – gracias a Dios.

Fórmula simple:

Sin malos saltos === ¡No es un desarrollador real!

Algunos dicen que es un rito de iniciación.

Todos los programadores en existencia han tenido esto al menos una vez. Básicamente, es donde aprendes que las cosas pueden salir mal y deben poder volver a donde estabas de antemano.

Hay una muy buena descripción de tal experiencia en la Temporada 1 Episodio 3 de la serie AMC Halt and Catch Fire.

¡OH SI! Sucede.

Esa es una de las razones por las que normalmente no hay un solo punto de falla, sino algunas salvaguardas establecidas. Y una de las razones por las que nunca quise trabajar para nada médico. (Y las computadoras Apple no pueden usarse para nada nuclear: saben lo que están haciendo).

Oh, sí. Si está en el trabajo por un período de tiempo prolongado y nunca ha cometido un error importante al menos una vez, es una mala señal. Significa que su empleador no le está asignando tareas complejas, lo que generalmente significa que no tienen mucha confianza en usted.

No digo que muchos errores estén bien, pero que eres humano, lo arruinarás de vez en cuando.

Generalmente a medida que mejora su confianza aumenta.

En algún momento, a menudo lo “ala” y todo funciona. Con el tiempo, “lo alabas” y fallas gravemente.

Asumiría que todos fracasan gravemente eventualmente. No se trata de “si” sino de cuándo.

Totalmente normal

Rompí el sistema Google Ad una vez … digamos que nunca lo volví a hacer 🙂

Si, es normal. Cuanto peor se arruina, mejor es la lección.

Si. Y no solo una vez. Su forma de aprendizaje constante.