20 Expresiones Técnicas en Inglés que los Programadores Escuchan Todos los Días

Hablemos de esto fuera de esta reunión, en una conversación aparte.

Se dice cuando surge un tema en una reunión que es demasiado específico o solo relevante para pocas personas. No es maleducado: es una señal para continuar la discusión en un foro más pequeño.

Ese tema o problema es muy complejo y podría consumir mucho tiempo sin un final claro.

Tomado de Alicia en el País de las Maravillas. Se usa para advertir a los compañeros de que investigar algo más a fondo puede no valer la pena en este momento.

El equipo o persona no puede avanzar en una tarea porque algo externo impide el progreso.

Muy común en los standups. Un blocker puede ser una dependencia que falta, una decisión que no se ha tomado, un acceso que no se ha dado o un bug en el código de otra persona.

Lanzar la funcionalidad o el código a producción. Vamos a desplegarlo.

Abreviatura de 'ship the code'. Se usa para señalar que algo está listo para salir. A veces se usa como ánimo para dejar de sobreingeniería y simplemente lanzar.

El coste acumulado de los atajos tomados durante el desarrollo que habrá que abordar más adelante.

Abreviatura de 'technical debt'. Cada vez que escribes una solución rápida en lugar de la correcta, añades deuda técnica. En algún momento, el coste acumulado es demasiado alto para ignorarlo.

Una tarea de investigación corta y acotada en el tiempo para investigar un problema o tecnología antes de comprometerse con una solución.

Término de Agile/Scrum. Un spike no consiste en construir algo, sino en aprender lo suficiente para tomar una decisión. Frecuente cuando el equipo no sabe cuánto tiempo llevará algo.

Explicar tu código o problema en voz alta, a un pato de goma, a un compañero o a cualquiera, para encontrar el bug tú mismo a través del acto de explicar.

Del libro 'The Pragmatic Programmer'. A menudo, el acto de explicar un problema te obliga a verlo desde un ángulo diferente, y encuentras la respuesta antes de que la otra persona responda.

Pasar demasiado tiempo debatiendo detalles triviales o fáciles de entender mientras se ignoran los importantes y complejos.

De la Ley de la Trivialidad de Parkinson. En una reunión sobre una central nuclear y un cobertizo de bicicletas, la gente pasa todo el tiempo en el cobertizo porque todo el mundo lo entiende. Lo mismo ocurre en las code reviews o en las sesiones de planificación.

Hacer una cadena de tareas pequeñas y aparentemente no relacionadas para lograr el objetivo original, perdiendo la pista de lo que intentabas hacer.

De un episodio de Ren y Stimpy. Ejemplo clásico: necesitas hacer un deploy, pero primero tienes que actualizar una dependencia, pero eso requiere una versión nueva de Node, pero primero hay que actualizar Homebrew... y ahora estás haciendo yak shaving.

La solución actual cumple los requisitos mínimos. Podemos mejorarla más adelante.

También se escucha como 'good enough for government work' (modismo estadounidense). En ingeniería, se usa a menudo al debatir entre el perfeccionismo y el lanzamiento. No se trata de ser descuidado, sino de saber cuándo es mejor terminar que perfeccionar.

La métrica u objetivo más importante que guía las decisiones de un producto o equipo.

Lenguaje estratégico tomado de la cultura startup. Lo escucharás en reuniones de producto, discusiones de OKRs y presentaciones de roadmap.

Un proyecto nuevo construido desde cero, sin base de código existente ni restricciones.

Lo opuesto de 'brownfield' (trabajar con código heredado). Los proyectos greenfield son emocionantes pero también arriesgados porque no hay patrones existentes que seguir.