Programación para ingenieros civiles: automatizaciones que ahorran horas + buenas prácticas explicadas simple

Los datos duros:

• Tareas repetitivas en oficina de ingeniería típica: 40-60% del tiempo del equipo.
• Salario premium de ingenieros con habilidades de programación: +30-70% según región.
• Reducción de errores humanos automatizando: 60-90% para tareas típicas.

Y sobre todo: te cambia el chip. Empiezas a ver problemas como sistemas — con inputs, procesos y outputs. Esa mentalidad, más allá del código, te vuelve mejor ingeniero.

Lo que NO significa programar como ingeniero civil:

• No significa ser desarrollador de software.
• No significa dejar la ingeniería.
• No significa aprender 20 lenguajes.
• Significa usar programación como una herramienta más, como el AutoCAD o el Excel — igual de natural.

Ordenadas de más fácil a más avanzada. Todas viables con Python o Dynamo + IA.

1. Renombrado masivo de familias / capas / vistas (Revit / AutoCAD). Antes: 2-4 h. Después: 30 s. Ahorro: ~99%.
2. Exportar tablas de cantidades a Excel con formato corporativo. Antes: 1-2 h. Después: 10 s. Ahorro: ~99%.
3. Colocar cotas o etiquetas automáticas siguiendo reglas. Antes: 3-5 h/plano. Después: 5 min. Ahorro: ~95%.
4. Generar perfiles longitudinales cada X metros en Civil 3D. Antes: 3 h. Después: 15 min. Ahorro: ~92%.
5. Cubicación automática de movimiento de tierras. Antes: 2 h. Después: 30 s. Ahorro: ~99%.
6. Chequeo de estándares BIM (naming, categorías, parámetros). Antes: 2 h. Después: 30 s + reporte. Ahorro: ~99%.
7. Generación masiva de láminas con vistas + tablas + membrete. Antes: 4-8 h. Después: 2 min. Ahorro: ~98%.
8. Detección de interferencias entre disciplinas + reporte. Antes: 3 h. Después: 15 min. Ahorro: ~92%.
9. Modelado paramétrico de taludes desde polilínea + reglas. Antes: 4 h. Después: 30 min. Ahorro: ~87%.
10. Exportar puntos topográficos a CSV con clasificación. Antes: 1 h. Después: 10 s. Ahorro: ~99%.

"Arquitectura de software" suena a algo enorme. Para ti, ingeniero que automatiza, es MUCHÍSIMO más simple. Se resume en:

Regla única: organiza tu código en capas que hacen una sola cosa cada una.

Traducción a carpetas de tu proyecto:

MiPlugin/
  UI/              (formularios, ventanas, botones)
  Logic/           (tus reglas: "las vigas <3m no cuentan")
  Revit/           (todo lo que toca la API — SetParameter, GetElement)
  Program.cs       (punto de entrada, arma las 3 capas)

¿Por qué esto importa? Porque el día que Autodesk cambie la API (y siempre cambian), solo tocas la carpeta Revit/. Tu lógica y UI quedan intactas. Y si mañana quieres cambiar de C# a otro lenguaje, tu lógica es reutilizable.

Analogía civil: es como diseñar un edificio con estructura, arquitectura e instalaciones separadas. Si toca cambiar las instalaciones, no rediseñas la estructura. Con código igual.

"Código limpio" son 4 hábitos concretos:

a) Nombres que dicen la verdad.

Mal:

def calc(x, y):
    return x * y * 0.18

Bien:

def calcular_iva(precio, cantidad):
    return precio * cantidad * TASA_IVA

El segundo se lee. El primero te obliga a adivinar qué hace.

b) Funciones cortas que hacen UNA cosa.

Mal — una función que hace 5 cosas: leer archivo, filtrar datos, calcular, generar reporte, enviar email.

Bien — 5 funciones:

def leer_datos(archivo): ...
def filtrar_por_categoria(datos, cat): ...
def calcular_totales(datos): ...
def generar_reporte(totales): ...
def enviar_email(reporte, destinatario): ...

c) Constantes con nombre, no números mágicos.

Mal: if edad > 18: (¿por qué 18? ¿qué significa?).

Bien:

EDAD_MAYORIA = 18
if edad > EDAD_MAYORIA:
    ...

d) Comentarios donde importan, no en lo obvio.

Mal:

# Sumar 1
x = x + 1

Bien:

# Las vigas <3m no cuentan por norma interna DGA-2023
if longitud_viga >= LONGITUD_MINIMA_VIGA:
    contador += 1

El problema: cada script empieza de cero. Copias y pegas las mismas 30 líneas de siempre para conectar con Excel, para leer un archivo, para armar un reporte.

La solución: cuando escribas la misma cosa dos veces, es una función. La tercera vez, es un componente.

Ejemplo real: todos tus scripts terminan exportando a Excel con el mismo membrete corporativo. Extrae ese código a una función que puedas importar:

# archivo: helpers/excel_corporativo.py
def exportar_con_membrete(datos, ruta):
    """Exporta una lista de datos a un Excel con el
    membrete y estilos corporativos de la empresa."""
    ...

Ahora en cualquier script: from helpers.excel_corporativo import exportar_con_membrete. Una línea, no 30.

Efecto compuesto: con 6-8 componentes bien hechos, cada nuevo script tarda 1/3 del tiempo. Y todos comparten el mismo estándar corporativo automáticamente.

Regla de oro: cada vez que copies y pegues código, párate y pregúntate: "¿esto merece ser una función?". La mayoría de veces, sí.

Si sólo aprendes una herramienta de esta guía, que sea Git. Es el backup infinito de tu código.

Setup fácil (sin terminal):

1. Instala GitHub Desktop (interfaz visual, gratis).
2. Crea una cuenta en GitHub.com (gratis).
3. Crea un repositorio privado para cada proyecto de automatización.
4. Cada vez que algo funciona: botón "Commit" → botón "Push". Listo. Está guardado en la nube.

Lo que ganas:

• Si mañana rompes algo, vuelves a la versión de ayer con un botón.
• Trabajas desde otra máquina y todo está sincronizado.
• Si vas a compartir con un colega, es una URL.
• Nunca más "perdí el archivo".

Costo total de aprenderlo bien: 20 minutos + un video de YouTube. Valor: infinito.

No necesitas escribir tests automatizados como un dev senior. Necesitas un mínimo de disciplina para no romper cosas.

El protocolo mínimo antes de dar por bueno un script:

1. Prueba con datos reducidos — no con el modelo de producción. Un archivo pequeño.
2. Prueba con datos límite — 0 elementos, 1 elemento, muchos elementos.
3. Prueba con datos "malos" — un dato faltante, un valor negativo, un texto donde iba número.
4. Verifica manualmente el output las primeras 2-3 veces. Después empiezas a confiar.
5. Ten un "modo dry-run" — un modo que solo lista lo que HARÍA sin hacerlo. Perfecto para revisiones antes de correr en producción.

Ejemplo de dry-run:

def renombrar_familias(dry_run=False):
    for familia in obtener_familias():
        nuevo_nombre = calcular_nuevo(familia)
        if dry_run:
            print(f"[DRY] {familia.nombre} -> {nuevo_nombre}")
        else:
            familia.rename(nuevo_nombre)

Corres con dry_run=True primero, revisas la salida, y sólo si todo está bien lo corres de verdad.

Sigues este orden:

Etapa 1 — Script personal (semanas): Un archivo. Sólo tú lo usas. Vale. No necesitas más.

Etapa 2 — Herramienta compartida (meses): Ya lo usan 2-3 personas. Ahora sí: métele a Git, ponlo en carpetas, documenta las tres cosas críticas (cómo instalar, cómo usar, cuándo NO usarlo).

Etapa 3 — Producto del equipo (semestre): Ya lo usan 10+ personas. Toca: instalador, versión, canal de soporte (aunque sea WhatsApp), reglas de contribución.

Etapa 4 — Herramienta del rubro (año o más): Ya se distribuye a clientes externos. Necesitas: firma digital, updates automáticos, tests, licenciamiento. Y ahí es donde una mentoría o socio técnico ahorra semanas de errores.

Regla clave: no pases de etapa antes de tiempo. Un script que sólo tú usas no necesita instalador. Un producto que usan 20 personas no puede vivir sin Git. Ajusta la disciplina al momento.