Structured modules for programming, software development, and the IT fundamentals that hold a project together. Start with the basics, work through practical examples, and keep going at your own pace.
Why the academy exists, and what we want learners to walk away with.
Every pathway starts with a small, finishable unit: variables and control flow, then functions, then data. We resist the urge to jump into frameworks before the fundamentals hold. Learners who finish a module can explain what they built and why it works, not just that it ran.
We teach the reasoning behind a choice, not just the syntax. When a learner picks a database, a data structure, or a testing strategy, they should be able to justify it in a code review. That habit outlasts any specific tool or version.
Most of our learners study around a job, a degree, or a career change. Modules are sized to fit evenings and weekends, with clear stopping points. Progress is measured by what you can build and explain, not by hours logged or streaks kept.
We are a learning environment, not a placement agency or a certification body. We do not promise jobs, salaries, or guaranteed outcomes. What we offer is a clear sequence of material, practical exercises, and feedback loops that help you build genuine capability over time.
Short, focused write-ups we keep coming back to in class: how to read a failure, how to pick a data model, how to write tests that don't fight you later. Each one stands on its own, but they follow the same idea as our modules — understand the mechanism before you reach for a tool.
Reading a Stack Trace Without Panic
Debugging method
A stack trace is a map, not a verdict. We walk through a small service and show how to read frames from the exception line outward, separate library noise from your own code, and reproduce the failure in a single test. There is also a section on the common trap of fixing the last frame instead of the first one that actually belongs to your project.
Read the full article
Choosing Between SQL and Document Stores
Data modelling comparison
The decision is usually made by access patterns, not by what is trending. We model the same three features — order history, user profiles, audit logs — in both systems and look at where joins stay cheap and where they start to hurt. Transaction boundaries, migration cost, and the point where denormalisation becomes the simpler option all get a closer look.
Read the full article
Writing Tests That Survive Refactoring
Testing practice
Suites that assert on internal method calls tend to break the moment you reorganise code, even when the feature still works. We compare two versions of the same checkout test suite and see which assertions survive a refactor. Test doubles, boundary selection, and the difference between testing a unit and testing a contract are covered along the way.
Read the full articleThree pieces that pair well with the current module. They pick up where the lesson notes stop: a debugging routine, a data modelling decision, and a testing habit that saves you time later. Read one after a session, not all three at once.
A stack trace is a map, not a verdict. This walkthrough uses a small Python service to show how to scan frames from the exception line outward, separate library noise from your own code, and reproduce the failure in a single test before touching anything.
Open the articleThe same three features — order history, user profiles, audit logs — modelled twice. Where joins stay cheap, where they start to hurt, and the point at which denormalisation becomes the simpler option. Ends with a checklist you can run against your own requirements.
Open the articleTest suites that break on every rename usually assert on internal calls instead of observable behaviour. Two versions of the same checkout test suite, compared side by side, to show which assertions survive a refactor and which just add maintenance work.
Open the article