Services | BushTech Academy

Modules are written by working developers, not rewritten from vendor documentation. Each one ends with a task you can actually run.

What the academy covers, and how the modules are built

The curriculum is split by discipline rather than by difficulty level, so you can enter at the section that matches the work in front of you. Every module states its prerequisites, the tooling it assumes, and what you should be able to build once you finish it.

Language foundations

Syntax, types, and control flow explained through small programs you run locally. Covers reading compiler and interpreter messages instead of guessing at them.

Software design and structure

How to break a feature into modules, name things consistently, and keep interfaces stable while the internals change. Includes refactoring exercises on a deliberately messy codebase.

Version control and review

Branching, commit history, and pull request hygiene for teams larger than one. Focused on diffs a reviewer can read in a single sitting.

Data and persistence

Relational schemas, query patterns, and the trade-offs between normalizing and denormalizing. Worked against a sample dataset with real edge cases.

Web and API layers

Request handling, status codes, authentication flows, and versioning an endpoint without breaking existing clients. Debugging tools included.

Testing and debugging practice

Unit and integration tests that catch regressions rather than inflate coverage numbers. Stack trace reading, logging levels, and isolating a failure to one frame.

Modules are self-paced. You keep access to the reference material and the exercise repositories after finishing a section.

How a Module Moves From Question to Working Code

Every track in BushTech Academy follows the same route: a concrete problem, a short technical brief, a build step, and a review that decides what stays. Nothing is published until it has been tested against a real project file.

Steps below describe the standard path. Some modules stop earlier if the topic is narrow, and a few run a second review pass when the code touches shared systems.

1. Intake and topic framing

A learner or instructor submits a question, a failing build, or a concept that keeps causing confusion. We write it down as a single sentence with the language, framework, and version attached, so the scope stays fixed before any material is drafted.

2. Technical brief and outline

The brief lists what the module must cover, what it deliberately leaves out, and which prior modules it depends on. Prerequisites are checked here, not later, because a missing foundation is the most common reason a lesson does not land.

3. Drafting the working example

Each module is built around one runnable example: a small service, a data transform, or a refactor of an existing file. Comments explain the decision points, and the example is kept short enough to read in one sitting without skipping lines.

4. Review against real code

A second person runs the example in a clean environment, checks the error paths, and flags anything that only works because of a local setting. Version-specific behaviour and deprecated calls get corrected at this stage rather than in a footnote.

5. Publication and revision

Approved modules go into the catalogue with their prerequisites, estimated reading time, and the exact tool versions used. When a language or library changes in a way that breaks the example, the module is revised and the change is noted at the top of the page.

Feedback from learners who finished the modules

What changed after the course, in their own words

Send your own notes

Shannon Shaw

I came in able to write scripts but not to explain them. The debugging section forced me to read a stack trace from the bottom frame up, and that habit alone cut my fix time roughly in half. The exercises are small enough to finish after work, which is the only reason I kept going.

Isabel Taylor

The module on splitting files arrived right when our repository had turned into one folder nobody wanted to touch. I used the checklist on a service of ours and moved one responsibility out at a time. Reviewers stopped asking me to explain the diff, which was the whole point.

Molly Taylor

I joined a team of five with no shared habits around branches or commit messages. The workflow material gave us a starting point we could actually agree on, and the review requests got shorter. Nothing here is clever, it is just written down clearly enough to follow.

Nicole Thomas

Most of what I knew about systems came from fixing things after they broke. Working through the fundamentals track gave me the vocabulary to describe what a service actually does before writing code. I still keep the notes open during planning meetings.

Pick the track that matches how you already work

Every track covers the same core ground: reading code, writing it carefully, and understanding what runs underneath. What changes is the depth, the pace, and how much of your own project you bring into the room. Choose the one that fits your week, not the one that sounds most impressive.

Foundations Track

For people who can follow a tutorial but freeze when the file is empty. Covers syntax across one language, control flow, functions, and the debugging habits that make errors readable. Weekly exercises are small and reviewed line by line.

Best if you are starting from scratch or coming back after a long break.

Start with Foundations

Application Track

Builds on working knowledge of a language. Focuses on structuring a real application: modules, data flow, version control, and testing enough to trust your own changes. You bring a project and leave with it running.

Suited to developers who write code alone and want it to survive a second contributor.

Choose Application

Systems Track

For those already comfortable shipping software. Covers what sits behind the application: networks, storage, deployment pipelines, and the operational trade-offs that decide whether a system stays up. Reading material is dense and assumes prior experience.

Recommended for engineers moving toward infrastructure or platform work.

Enter Systems

Questions we hear before someone starts the first module

Most of what people ask is practical: how the material is ordered, what they need installed, and how much time a section takes. Below are the answers we give most often.

Do I need prior programming experience to begin?

No. The first track assumes you can use a terminal and edit a text file, nothing more. We start with variables, control flow, and reading error messages before touching frameworks. If you already write code daily, you can skip ahead to the software concepts section without losing the thread.

What tools should be installed before the first session?

A code editor, a current runtime for the language you pick, and Git. That covers the early modules. Later sections on digital systems introduce a database client and a container runtime, but we list those in the module notes so you are not installing anything blind.

How are the modules ordered, and can I jump around?

Modules run from language fundamentals through software design to deployment and systems work. The order is deliberate, but each section opens with a short prerequisite list. If you already know the material in a section, read the prerequisites and move on. Skipping without checking them is where most people get stuck.

How much time does a typical section take?

Plan on a few evenings per section if you do the exercises. Reading alone is faster, but the exercises are where the concepts settle. The coding practice modules take longer than the conceptual ones, and the systems material rewards a slower pace.

Is the material tied to one language or stack?

No. The coding practices and software concepts sections are language-neutral and use examples in more than one language where it helps. The digital systems material leans on common tooling, but the reasoning applies whether you work in Python, JavaScript, or something else.

Can I ask questions while working through a module?

Yes. Send them to info@bushturkeytrailrunners.com or call 0282 7758267. We answer technical questions about the exercises directly. For anything about enrollment or access, the contact page has the full details.