Consejos para nuevos desarrolladores de software que han leído todos esos otros ensayos de consejos

Confiar en los consejos y en los “expertos”

• Muchos comentarios hacen eco del punto del ensayo: se sigue a las personas porque escriben o hablan bien, no porque tengan razón.
• Esto se aplica a publicaciones de blogs, libros, YouTube e incluso salidas de LLM; una presentación segura ≠ corrección.
• Varios instan al escepticismo sin cinismo: entender el razonamiento y la “historia de terror” detrás de cualquier buena práctica (la analogía de la Cerca de Chesterton).

Software, valor comercial y ventas

• Un debate recurrente: “el software nunca genera dinero, solo lo hacen las ventas”.
  • Quienes lo apoyan dicen que el software es un centro de costes y que el beneficio proviene de las transacciones y la captación de clientes.
  • Quienes lo critican responden que el software crea valor que se vende o se alquila; en muchas empresas, el software claramente impulsa los ingresos y la compensación de los desarrolladores lo refleja.
• Matiz de consenso: el contexto empresarial importa; la tecnología existe para servir al negocio, pero infravalorar la ingeniería conduce a malos resultados y a la eventual fuga de talento.

Propósito del software

• Aparece una afirmación contundente: “el único propósito del software es la automatización”.
  • Quienes la apoyan lo extienden incluso a los videojuegos como aplicación automatizada de reglas.
  • Quienes se oponen citan juegos, arte y usos no relacionados con la automatización como propósitos válidos; consideran esto un dogmatismo excesivo.

Trabajo de un desarrollador

• Tema popular: tu trabajo real es resolver problemas del negocio/usuario, no “escribir código” ni “escribir mensajes de Slack”.
• Algunos sostienen que esto es una exageración retórica; a menudo sí es tu trabajo escribir código, pero el enfoque debe estar en resolver el problema correcto, a veces no añadiendo más código.

Documentación, especificaciones y código fuente

• Un bando defiende leer la documentación “de cabo a rabo” y estudiar el código fuente de las herramientas clave; afirman que esto produce velocidad a largo plazo y “conciencia del mapa”.
• Hay una gran oposición:
  • Las especificaciones y librerías modernas tienen miles de páginas; es imposible leerlas o retenerlas por completo.
  • La gente tiene distintos estilos de aprendizaje; muchos prefieren una lectura iterativa, guiada por problemas, o echar un vistazo al índice.
  • Compromiso sugerido: aprender en profundidad un pequeño conjunto básico de herramientas, revisar en general y saber “dónde mirar” después.

Simplicidad vs. complejidad y la “forma correcta”

• Fuerte apoyo a “no compliques las cosas más de lo necesario” (KISS).
  • Críticas a la sobreabstracción, la generalización prematura y los marcos elaborados para proyectos diminutos.
  • Historias de “los tipos de la forma correcta” que imponen factories/builders/ORMs/staging para código trivial, o enormes frameworks internos como seguridad laboral.
• Contrapunto: los pequeños proyectos paralelos pueden ser un lugar seguro para practicar infraestructura y tooling “adecuados”; lo que parece exagerado puede ser aprendizaje deliberado.

Calidad del código, mantenibilidad y excelencia

• Muchos prefieren “código claro, que funcione y sea fácil de depurar” frente a código “ingenioso” o “excelente”.
• Desacuerdo sobre la “excelencia”:
  • Algunos dicen que es real pero peligrosa (hubris, sobreingeniería).
  • Otros sostienen que descartar la excelencia es abrazar la mediocridad; la clave es apuntar a soluciones funcionales y mantenibles, no al ego.

Depuración, lectura de código y herramientas

• Varios comentarios elogian un cierto libro de depuración y enfatizan la depuración como una habilidad profesional central.
• Consejo: aprende a leer bien el código (incluyendo recorrerlo paso a paso), no solo a escribirlo.
  • Una visión: los depuradores son una herramienta de aprendizaje poderosa, como los ejercicios de un libro de texto.
  • Otra visión: depender demasiado de los depuradores es una muleta; los ingenieros senior deberían razonar sobre el código sin ejecutarlo siempre.

Colaboración, revisiones y humildad

• Las revisiones de código se ven como de gran impacto: mejoran el código, enseñan habilidades de lectura y ponen de relieve problemas de diseño.
• Consejo para juniors:
  • Deja el ego, acepta críticas directas, haz preguntas y admite errores pronto.
  • Entiende que las “mejores prácticas” y las decisiones de arquitectura son contextuales; los seniors pueden tener razón por razones no obvias.

Salud, paseos y carga cognitiva

• El consejo de “salir a caminar” resuena con fuerza.
  • La gente informa que caminar o simplemente mirar un estanque es muy útil para depurar mentalmente y sobrellevar el estrés.
• Punto más amplio: gestiona el “estado” en tu cabeza; externalízalo mediante notas/wikis y protege tu ენერგía (evitando complejidad innecesaria).