¿Un ingeniero de software en una empresa resuelve el mismo tipo de problemas repetidamente?

En realidad no … de vez en cuando encuentras algo que es un poco similar a algo que hiciste antes, pero la variedad es infinita.

Por supuesto, hay un montón de código que es solo repetitivo, conectando cosas y decidiendo cómo llamarlo todo, o dibujando gráficos o cosas por el estilo … pero eso es apenas una solución de problemas, es más que escribir la introducción para que pueda llegar al carne real de tu argumento.

Los problemas realmente carnosos, nunca son lo mismo dos veces.

Incluso cuando he tenido que hacer lo mismo muchas veces … cada vez tiene un marco ligeramente diferente.

Ejemplo: administrar un subproceso en Linux.

  • Ejecute el subproceso, espere a que escriba una línea determinada en un archivo, escriba algo en este otro archivo, espere a que salga. Okay. Suficientemente simple…
  • Ejecute un proceso ANTES de init durante el arranque inicial del sistema ramdisk, y espere a que le diga algo en una tubería con nombre. Sin bloquear estas otras cinco cosas que también usan tuberías con nombre. Sin sistema de archivos, y la red aún no está activa, ni la consola UART se ha inicializado todavía … espera, ¿cómo puedo depurar esto? Ah, claro, hay un autobús SPI en esta cosa … espía eso. No, aquí está este GPIO conectado a un LED … así que es más fácil conectar un telescopio al LED y parpadear en Morse de alta velocidad. Sí, realmente, depure mensajes en código Morse.
  • Asegúrese de que este proceso siempre se esté ejecutando … suena fácil, ¿verdad? Ah, pero es el tercer proceso iniciado en el sistema durante init … y si se bloquea, no puede leer sus coredumps porque comenzó antes del postprocesador coredump del espacio de usuario … y si no se reinicia, o crashloops, el sistema es catatónico. , inaccesible desde la red, por lo que debe restablecer físicamente la alimentación. Y, por cierto, el cliente que presentó el error tiene estas cosas instaladas en los sistemas de seguridad en las salas de audiencias de toda la ciudad, lejos de sus oficinas de soporte de TI, y tienen que conducir físicamente allí, dejarse entrar al área segura y tira del cable de alimentación para restablecerlos … así que realmente les gustaría que esto se resolviera pronto, gracias. Todo lo que tengo que trabajar es un coredump parcial, truncado. De hecho, arreglé tres errores diferentes para rastrear este … resultó ser una línea faltante en un script de inicio, pero también arreglé un error en el coredumper y uno en el controlador de flash de arranque del sistema … en tres días. El cliente estaba extasiado.
  • Ejecute el subproceso. Espere a que escriba una línea de registro, establezca una variable en otro lugar, espere a que algo cambie. Si sale, reinícielo. Si recibe una instrucción de red de algún lugar, escriba un nuevo archivo de configuración para su proceso y envíele una señal. Si envía una señal nuevamente antes de que escriba la confirmación en el registro, se bloquea, así que no lo haga, pero si obtiene más instrucciones de red, debe guardarlas en el búfer y enviarle una nueva señal lo antes posible después de que le indique que está bien. . Escribe varias cosas en el archivo de registro, las analiza y establece variables en algunos lugares para que la IU pueda decirle al usuario lo que está sucediendo. Algunos de ellos significan que tienes que cambiar el archivo de configuración y enviarle una señal de nuevo también … Ah, y como tienes que monitorearlo, estás generando procesos zombies, así que haz un pequeño baile para limpiarlos del núcleo cuando Ellos salen. No es tan simple … ah, y haga todo esto mientras agrega menos de 1kb a la imagen del sistema, y ​​su presupuesto de memoria es de 2kb. Y tiene 100 ms para hacer cada paso allí, en una CPU de 233 MHz que podría estar realmente ocupada. No tuvo éxito con el presupuesto de memoria y almacenamiento, resultó ser demasiado código, pero está bien, lo recuperamos en otro lugar.
  • Ejecute un script de shell en Borg que envíe un RPC periódicamente (para los Googlers por ahí … ¿sabía que eso era posible?). Sin escribir un nuevo archivo de registro cada 15 segundos. (Sí, este es corto … pero fue muy divertido y educativo).

Cinco problemas completamente diferentes que se ven iguales en la descripción de nivel superior.

Para las personas que se obsesionan con la elección del idioma: espacio de usuario C, kernel-mode C, bare-metal C, shell script, perl, C ++, un poco de Python, algo de Lua, dos líneas de Forth (!) TCL y un montón del trabajo de Makefile en estos ejemplos. NO PUEDE asumir que solo necesita uno, dos o tres idiomas en la programación profesional. El total de mi carrera está en algún lugar a mediados de los años 30, si no más (algunas cosas que preferiría olvidar).

¿Un ingeniero de software en una empresa resuelve el mismo tipo de problemas repetidamente?

No. Oh no. La mayoría de los ingenieros pasan su vida laboral en un juego de whack-a-mole, donde nunca hay un solo problema que resolver; los nuevos siguen apareciendo, generalmente más rápido de lo que puedes golpearlos.

A veces se siente como ahogarse en un mar de incompetencia; esos problemas no se generan de la nada; provienen de sus colegas y de su gerencia (pero principalmente de su gerencia). El personal de ventas y marketing es un prolífico creador de problemas, principalmente problemas que no tienen ningún sentido.

Es asombroso. el nivel de calma Zen que alcanzas, una vez que alcanzas tu hacha y te enfureces.