Skip to content

Learn to think in objects

Fourteen weeks at University Metropolitan Tirana. You arrive able to write code that runs. You leave able to design scalable software that survives being changed.

Open the roadmap Start week 1

From scattered requirements to connected objectsNine small scattered squares sit at the top of the image, tilted at different angles, representing loose and unstructured requirements. An arrow points downward. Below it, three rounded rectangles represent objects, each showing a class name and two fields, joined to one another by connecting lines to show that they collaborate.

Most programs start as a pile of requirements. The work is turning them into objects that own their own data.

  • One app, three sprints

    You build it, rebuild it properly once you know what a weak design costs, then finish it. Not twelve exercises you throw away.

  • A portfolio, not a CV line

    Your work is public on GitHub from week one. When somebody asks what you have built, you send them the repository.

  • Core skills

    The ones you are asked to demonstrate after the course, not just describe.

What you will be able to do

  • Design with objects


    Read a description of a system and decide what the classes are, so that a change next month touches one file instead of eleven.

  • Read an error and fix it


    Turn a compiler message or a stack trace into the line that is wrong, without guessing and without asking anyone.

  • Handle failure


    Write code that refuses bad input, says why, and keeps going. Most student programs crash. Yours will not.

  • Test your own work


    Prove your code works before you claim it does. This is the skill most graduates arrive without.

  • Write Java people are writing now


    Do in three lines what a textbook from 2010 does in fifteen, and know when the short version is the wrong choice.

  • Build something that lasts


    Save your data, load it back, and put a window on top. Your program closes and your work is still there.

What you build

One application, across the whole semester. You do not start over, you keep going.

  • Sprint 1

    Your first real program. Classes you designed yourself, holding data that cannot go wrong. It runs in a terminal and it does something useful.

  • Sprint 2

    You rewrite it, now that you have felt what a weak design costs. It saves your work, survives bad input, and has tests that prove it still works.

  • Sprint 3

    A window on top, and a file you can send to someone who will just run it. The model underneath barely changes, and that is the whole argument.

How you learn

  • Lectures

    Two hours a week, in two sessions, each with a page to read and code written live. Read them with the editor open and type along, because reading code and writing code are different skills.

  • Seminars

    Two hours a week where you build things yourself. The exercises use a different problem from the lecture on purpose, because applying an idea somewhere new is what makes it stick.

  • Projects

    Three sprints across the semester, each one extending the last. The sprints are not optional practice. They are the course.

Fourteen weeks. Four modules. One thing you built.

The roadmap shows every module, what you can do once you have finished it, and where the course has reached right now.

See the roadmap