Código de Ética 🤝

Cómo trabajamos en los cursos: aprender de verdad, en equipo y usando las herramientas con criterio.

1. El espíritu: sé razonable

Todo lo que hacemos en el curso tiene un solo objetivo: que aprendas. La regla general es simple: lo que maximiza tu aprendizaje está bien; lo que lo esquiva, te lo quita a ti. Antes de cualquier atajo, pregúntate: ¿después de esto voy a saber más o solo voy a parecer que sé más?

Si una acción te deja igual que antes de hacerla, no era trabajo: era un disfraz.

2. Tu trabajo te representa

  • Entrega solo lo que puedes explicar línea por línea. Si no puedes contar qué hace y por qué está ahí, todavía no es tuyo.
  • Inspirarse en ejemplos, documentación y código ajeno es parte del oficio. La versión que entregas, en cambio, la construye tu equipo, con sus propias decisiones.
  • Da crédito: si un recurso te ayudó — un fragmento de código, un tutorial, un arte, una música — dilo en el README o en un comentario. Citar no resta puntos; esconder, sí resta aprendizaje.
  • Cada proyecto del curso es distinto por diseño: tu versión debe reflejar las decisiones, el estilo y las ideas de tu equipo.

3. El equipo de verdad

  • Todos programan. Dividir el trabajo está bien; dividir el aprendizaje, no. Nadie se queda de espectador ni "solo hace las diapositivas".
  • Los commits cuentan la historia: cada integrante aporta los suyos, con mensajes claros, de forma equitativa y constante (no todo la última noche).
  • Roten las tareas difíciles: si siempre programa la misma persona, el resto está perdiendo el curso en cámara lenta.
  • Revisen el código de los demás: explicar tu parte y entender la del otro es la mejor preparación para la sustentación.
  • Los desacuerdos técnicos se resuelven probando, no imponiendo. Y se habla a tiempo: un compañero ausente es una conversación pendiente, no una sorpresa del día de la entrega.

4. La IA es una herramienta, no tu reemplazo

Los asistentes de IA son parte del mundo real del desarrollo y está bien usarlos… para aprender más rápido, no para aprender menos.

  • Úsala para que te explique: un error que no entiendes, un concepto nuevo, una alternativa a tu solución. Pídele preguntas, no respuestas.
  • No pegues código que no entiendes. Si la IA escribió algo por ti, reescríbelo tú, cámbiale las partes, rómpelo y arréglalo — hasta que sea tuyo.
  • Sé transparente: si una herramienta te ayudó en una parte, decláralo como cualquier otra fuente.
  • La IA se equivoca con total confianza. Verificar lo que te dice también es programar.

La prueba de la IA: si no puedes explicarlo ni reescribirlo sin ella, no lo entregues todavía.

5. Entender vale más que terminar

  • Un programa que funciona y no entiendes es una deuda; uno que fallaste pero entiendes es un avance. En el curso (y en los parciales, y en las entrevistas de trabajo) se nota la diferencia.
  • Divide y vencerás: problemas pequeños, pruebas pequeñas, commits pequeños.
  • Depurar con calma es la habilidad más subestimada del oficio: leer el error completo, aislar el caso, imprimir el estado.

6. La escalera cuando te atascas

Atascarse es parte del plan. El orden que más te hace crecer:

  • 1. La documentación y el README del proyecto: casi siempre la respuesta ya está escrita.
  • 2. Tu equipo: explicar el problema en voz alta resuelve la mitad de los casos.
  • 3. La IA o internet, para entender: qué significa este error, por qué pasa, qué opciones hay.
  • 4. El profesor: con el intento hecho y la pregunta concreta. Preguntar a tiempo es de buenos programadores, no de malos.

Referentes consultados 📖

Este código destila ideas de políticas de honestidad académica y uso de IA de cursos de programación reconocidos:

Este código aplica a todos los cursos y proyectos. Si tienes dudas sobre un caso concreto, pregunta antes de entregar: esa también es la actitud correcta.

@xacarana

1. The spirit: be reasonable

Everything we do in this course has a single goal: that you learn. The general rule is simple: whatever maximizes your learning is fine; whatever dodges it takes something away from you. Before any shortcut, ask yourself: after this, will I know more, or will I only look like I do?

If an action leaves you the same as before, it wasn't work: it was a costume.

2. Your work represents you

  • Submit only what you can explain line by line. If you can't say what it does and why it's there, it isn't yours yet.
  • Taking inspiration from examples, documentation and other people's code is part of the craft. The version you submit, however, is built by your team, with its own decisions.
  • Give credit: if a resource helped you — a code snippet, a tutorial, artwork, music — say so in the README or a comment. Citing never costs points; hiding costs learning.
  • Every course project is different by design: your version should reflect the decisions, style and ideas of your team.

3. A real team

  • Everyone codes. Splitting the work is fine; splitting the learning is not. Nobody is a spectator or "just does the slides".
  • Commits tell the story: every member contributes their own, with clear messages, evenly and steadily (not everything on the last night).
  • Rotate the hard tasks: if the same person always codes, everyone else is losing the course in slow motion.
  • Review each other's code: explaining your part and understanding your teammate's is the best preparation for the final presentation.
  • Technical disagreements are settled by testing, not by imposing. And speak up early: an absent teammate is a pending conversation, not a delivery-day surprise.

4. AI is a tool, not your replacement

AI assistants are part of real-world development and it's fine to use them… to learn faster, not to learn less.

  • Use it to get explanations: an error you don't understand, a new concept, an alternative to your solution. Ask it for questions, not answers.
  • Don't paste code you don't understand. If the AI wrote something for you, rewrite it yourself, change its parts, break it and fix it — until it's yours.
  • Be transparent: if a tool helped you somewhere, declare it like any other source.
  • AI gets things wrong with total confidence. Verifying what it says is also programming.

The AI test: if you can't explain it or rewrite it without the AI, don't submit it yet.

5. Understanding beats finishing

  • A program that works but you don't understand is a debt; one you failed at but understand is progress. In the course (and in exams, and in job interviews) the difference shows.
  • Divide and conquer: small problems, small tests, small commits.
  • Calm debugging is the most underrated skill of the craft: read the whole error, isolate the case, print the state.

6. The ladder when you're stuck

Getting stuck is part of the plan. The order that makes you grow the most:

  • 1. The documentation and README of the project: the answer is almost always already written.
  • 2. Your team: explaining the problem out loud solves half of the cases.
  • 3. AI or the internet, to understand: what this error means, why it happens, what the options are.
  • 4. Your teacher: with the attempt done and a concrete question. Asking early is what good programmers do.

References 📖

This code distills ideas from academic honesty and AI-use policies of well-known programming courses: