Eccentric Academy no nació de un plan de negocios cerrado, sino de una serie de decisiones concretas sobre qué enseñar, en qué orden y con qué nivel de exigencia. Repasamos los tramos que marcaron el rumbo, desde las primeras clases sueltas hasta la estructura de módulos que usamos hoy.
Todo empezó con grupos pequeños de personas que querían entender qué pasaba detrás de una pantalla. Las sesiones eran presenciales, con un proyector y muchos ejercicios escritos a mano antes de tocar el teclado. Ahí quedó claro que la práctica guiada funcionaba mejor que cualquier explicación larga.
Cuando el alumnado empezó a llegar con niveles muy distintos, improvisar dejó de servir. Reorganizamos el contenido en módulos con un orden fijo: entorno, lógica, estructuras de datos y luego proyectos. Cada módulo cierra con un ejercicio entregable para no avanzar con huecos sin resolver.
Sumar conceptos de arquitectura, control de versiones y bases de datos relacionales cambió el perfil de los cursos. Ya no se trataba solo de aprender a programar, sino de entender cómo se sostiene una aplicación cuando crece y la toca más de una persona. Esa etapa definió el enfoque técnico actual.
Incorporamos perfiles que desarrollan software todos los días y traen casos concretos a clase: errores que aparecieron en producción, decisiones de diseño que hubo que revertir, revisiones de código incómodas. Ese material no se encuentra en un manual y es el que más consultas genera después de cada sesión.
Muchas personas terminan un módulo y quieren seguir practicando sin un docente al lado. Armamos espacios de consulta y ejercicios abiertos para que el aprendizaje no se corte al terminar la última clase. La constancia, más que el talento inicial, es lo que sostiene ese recorrido.
Una academia técnica no se sostiene solo con temarios: se sostiene con criterio sobre lo que conviene aprender y en qué orden.
Cada módulo termina con algo que funciona: un script que lee datos, una interfaz que responde, una consulta que devuelve lo esperado. La teoría entra cuando ya hay una pregunta concreta sobre la mesa, no antes. Así el estudiante recuerda el concepto porque lo necesitó para resolver algo real.
Preferimos avanzar despacio y bien: entender qué hace una función antes de copiarla, saber leer un mensaje de error antes de buscar la solución en un foro. La prisa por cubrir temas suele dejar huecos que después cuestan el doble de cerrar. Nuestro ritmo está pensado para que las bases queden firmes.
Editores con los que trabaja la industria, control de versiones, terminal, documentación oficial en inglés técnico. No simulamos un aula ideal: usamos lo mismo que se encuentra alguien en su primer trabajo o en su primer proyecto propio. Familiarizarse con ese entorno desde el principio ahorra frustraciones después.
El objetivo no es que alguien dependa de un curso para siempre, sino que llegue a plantearse sus propios problemas y buscar cómo resolverlos. Cuando un estudiante puede leer una especificación, probar una idea y depurarla sin ayuda constante, el proceso formativo ha cumplido su función.
A lo largo de los distintos módulos, la academia trabaja con estudios de desarrollo, áreas de sistemas de empresas locales y grupos de docencia técnica que aportan casos reales, revisan materiales y abren sus entornos para prácticas puntuales. No se trata de patrocinios publicitarios: son acuerdos de contenido y acompañamiento que mantienen los programas cerca de lo que ocurre hoy en los equipos de software.
Aporta ejercicios de revisión de código y participa en las sesiones de cierre de los módulos de desarrollo de aplicaciones, con devoluciones escritas sobre los proyectos entregados.
Colabora en el diseño de contenidos sobre sistemas digitales y administración de entornos, además de recibir visitas guiadas para conocer cómo se organiza un área de infraestructura.
Revisa la progresión pedagógica de los módulos introductorios y comparte materiales abiertos sobre lectura de documentación y buenas prácticas de estudio.
Propone esquemas de bases de datos reales para los ejercicios de modelado y consulta, y acompaña las prácticas de normalización con ejemplos de su propio trabajo.
Agrupa a egresados y profesionales que acompañan a quienes recién empiezan, resolviendo dudas puntuales sobre entornos, herramientas y primeras entregas.
Recorrido formativo desde los primeros pasos hasta la práctica técnica sostenida
Primer contacto con el editor, la consola y la lectura de errores. Se trabajan variables, condicionales y bucles con ejercicios que se ejecutan en la misma sesión, sin acumular teoría sin aplicar.
Listas, diccionarios y funciones propias para organizar programas cada vez más largos. Aquí se instala la costumbre de dividir problemas y nombrar bien lo que hace cada bloque de código.
Formularios, rutas, manejo de errores y variables de entorno. El módulo cierra con una aplicación pequeña revisada con criterios de accesibilidad y peso de imágenes antes de publicarla.
Modelado de entidades, relaciones y claves antes de escribir la primera consulta. Se comparan esquemas normalizados y duplicaciones por comodidad según el caso de uso real.
Control de versiones, entornos de trabajo y lectura de documentación oficial. El objetivo es que cada estudiante pueda sostener su propio avance sin depender de un tutorial cerrado.
Cada persona arma una entrega propia, la documenta y la defiende ante el grupo. La revisión se centra en decisiones de estructura, no en la apariencia del resultado.

Eccentric Academy nació con una idea sencilla: enseñar programación, ingeniería de software y sistemas digitales sin adornos ni atajos. Trabajamos con módulos estructurados que van del entorno local a los primeros programas funcionales, y de ahí hacia el desarrollo de aplicaciones y los conceptos que sostienen cualquier proyecto real.
Nuestro alumnado es variado. Hay quien nunca escribió una línea de código y quiere empezar con orden, y hay quien ya trabaja en tecnología y busca actualizar prácticas, revisar fundamentos o incorporar herramientas que dejó pendientes. La academia no promete atajos ni resultados inmediatos: propone constancia, curiosidad y ejercicios que se ejecutan, se rompen y se vuelven a armar.
El tono que usamos es directo y profesional. Explicamos con claridad, mostramos el porqué de cada decisión técnica y reservamos espacio para la práctica desde la primera sesión. La identidad visual acompaña esa idea: azul marino profundo, acentos en cian y una tipografía sobria que no compite con el contenido.