The platform did not start as a catalogue of courses. It started as a set of notes shared between a few instructors who kept running into the same problem: learners arriving with fragments of knowledge and no order to put them in. What follows is a short account of the decisions that turned those notes into a working curriculum.
The first material was plain: written explanations of variables, loops, and functions, passed around as files. There was no interface and no structure beyond folders. That phase lasted longer than expected, mostly because every attempt to organise the notes revealed gaps in how the topics connected.
The turning point was agreeing that sequence matters more than coverage. Instead of listing every topic a developer might eventually need, the team committed to a linear path where each module assumes only what came before it. That decision removed a lot of tempting material from the early stages.
Each module settled into a consistent shape: a short concept explanation, a worked example, and a small task that fails in a predictable way if the concept is misunderstood. The format was tested with first-year learners, and the parts that caused confusion were rewritten rather than explained again.
Learners kept hitting walls that had nothing to do with syntax: file systems, environment variables, how a request reaches a server. A parallel track of IT fundamentals was added so that programming modules would not have to carry that weight on their own.
Today the curriculum covers programming basics, version control, backend and frontend work, and the infrastructure concepts that sit underneath. The structure is deliberately conservative. New topics are added only when they fit an existing module or open a clear next step for someone who has finished the previous one.
The modules you see today were not designed in one sitting. They were assembled year by year, each stage answering a problem that earlier learners kept running into: too much theory before the first working file, no clear order between topics, and no honest picture of what a junior developer actually does in week one.
Prof. Stefan Kofler wrote the initial sequence on paper: variables, control flow, functions, then a small command-line tool. The rule from day one was that every concept had to end in something runnable, not a quiz.
After a term of lost student work, git was pulled forward from the advanced track. Verena Wurm MBA. restructured the exercises so branches and rollbacks were practiced on real group projects instead of toy repositories.
Christian Hahn separated the backend material into Node, Python, and Java paths. Learners picked one after finishing the shared fundamentals, which cut the dropout rate in the second module noticeably.
Andrea Beck B.Sc. added a dedicated block on reading stack traces, isolating failing input, and reproducing errors in smaller files. It sits between fundamentals and the first framework, where students hit their first real wall.
Two modules were merged and one was dropped entirely after review sheets showed the same complaint three terms in a row. The remaining sequence is shorter than the original plan and easier to follow.
The platform now runs on a fixed order: fundamentals, tooling, debugging, one backend path, then a small project. Each stage has a defined exit point, so learners know when they are ready to move on.
Who we are and who we teach
You have used software your whole life but never opened the editor. The first modules deal with syntax, variables, loops, and the small mental model of how a program runs line by line. We keep the tooling minimal so the language itself stays in focus.
If you can follow a recipe, you can follow a loop. The rest is repetition.
Maybe you can build a page but freeze when a project grows past three files. Here the modules move into structure: functions, data handling, version control, and reading someone else's code without guessing. This is where scattered knowledge turns into a working method.
Knowing how to write code is not the same as knowing how to keep it readable.
Backend logic, databases, APIs, and the deployment questions that come after the code works on your laptop. These modules are slower on purpose. We would rather you understand why a request fails than memorize a fix that only works once.
A bug you understand is a lesson. A bug you copy-pasted is a debt.
File systems, networks, the browser, the terminal, how data moves between machines. These topics rarely feel urgent until something breaks. We teach them early so the later modules have somewhere to stand.
The terminal is not hostile. It is just quiet and literal.