Interactive roadmap · content version 2026-10-19
Four tracks you learn together… and one project that grows with you.
Use AI to learn, reason, implement, and review from day one, and later build evaluated AI features into the product.
Understand, write, test, debug, and operate software.
Understand the domain and the user's need, choose a suitable solution and design, and deliver value. Architecture and business understanding both belong to this track.
Explain, agree, collaborate, document, and lead as your responsibility grows.
The tracks run in parallel and don't need equal time. Practice starts from the first step, and using AI to learn starts on day one; building AI into the product comes later.
One project that grows with you: A learning platform: students, courses, and enrollments first, then lessons, progress, quizzes, security, deployment, integrations, AI capabilities, SaaS, and operational responsibilities.
A draft open to review. The stages describe growing responsibility; professional roles are proven through practice and impact, not checkboxes.
Six stages from top to bottom and four fixed tracks side by side. Pick a stage to see its steps, and open any step for its details.
| AI | Java Backend | Business, design & delivery | Communication & professional | |
|---|---|---|---|---|
| 01BeginnerSteps 01–04 · An in-memory course program | AIExplanations, hints, and review | Java BackendJava, OOP, Git, and tests | Business, design & deliveryEnrollment rules and simple responsibilities | Communication & professionalA clear question and an explained decision |
| 02Junior foundationsSteps 05–07 · A backend with persistent data | AIData-model critique and an IDE assistant | Java BackendSQL, HTTP, and Spring Boot | Business, design & deliveryERD and API contracts | Communication & professionalDocumentation and work with Frontend and QA |
| 03Capable JuniorSteps 08–10 · A deployed student journey | AIReview, tests, and a bounded agent | Java BackendSecurity, Docker, and CI/CD | Business, design & deliveryPermissions, quality, and releases | Communication & professionalDemo and runbook |
| 04Mid-levelSteps 11–14 · A complete feature that tolerates failure | AIAnalysis and model integration | Java BackendConcurrency, performance, and integrations | Business, design & deliveryConsistency, payments, and value | Communication & professionalOwnership, estimation, and trade-offs |
| 05Preparing for Senior responsibilitiesSteps 15–18 · An important part you can operate | AIRAG and tool calling | Java BackendMulti-tenancy and observability | Business, design & deliverySaaS, SLOs, and scaling | Communication & professionalLeadership and mentoring |
| 06Staff / Architect and beyondSteps 19–21 · Impact across teams | AIOperating, evaluating, and enabling teams | Java BackendPlatform and deep specialization | Business, design & deliveryStrategy and economics | Communication & professionalInfluence and growing leaders |
Stage 1 · Steps 01–04
Stage goalStart using AI and build a foundation that helps you understand and review, with an in-memory program that manages courses, students, and enrollments.
Exit evidenceYou run the program and explain its behavior, add a new rule, and diagnose a bug and prove the fix with a test.
OutcomeAn in-memory course program
Where do we apply this in the platform? Run a Java program that shows course data, and define the teacher, student, course, and enrollment as the platform's first scope.
Where do we apply this in the platform? The enrollment-eligibility rule: who can enroll in a course, with written success and rejection cases that match the program's behavior.
Where do we apply this in the platform? An in-memory model of students, courses, and enrollments that prevents duplicate enrollment and respects course capacity.
Where do we apply this in the platform? The platform's first repository: a build from a clean checkout, a test that prevents duplicate enrollment, and a reviewable PR.
Stage 2 · Steps 05–07
Stage goalTurn the program into a backend with persistent data and APIs for courses, lessons, and enrollment.
Exit evidenceYou trace a request to the database, justify the model and the API contract, change a requirement and test it, and someone else can use your documentation.
OutcomeA backend with persistent data
Where do we apply this in the platform? Move students, courses, and enrollments to PostgreSQL, with an Enrollment table and constraints that prevent duplicates.
Where do we apply this in the platform? An API contract for listing courses, enrolling, and rejection cases, agreed before implementation.
Where do we apply this in the platform? A Spring Boot backend with APIs for courses, lessons, and enrollment, and documentation someone else can use.
Stage 3 · Steps 08–10
Stage goalAdd accounts, permissions, lessons, quizzes, and results, and deliver a complete student journey on a deployed environment.
Exit evidenceYou deliver a small feature from understanding the requirement through deployment and follow-up, and you know when you need help or review.
OutcomeA deployed student journey
Where do we apply this in the platform? Accounts and roles: a student sees only their own enrollments and a teacher edits only their own courses, even with a direct request.
Where do we apply this in the platform? Tests for the lesson, quiz, and result journey that catch any grading bug before it is fixed.
Where do we apply this in the platform? A complete student journey on a deployed environment: sign in, choose a course, enroll, take a lesson and a quiz, and see the result.
Stage 4 · Steps 11–14
Stage goalHandle business rules, concurrency, performance, integrations, and failure with more independence, and build a first useful AI feature for teachers.
Exit evidenceYou own a medium-sized feature from requirements to operation, handle integrations and failure cases, and explain your trade-offs, with review matched to the risk.
OutcomeA complete feature that tolerates failure
Where do we apply this in the platform? Protect the last seat in a course from concurrent enrollments, with a test that proves the result.
Where do we apply this in the platform? Speed up course and progress listings with a specific measurement, and protect lesson files from unauthorized access.
Where do we apply this in the platform? Payments and notifications: a duplicate payment webhook doesn't duplicate the enrollment, and an email outage doesn't lose the job.
Where do we apply this in the platform? Draft quiz questions generated by AI and reviewed by the teacher, who can edit or reject them, with quality, cost, and latency measured.
Stage 5 · Steps 15–18
Stage goalHandle more ambiguity and risk, and improve both the system and the team; add a content assistant and permissions, and study SaaS, reliability, and distribution when they are needed.
Exit evidenceYou own an important part across design, implementation, and operation, reduce its risks, guide others, and work with incomplete requirements. Doing this with a real team and real users is a core part of proving it.
OutcomeAn important part you can operate
Where do we apply this in the platform? An assistant that answers students only from the course content they are allowed to access, with citations and tests that prevent leaks.
Where do we apply this in the platform? The platform serves centers and teachers with isolated data, plans and subscriptions, and a gradual migration plan.
Where do we apply this in the platform? Monitor the platform with metrics, logs, and traces, and run an exercise of a failing external dependency and service recovery.
Where do we apply this in the platform? An assistant that reads a student's progress and suggests a plan without changing an enrollment or a grade, and splitting a service only with proven justification.
Stage 6 · Steps 19–21
Stage goalConnect technical direction to platform economics and enable multiple teams. Staff and Architect may be different paths, not necessarily consecutive ranks.
Exit evidenceInitiatives adopted by several teams, lasting measurable results, and knowledge and ownership that continue without depending on you day to day.
OutcomeImpact across teams
Where do we apply this in the platform? Reproducible environments for several teams, and measured cost per center, student, and AI session.
Where do we apply this in the platform? API and event governance across the platform's teams, and shared migrations that don't break consumers.
Where do we apply this in the platform? A deep specialization that solves recurring problems in the platform, and leaders and teams who carry the direction forward independently.
Progress is saved on this device only and is never sent to a server. Switching devices or clearing browser data can erase it, so back it up with export.
Each diagram has one purpose and a written explanation. Technical diagrams are available as SVG, and editable sources as Mermaid.
Why we need the four tracks
State 1 of 5
Relies on AI to produce the product.
State 2 of 5
Adds the ability to understand, write, review, and debug code.
State 3 of 5
Adds system organization and technical trade-offs.
State 4 of 5
Adds user needs, business rules, priorities, time, and cost.
State 5 of 5
Adds communication, coordination, and delivery with others.
A shared trap anyone can fall into at any stage: collecting lots of knowledge without applying it. It isn't a sixth rank or a promotion.
Five successive states. AI is present in every state. Each state adds one capability, and the gaps still open stay visible: understanding code, system design, solution fit, and communication and delivery. System design and solution fit belong to the same third track. A separate shared trap comes at the end: the spectator.
Moving from watching to applying
Two loops. The first is a trap: you watch, feel you understood, start a new course, postpone practice, and go back to watching. The second is learning by doing: a small problem, guided learning, implementation, testing and adjusting, explaining the decision, then a new problem. The bridge between them: start with a small change of your own. The result: a platform feature + a test + an explanation. AI supports learning and review; the decision is yours.
A template for explaining any step
An example card for step 11. The problem: two people booking the last seat. We learn concurrency, transactions, and locking to keep course capacity correct under concurrent requests. The target evidence is a test scenario: 10 concurrent requests for the last seat produce exactly one successful enrollment and no negative capacity. The independent challenge: change the booking policy and explain its impact.
Connecting the stages to what we actually build
Modules don't necessarily mean microservices. · Rectangle: a module inside the application · cylinder: a database · dashed frame: an external dependency
Six simplified states of the same project. Modules are rectangles, databases are cylinders, and external dependencies have a dashed frame. Separate modules don't mean microservices.
Tracing a request and its errors
We never trust a studentId supplied by the client; we use the verified identity. A pre-check alone doesn't prevent a concurrent duplicate; the UNIQUE constraint does.
A logical teaching example, not documentation of a real implementation. Access Check is a responsibility, not an ordering of Spring Security classes. Capacity and payment are outside this example.
A student enrolls themselves through POST /courses/{courseId}/enrollments. The client sends the request and credentials to the API. The API verifies identity and role through Access Check: an invalid identity returns 401, and an allowed identity with a disallowed role returns 403. Only on success does the API pass the verified student identity and courseId to the Enrollment Service. The service loads the course: a missing course returns 404, and unavailable enrollment returns 409. It then inserts the enrollment under a UNIQUE(student_id, course_id) constraint; success returns the enrollment ID and then HTTP 201, and a duplicate is mapped to 409. PostgreSQL never responds to the client directly.
What learning in parallel means
Feature: Preventing duplicate enrollment · A contribution matrix, not a sequence of services.
| Track | Understand | Design | Implement | Verify | Explain |
|---|---|---|---|---|---|
| AI | Questions that expose ambiguity | Critique the alternatives | Bounded assistance | Suggest failure cases | Review the explanation's clarity |
| Java Backend | Read the current behavior | A suitable data constraint | Service + SQL | A concurrent test | Show the code and the result |
| Business, design & delivery | Define a duplicate | The error contract | A small feature scope | Accept success and rejection | Deliver the journey |
| Communication & professional | Clarify the requirement | Agree with Frontend and QA | Update progress | Review with a colleague | Demo and a documented decision |
A contribution matrix for one feature, preventing duplicate enrollment, across five work phases and the four learning tracks. These are each track's contributions in each phase, not services talking to each other.
AI helps me build, and AI inside the product
The developer
Understanding and decisions stay with you
The teacher
The teacher makes the final decision
Two different roles for AI. First: AI helps me build; the developer uses it for learning, planning, implementation, and review, and the understanding and the decision stay with the developer. Second: AI inside the product; the teacher receives a draft of questions and can review, edit, or reject it.
Reducing distraction
A decision tree. First question: is the tool needed for my current step? If yes: does the simplest available solution meet the need? If yes, use the simpler solution and apply it; if not, identify the constraint, try a small alternative, measure, then choose. If the tool isn't needed for your step: does it serve a specific learning goal or job role? If yes, run a bounded learning experiment; if not, keep it on a later list. Examples: microservices when there is a separation need, Kubernetes for an operational need, Kafka for an event or streaming need. This isn't a ban on exploration or a ranking of tools.
Evidence of learning and a checklist
Example: enrolling in a course
I explain the idea and its limits in my own words.
I explain why Enrollment is its own entity, and when a UNIQUE constraint isn't enough on its own.
I apply it to a new requirement.
I add a rule that enrollment closes one day before the course starts.
I reproduce a bug and fix it.
I reproduce a duplicate enrollment, fix it, and prove the fix with a test.
I test the behavior and explain my choice.
I write tests for success and rejection, and explain why I chose a database constraint.
This list is for you, not a certificate. Next to each piece of evidence, write a link or a note that proves it. Print the evidence checklist
Four types of evidence of learning, using course enrollment as the example: explain, change, diagnose, and prove and justify. With a printable checklist that has room for links and notes.
Why Enrollment is its own entity
Three entities. Student has id as primary key and name. Course has id as primary key and title. Enrollment has id as primary key, student_id and course_id as foreign keys, and enrolled_at, with a composite UNIQUE constraint on student_id and course_id. A student has zero or more enrollments, and each enrollment belongs to exactly one student. A course has zero or more enrollments, and each enrollment belongs to exactly one course.
All files work without an account. Print actions open your browser's print dialog, where you can save as PDF.
For roles, technical collaborations, or consulting on backend systems and enterprise integration, email me or connect with me on LinkedIn.
