Skip to main content
DevScallix

How we teach

Learn. Build. Review. Defend. Ship.

You can't learn programming by watching it. We teach the way teams work: code gets written, reviewed, explained and delivered in a running state.

See the examplesJava Backend Career Track

Method

You learn by working like an engineer, not by watching videos.

Every topic goes through the same five steps. What you built, what changed in review and how you explained your decisions are all visible — progress is shown, not guessed.

  1. 01

    Learn

    You learn the topic from an instructor — the “why” before the “how”.

  2. 02

    Build

    You turn it into working code straight away. Assignments look like real requirements.

  3. 03

    Review

    Your code is reviewed as a Pull Request. You get specific feedback and improve it.

  4. 04

    Defend

    You explain your decisions: why this structure, this name, this approach. We discuss the alternatives.

  5. 05

    Ship

    You hand in work that is finished, tested and running — not “almost done”.

Each loop strengthens the next. Over time, that's what Scale means: bigger systems, bigger responsibility.

Code Review

How your code gets reviewed

In real teams, code isn't accepted just because it runs. It's read, discussed and improved. In this program that's part of every assignment.

  1. 01

    Submit a Pull Request

    You submit assignments as Pull Requests on GitHub, the way teams do.

  2. 02

    Specific feedback

    Explained comments on naming, structure, tests, error handling and design.

  3. 03

    Iterate

    You rework the code based on feedback — the part where most of the learning happens.

  4. 04

    Defend

    You explain why you did it this way. We discuss alternatives and trade-offs.

Engineering evidence

This is what real engineering looks like.

Three short training examples: a code review, an engineering decision and getting code to a running state. Every assignment in the program goes through this.

PR #27 · Find an order by id

OrderService.java

public Order findOrder(Long id) {
Removed: return repository.findById(id).get();

Mentor

`.get()` throws NoSuchElementException when the order doesn't exist, and the user sees a 500. Throw a clear exception so the API can return a 404.

Added: return repository.findById(id)
Added: .orElseThrow(() -> new OrderNotFoundException(id));
}

OrderServiceTest.java

Added: @Test
Added: void throwsWhenOrderIsMissing() {
Added: assertThrows(OrderNotFoundException.class,
Added: () -> service.findOrder(42L));
Added: }

Mentor

Good. This test protects the behaviour the next time someone changes this method.

Why this change was requested

  1. The user gets a clear answer: 404, not 500.
  2. The exception name explains the problem on its own.
  3. The test protects this behaviour from future changes.

Training example · not real student work

Tutorials vs real engineering

A tutorial asks “does it work?”. An engineer asks more.

We don't overload beginners. But from day one we teach you to ask the right questions.

Requirements
Tutorial: Repeat the steps
Real engineering: Understand the problem, clarify the requirements
Trade-offs
Tutorial: There's one right answer
Real engineering: Compare options, justify the choice
Clean Code
Tutorial: If it runs, it's fine
Real engineering: Someone else must be able to read and change it
Testing
Tutorial: Check it by hand once
Real engineering: Protect behaviour with automated tests
Code Review
Tutorial: Nobody looks
Real engineering: Every change is read and discussed
Architecture
Tutorial: Everything in one file
Real engineering: Separate responsibilities, draw boundaries
Deployment
Tutorial: Works on my machine
Real engineering: Runs the same way everywhere
Observability
Tutorial: Guess when it breaks
Real engineering: Use logs and metrics to see what's happening

Learn. Build. Scale.

Apply to the founding Java Backend cohort.

The founding cohort will be small and taught by the founder. Applying creates no payment obligation.

Apply nowQuestions & answers