Software Consulting Services

Cómo ser un buen programador: 12 hábitos de código que impulsan tu carrera

Un programador escribiendo código en varias pantallas durante la noche con diagramas de flujo y gráficos, mostrando cómo ser un buen programador mediante práctica y hábitos de programación.

TL;DR: tus hábitos valen más que tu stack. Commits claros, PRs pequeños, reproducibilidad, depuración con método, tests mínimos que cubran lo crítico, escribir (documentar), comunicar bien… y leer más código del que escribes.


Al inicio de la carrera, muchos desarrolladores creen que crecer profesionalmente depende de dominar el framework más reciente o acumular certificados. Sin embargo, lo que realmente marca la diferencia suelen ser los hábitos cotidianos de programación. 


Pequeños detalles como la forma de escribir un commit, el tamaño de un pull request o la claridad en la comunicación técnica terminan pesando más en la confianza que genera un dev dentro de su equipo. Son esos hábitos los que transforman a alguien de junior prometedor a compañero confiable y, con el tiempo, a referente técnico.


Aquí tienes una lista práctica de hábitos para convertirte en un mejor programador y avanzar en tu carrera profesional.

 

12 hábitos de código que impulsan tu carrera como developer


1) Commits legibles importan más que commits heroicos


Un commit no es solo un cambio en el código, es un registro de decisiones técnicas que quedará ahí para siempre. Un historial claro permite a cualquier compañero (incluso a ti mismo en seis meses) entender qué pasó y por qué. Aprender a escribir commits descriptivos es un hábito que diferencia a quienes están empezando de los que ya saben cómo trabajar en equipo.


feat(api): add rate limit to /invoices to prevent abuse
- sliding window 100 req/15m
- returns 429 + Retry-After
- docs updated


Plantilla útil:


# ~/.gitmessage.txt
<type>(<scope>): <summary>
- Why:
- How:
- Notes/links:
git config --global commit.template ~/.gitmessage.txt


2) Pull Requests pequeños y con contexto


Un PR no debería ser una montaña de 1000 líneas imposibles de revisar. Mantenerlos pequeños facilita la revisión, reduce errores y acelera la integración. Además, un buen PR no es solo código: es explicar el problema que resuelve, cómo probarlo y qué impacto tiene.


Checklist rápida para tu PR:

 

  • Problema/solución en 2–3 líneas
  • Pasos para testear local
  • Evidencia (curl/screenshots)
  • Impacto en performance/seguridad
  • ¿Flag/migración?


3) Reproducibilidad: un comando para levantarlo todo


“En mi máquina funciona” es el peor enemigo de un equipo. Automatizar procesos garantiza que cualquiera pueda levantar el proyecto sin fricción. Este hábito demuestra madurez profesional.


.PHONY: dev test lint
dev:
    python -m venv .venv && . .venv/bin/activate && pip install -r req.txt
    cp .env.example .env || true
    docker compose up -d
test:
    pytest -q
lint:
    ruff check . && black --check .
 

Regla práctica: si repetiste un proceso más de 3 veces en la semana, conviértelo en script.

 

4) Aliases y atajos que realmente usas


Los pequeños atajos de terminal no te hacen un gran programador, pero sí reducen fricción. La idea es concentrar tu energía en resolver problemas, no en repetir comandos largos.


alias gs='git status -sb'
alias gl='git log --oneline --graph --decorate -20'
alias dk='docker compose'
alias gsw='git switch'
alias gco='git checkout -b'


5) Depurar como detective, no como adivino


El debugging efectivo no se trata de “intentar cosas al azar”, sino de reproducir el error, observar, aislar, plantear hipótesis y confirmarlas.


console.time('invoice#create');
logger.info('createInvoice:start', { userId, payloadSize: JSON.stringify(body).length });
// ...
console.timeEnd('invoice#create');

 

Rutina de depuración:

 

  1. Reproduce con el caso mínimo
  2. Observa con logs claros
  3. Aísla con git bisect
  4. Escribe 1–2 hipótesis
  5. Test que falla → fix → test que pasa


6) Medir antes de optimizar


Optimizar sin datos es perder tiempo. Primero mide, luego decide.
 

import time

t0 = time.perf_counter()
# run target
elapsed = time.perf_counter() - t0
print(f"elapsed={elapsed:.3f}s")

 

Regla: prioriza endpoints con tráfico o SLA comprometido (p95/p99).


7) Tests mínimos que te dejan dormir tranquilo


Los tests no son un lujo, son tu cinturón de seguridad.


// Jest
test('applies prorated discount', () => {
 expect(applyDiscount(100, { type: 'prorated', days: 10, of: 30 })).toBe(66.67);
});

Cobertura mínima:

  • Unit tests para lógica crítica
  • Un par de integration tests para flujos principales
  • Un test de regresión por cada bug real


8) Escribe para tu “yo del futuro”


Documentar no es burocracia: es un regalo para ti mismo y tu equipo. Un README corto o un dev log con tus pasos evita horas de frustración.


Plantilla express:


Hecho: …
Atascos: …
Siguientes 3 pasos: …
Notas: links/comandos


9) Comunica con claridad, como un senior


La comunicación técnica es tan importante como el código. Saber reportar lo que hiciste, lo que harás y lo que te bloquea genera confianza.


Yesterday: validación email + retry
Today: PR #1245 (rate limit), luego pruebas de carga
Blocked: acceso a S3 staging
Need: @ops permisos antes de las 3pm


10) Lee más código del que escribes


Escribir sin leer te encierra en tus propios errores. Revisar PRs ajenos y explorar repos maduros acelera tu aprendizaje.


Cómo hacerlo:

 

  • Revisa PRs y comenta mejoras concretas
  • Explora repos sólidos: sigue el flujo entrada → dominio → persistencia → tests
  • Colecciona patrones de nombres, capas, manejo de errores
  • Compara tu solución con la de otros después de intentarlo


11) Estima con honestidad (y buffer)


No se trata de acertar siempre, sino de ser confiable. Descompón la tarea, lista riesgos y añade un margen de seguridad.


Tarea: Exportar CSV masivo
Subtareas: endpoint+filtros (0.5d), streaming/paginación (1d), tests/docs (0.5d)
Riesgos: dataset grande, memoria
ETA: 2d + 0.5d buffer


12) Observabilidad básica y on-call con cabeza


Un buen programador no solo escribe código: también se asegura de que funcione en producción. Dashboards, alertas y runbooks vivos son esenciales para un equipo sano.


Más que código: el camino hacia ser un gran programador


Convertirse en un buen programador no depende solo de los frameworks ni de los años de experiencia. La respuesta a “cuánto tiempo toma ser bueno programando” está en repetir hábitos como estos. “Cómo ser un buen programador” se resume en ser alguien confiable: escribir commits claros, abrir PRs manejables, documentar pensando en el futuro, leer el código de otros y comunicarte con precisión.


No son pasos espectaculares, son rutinas consistentes que construyen tu reputación. Y al final, esa reputación es lo que te abre la puerta a ser visto como alguien indispensable dentro de tu equipo.

 


¿Quieres conocer más sobre Rootstack? Te invitamos a ver este video.