Each session is a real, named topic — but framed around the way of thinking, not the syntax of any stack. Engineers leave with mental models that travel.
3
Domains
34
Sessions
1h
Each
∞
Stacks
01
Sessions name real topics engineers can point to — auth, databases, crash reporting, concurrency.
02
Each session installs a way of thinking first, then grounds it in concrete examples from your project.
03
Each domain has the sessions it genuinely needs — no padding, no forced symmetry.
DomainPhase
0112 sessions
Backend + Ops
How to think about systems that hold state, serve many, and must not lie.
Foundations
W1
How our backend actually works
Every backend, in any language, is a function from request to response — with side effects you must reason about.
Live walkthrough
A guided tour of a real feature's lifecycle — from request entering through routing, business logic, data access, and response. The point isn't the framework; it's the shape every backend follows.
Key Takeaways
The shape of any backend: input → identity → logic → state change → output
Where side effects live and why that matters when something goes wrong
How to read a backend's structure as a map of decisions
The questions you should answer about any backend you encounter
Session Flow
0:00–0:10The request lifecycle in any backend — the universal shape
0:10–0:35Live trace: pick a real endpoint, follow it from entry to response
0:35–0:50Discussion: walk through requests in your current project
0:50–1:00Wrap-up: the backend orientation checklist
W2
What is a server
A server is a process that listens, responds, and outlives any single request. Containerisation makes that process portable.
Discussion + demo
What a server actually is at the OS level — a process bound to a port, handling concurrent requests, with finite resources. Why containers matter as reproducibility, not magic.
Key Takeaways
A server as a long-running process, not a magic box
Why ports, processes, and resource limits matter everywhere
What containerisation solves — reproducibility, not virtualisation
How to reason about where your code actually runs
Session Flow
0:00–0:12A server is a process: what that means at the OS level
0:12–0:28Live: start a server locally, look at the process, kill it, restart it
0:28–0:45Containerisation: what Docker solves and what it doesn't
0:45–0:55Discussion: where does "the server" actually live in your project?
0:55–1:00Wrap-up
W3
Database
A database isn't storage. It's a system that promises to remember what you told it — and a set of guarantees about how that memory behaves.
Discussion + walkthrough
How to think about a database as a contract. Schema, indexes, transactions, and data integrity as tools for keeping the system honest. Stack-agnostic.
Key Takeaways
A database as a set of guarantees, not just storage
Schema as documentation of what you're promising about data
Why indexes exist and what they cost
Transactions as the answer to "what if this fails halfway"
Session Flow
0:00–0:12What a database actually does: persistence, integrity, concurrency
0:12–0:30Schema and indexes: walked through with real examples
0:30–0:45Transactions and the failure modes they prevent
0:45–0:55Discussion: what does your database promise that you depend on?
0:55–1:00Wrap-up
W4
Auth
Auth is two questions, always. Who are you, and what are you allowed to do? Most auth bugs are confusion between the two.
Discussion + walkthrough
Authentication vs authorisation as two distinct concepts. Sessions, tokens, identity flow. Stack-agnostic — JWT, sessions, OAuth all serve the same conceptual job.
Key Takeaways
Authentication = "who" / Authorisation = "what" — never the same question
How identity is carried across requests
Where most auth bugs live: the authn/authz boundary
How to read any auth flow regardless of mechanism
Session Flow
0:00–0:12Authentication vs authorisation: the distinction that matters
0:12–0:30Live trace: an authenticated request through our codebase
0:30–0:48Common auth mistakes: real examples
0:48–0:58Discussion: where is the auth boundary unclear in your project?
0:58–1:00Wrap-up
Cross-layer
W5
Writing an API
An API is a contract you can't take back. Designing one is mostly about deciding what you're willing to promise forever.
Discussion + exercise
API design as contract design. Endpoint shape, naming, error responses, versioning. Why backwards compatibility is the constraint that shapes everything.
Key Takeaways
An API as a long-term contract
What promises to be careful about making
How to design boundaries that survive future change
Questions to ask before any new endpoint
Session Flow
0:00–0:12API as contract: what you're really committing to
0:12–0:28Three APIs reviewed — what they got right, what locked them in
0:28–0:45Paired exercise: design an endpoint for a given feature
0:45–0:55Discussion: critique each other's designs
0:55–1:00Wrap-up
W6
Reading a codebase
You'll spend more of your career reading code than writing it. The skill that scales is orientation in unfamiliar territory.
Demo + discussion
How to walk into any codebase and orient quickly. The heuristics: find the entry point, data store, auth, boundaries. Demonstrated live in an unfamiliar stack.
Key Takeaways
The five questions to ask any unfamiliar codebase
How to use AI to orient without being misled
How conventions reveal how the team thinks
The 60-minute orientation drill
Session Flow
0:00–0:10The orientation heuristic: five questions for any codebase
0:10–0:35Live demo: orient in an unfamiliar codebase, narrating thinking
0:35–0:50Discussion: what was confusing and why?
0:50–1:00Wrap-up
W7
Env config and secrets
Configuration is data your code depends on but doesn't own. Secrets are configuration that must never appear in code.
Discussion + demo
How config flows from dev to production, why secrets must be separate, how feature flags fit into safe shipping.
Key Takeaways
Configuration vs code: why the boundary matters
Why secrets in code is a permanent mistake
How feature flags change what "shipped" means
Questions before adding any new config value
Session Flow
0:00–0:12Config and secrets: the boundary and why it matters
0:12–0:28Live: how config flows through our environments
0:28–0:42Feature flags as a shipping safety net
0:42–0:55Real incidents from misconfiguration
0:55–1:00Wrap-up
W8
Debugging across layers
Debugging isn't about finding bugs. It's about disagreeing with the system — and being right about which layer is lying to you.
Hands-on workshop
How to debug systematically across layers. Tools (Apidog, devtools, logs) and the thinking that uses them. All domains attend — debugging is universal.
Key Takeaways
Debugging as systematic hypothesis-testing
How to localise a bug to a layer before going deep
The tools that matter and the thinking that uses them
The discipline of disagreeing with the system productively
Session Flow
0:00–0:12Debugging as hypothesis-testing — the mindset
0:30–0:48Hands-on: a real cross-layer bug to localise and trace
0:48–0:58Discussion: what tooling does your team underuse?
0:58–1:00Wrap-up
Judgment
W9
Code review
A good code review isn't a hunt for mistakes. It's a conversation about whether this change makes the system better, worse, or just different.
PR walkthrough
Code review as a craft — what to look for, how to give feedback that lands, how to spot AI-generated code that's confidently wrong.
Key Takeaways
Categories of issue that travel across any code review
How to spot AI-generated code that looks correct but isn't
Feedback styles that change behaviour vs create resentment
When to approve, when to ask, when to escalate
Session Flow
0:00–0:12What good code review catches
0:12–0:32PR walkthrough: real examples
0:32–0:48Reviewing AI-generated code
0:48–0:58Discussion: feedback that lands
0:58–1:00Wrap-up
W10
Deployment checklist
A deploy isn't finished when the pipeline goes green. It's finished when you've seen the system run and it told you it's healthy.
Workshop + artifact
What to think about before, during, and after shipping. Migrations, env vars, flags, rollback plans, monitoring signals. Produces a written checklist.
Key Takeaways
The pre-deploy checks that catch incidents
Why "merged" is not "deployed" is not "done"
What to watch in the first 30 minutes
A reusable team checklist as the artifact
Session Flow
0:00–0:10Why we need a checklist: incidents from missing steps
0:10–0:30Build the checklist together
0:30–0:45Walk through a recent deploy with the checklist
0:45–0:55Where it lives, who owns it
0:55–1:00Wrap-up: checklist published
W11
Tracing a production incident
When something is broken at 3am, you don't debug — you triage. The skill is reading signals fast enough to stop the bleeding.
Incident replay
How to read logs, traces, dashboards under pressure. Replay a real past incident together.
Key Takeaways
Triage vs debugging: different goals, different speed
What to look at first when something is on fire
How logs, traces, and dashboards work as a coordinated lens
When to escalate and when to keep digging
Session Flow
0:00–0:08Context: a real past incident
0:08–0:25Replay: open the logs, navigate together
0:25–0:42Find the cause: attendees navigate, guides help
0:42–0:52Debrief: what the fix was
0:52–1:00Wrap-up
W12
Infrastructure
Infrastructure isn't mystical — it's a set of decisions about where things run, how they reach each other, and what fails when.
Live walkthrough
A demystifying tour of how our infrastructure works. Engineers who can reason about what their code runs on.
Key Takeaways
A mental model of where your code actually runs
How environments connect to each other and the world
The infra concepts every engineer should discuss
How to ask infra questions without being an Ops engineer
Session Flow
0:00–0:15Our infrastructure at a glance
0:15–0:35Live walkthrough of how a deploy moves through real systems
0:35–0:50Discussion: what infra concept does your team misunderstand?
0:50–1:00Wrap-up
029 sessions
Frontend
How to think about software that humans look at, touch, and trust.
Foundations
W1
From Design to Screen — The FE Journey
Passant
A frontend task isn't "make the design pixel-perfect." It's a chain of decisions from design file → components → data → real pixels — and each link can break.
Walkthrough + discussion
The end-to-end journey every FE engineer walks. Design file → components → data → real pixels. What a typical FE workday looks like, what decisions get made, and what "done" means for a frontend task. This is the mental map the whole series hangs on — every session that follows zooms into one part of this journey.
Key Takeaways
The full FE journey: design file → component tree → data binding → rendered pixels
What decisions FE engineers make daily that other domains never see
What "done" means for a frontend task — and how it differs from backend "done"
The mental map that every following session will reference
Session Flow
0:00–0:10The journey overview: what happens between "here's the design" and "it's live"
0:10–0:25Walk through a real feature: from Figma to production, narrating every decision
0:25–0:40What a typical FE day looks like: the rhythm of design reviews, component work, API integration, QA
0:40–0:52Discussion: what part of this journey surprised you or was invisible to you before?
0:52–1:00Wrap-up: the map we'll zoom into across the remaining sessions
W2
The Handshake — FE meets BE
Sahar
The seam between frontend and backend isn't a clean boundary — it's a negotiation about who handles uncertainty, and most cross-team misunderstandings live exactly here.
Discussion + demo
Who owns what at the seam. Requests, responses, errors, loading states. Why most cross-team misunderstandings live exactly here. How the frontend and backend negotiate responsibility for failure, latency, and missing data — and what goes wrong when that negotiation is implicit rather than explicit.
Key Takeaways
The FE↔BE seam as a responsibility negotiation, not just an API call
Who handles loading states, errors, and partial data — and what breaks when it's unclear
Why most cross-team friction traces to implicit seam agreements
How to make the handshake explicit before building starts
Session Flow
0:00–0:10The handshake: what FE expects from BE and what BE expects from FE
0:10–0:25Live trace: an API call through success, error, timeout — who handles what?
0:25–0:40Three real cross-team misunderstandings and what they reveal about the seam
0:40–0:52Discussion: where in your project is the handshake unclear right now?
0:52–1:00Wrap-up: the questions to settle before any cross-layer feature begins
W3
Why UIs Behave Strangely — Rendering, State, and How They Connect
Abdelhameed
Why does the button flash? Why did that form reset? Why is the screen showing old data? The answer is almost always: rendering and state are out of sync — and you can't fix one without understanding the other.
Discussion + demo
Why does the button flash? Why did that form reset? Why is this screen showing old data? This session explains both the rendering model and state management together — how the UI decides what to draw, and how the data driving those decisions gets managed, shared, and sometimes goes wrong. The two concepts are inseparable in practice, and treating them separately is why most frontend mental models are broken.
Key Takeaways
How the rendering cycle works: what triggers a re-render and what it costs
The three kinds of state (local, shared, server) and why putting state in the wrong place causes cascading bugs
Why rendering and state are inseparable — you can't debug one without understanding the other
How to spot rendering/state bugs regardless of framework
Session Flow
0:00–0:12The render cycle: what triggers it, what it costs, why it sometimes runs too much
0:12–0:25State management: local, shared, server — when each is appropriate
0:25–0:40How they connect: walk through real bugs where state and rendering interacted badly
0:40–0:52Discussion: where in your project are state and rendering fighting each other?
0:52–1:00Wrap-up: the diagnostic questions for any "the UI is behaving strangely" report
W4
Reading a Frontend Codebase
Samah
A frontend codebase you've never seen is more readable than you think — if you read it as a tree of decisions, not a pile of files. Placed here intentionally: after understanding how frontends think and behave, reading one becomes significantly less intimidating.
Demo + discussion
How to walk into any frontend project and orient quickly. Find the entry point, routing, state, API layer, design system. Placed here intentionally — after understanding how frontends think and behave in sessions 1–3, reading an actual codebase becomes significantly less intimidating. Demonstrated live in a stack the attendees haven't used.
Key Takeaways
The five questions to orient any frontend codebase
How conventions and file structure reveal how the team thinks
How to use AI to orient without being misled
The 60-minute frontend orientation drill
Session Flow
0:00–0:10The orientation heuristic: five questions for any frontend
0:10–0:30Live demo: orient in an unfamiliar codebase, narrating the thinking
0:30–0:45Attendees try: given a repo, find the routing, state, and API layer in 10 minutes
0:45–0:55Discussion: what was confusing and what made it click?
0:55–1:00Wrap-up
Cross-layer
W5
Performance — Who's Responsible?
Alaa
When a user says "this is slow," the blame lands on the frontend — but the cause usually lives elsewhere. Performance is a cross-layer concern, and fixing it requires knowing which layer to look at first.
Demo + profiling
Why pages feel slow and who's actually responsible? What makes a UI feel fast or slow, where the blame really sits, and what tradeoffs FE engineers navigate constantly. Most "frontend performance problems" trace to backend payload decisions, network waterfalls, or rendering mistakes that aren't visible in a code review.
Key Takeaways
The four kinds of "slow" and what causes each (rendering, network, bundle, backend)
Why most performance problems trace to a layer the user doesn't see
How to profile any frontend regardless of framework
The questions to ask before optimising anything — and who to ask them to
Session Flow
0:00–0:12What makes a page slow: the rendering pipeline in plain terms
0:12–0:28Backend decisions that cause frontend performance problems: payload shape, missing caching
0:28–0:45Live profiling: open devtools on a real screen, find the actual bottleneck
0:45–0:55Discussion: where is performance debt hiding in your project — and whose responsibility is it?
0:55–1:00Wrap-up
W6
Accessibility — Building for Everyone
Mariam
Accessibility isn't a compliance checkbox. It's the recognition that the real range of users is wider than you think — and the decisions that include or exclude them happen at every layer, not just frontend.
Demo + audit
Who you're really building for — beyond compliance. The real range of users, what they experience, and why accessibility decisions happen at every layer, not just FE. Covers the big five failures that account for most accessibility issues, what AI-generated UI commonly gets wrong, and how to do a fast accessibility check on any screen.
Key Takeaways
Accessibility as inclusion, not compliance — the real user range
The big five failures: missing labels, no keyboard nav, poor contrast, missing alt text, ARIA misuse
Why accessibility decisions happen at every layer — API response structure, content strategy, not just CSS
How to do a fast accessibility audit on any screen you've built
Session Flow
0:00–0:12The real user range: who you're actually building for and what they experience
0:12–0:28The big five: the failures that account for most accessibility issues
0:28–0:42Live audit: run an accessibility check on a real screen together
0:42–0:52AI and accessibility: what generated UI commonly misses and how to catch it
0:52–1:00Wrap-up: what accessibility looks like as a habit, not a task
W7
Error Handling — When Things Break
Magdy
The backend is down, the network drops, data comes back wrong. What does the frontend do? Graceful failure is harder than it sounds — because most UIs are designed for the happy path and break silently on everything else.
Workshop
What FE engineers do when the backend is down, the network drops, or data comes back wrong. Why graceful failure is harder than it sounds. Covers error boundaries, fallback states, retry logic, and the four states most UIs forget to design for: loading, error, empty, and partial data.
Key Takeaways
Failure as a first-class state, not an exception to handle later
The four forgotten states: loading, error, empty, partial — and why most UIs only design for "success"
Error boundaries and graceful degradation: how to protect users when things break
How to handle uncertainty without overwhelming the user or hiding real problems
0:12–0:28Error boundaries and graceful degradation: the principles
0:28–0:42Hands-on: add an error boundary and fallback to a feature that's missing one
0:42–0:52Discussion: what failure mode is your project worst at handling right now?
0:52–1:00Wrap-up: the failure-handling checklist for any cross-layer feature
Judgment
W8
Frontend Code Review
Mo2men
You can review frontend code meaningfully without being a framework specialist — by knowing what categories of wrong are common. Placed late deliberately: by this point the audience has enough context to actually understand what they're looking for.
PR walkthrough
How non-frontend engineers can do a useful first-pass review. State location, error handling, accessibility, performance smells, design system consistency. Placed late deliberately — by this point the audience has enough context from sessions 1–7 to actually understand what they're looking for in a frontend PR.
Key Takeaways
The six review categories that travel across frontend stacks
What kinds of frontend bugs are usually invisible in a PR
What AI-generated frontend code commonly misses
When to approve, when to question, when to escalate
Session Flow
0:00–0:12The six review categories: state, errors, a11y, perf, design system, AI smells
0:12–0:30PR #1: walk through together, find issues using the categories
0:42–0:52Discussion: which category does your team most often miss in review?
0:52–1:00Wrap-up: when to approve, when to ask, when to escalate
W9
The Modern Frontend Landscape
Heba
React, Vue, Next, TypeScript, Tailwind — there are so many tools because no single one solves the whole problem. Understanding why the ecosystem moves fast helps you stop chasing trends and start evaluating tradeoffs.
Talk + discussion
React, Vue, Next, TypeScript, Tailwind — why there are so many tools, why the ecosystem moves fast, and how FE engineers navigate it. A closing session that makes the outside world make sense. Why frameworks exist, what problems they solve, what tradeoffs they make, and how to evaluate new tools without being swept up in hype.
Key Takeaways
Why the frontend ecosystem has so many tools — what problem each layer solves
How to evaluate a new framework or library: the questions that matter
Why the ecosystem moves fast and what that means for long-term decisions
How FE engineers stay current without chasing every trend
Session Flow
0:00–0:15The landscape: what each tool category solves — frameworks, meta-frameworks, type systems, styling
0:15–0:30Why so many: the history of frontend complexity in 15 minutes
0:30–0:45How to evaluate: the five questions to ask about any new tool
0:45–0:55Discussion: what tool in your stack do you use but don't understand why it was chosen?
0:55–1:00Wrap-up: how to stay current without drowning
0313 sessions
Mobile
How to think about software that lives in pockets and survives the real world.
Foundations
W1
How our mobile apps actually work
Mobile apps look like web frontends but follow different physics. The structure tells you what the platform is forcing you to handle.
Live walkthrough
Tour of our iOS and Android apps — structure, features, data layer, navigation, platform-specific code. Demystifying the structure, not teaching native development.
Key Takeaways
How a mobile codebase is organised
Where platform-specific code lives vs shared logic
Differences between iOS and Android architecture
How to find feature code in any mobile codebase
Session Flow
0:00–0:12iOS and Android structure: shared vs different
0:30–0:45Attendees navigate: find a known feature on both platforms
0:45–0:55Discussion: what still feels like a black box?
0:55–1:00Wrap-up
W2
Mobile physics
Web engineers assume connectivity, power, screen size, and recency. Mobile engineers assume none. The mindset gap is bigger than the framework gap.
Discussion + examples
Why mobile is a different discipline. The five physics: unreliable network, finite battery, finite memory, version fragmentation, lifecycle complexity.
Key Takeaways
The five mobile physics that change every assumption
Why backend and FE decisions silently hurt mobile
How to think about a feature's mobile cost during design
Questions before any mobile-affecting change
Session Flow
0:00–0:15The five physics: network, battery, memory, versioning, lifecycle
0:15–0:35Three failures from ignoring mobile physics
0:35–0:50Discussion: which physics is your project most exposed to?
0:50–1:00Wrap-up
W3
State management on mobile
Mobile state is web state with a survival problem. The OS can kill your process at any time — your state management must account for death and resurrection.
Discussion + walkthrough
How state management works on mobile — view state, app state, persistence boundaries. Why it's fundamentally more complex than web: the lifecycle means state can be lost at any moment. State restoration, what should survive backgrounding, and the worst class of mobile bugs this creates.
Key Takeaways
Why mobile state management is harder than web: lifecycle interruption
The distinction between ephemeral state and state that must survive process death
How to decide what to restore after backgrounding vs re-fetch
Why this matters equally in native, React Native, and Flutter
Session Flow
0:00–0:15Mobile state vs web state: what the lifecycle changes
0:15–0:30What happens when the OS kills your app — what survives, what doesn't
0:30–0:45Discussion: walk through state in a real feature — what should survive?
0:45–0:55Common mistakes: state lost that shouldn't be, state saved that shouldn't be
0:55–1:00Wrap-up
W4
Asynchronous programming and concurrency
On mobile, nothing is fast and everything is interruptible. If you don't think in async, the user experiences freezes, races, and lost data.
Discussion + examples
Why async thinking is non-optional on mobile. The main thread constraint — blocking work freezes the UI. How concurrency works conceptually across platforms: threads, queues, coroutines, async/await. Common pitfalls: races, main-thread violations, callback hell, cancellation.
Key Takeaways
Why the main thread is sacred on mobile
How to think about async operations: what runs where and what waits
Common concurrency bugs: races, stale callbacks, uncancelled work
Why this applies equally to Kotlin coroutines, Swift async/await, and JS promises
Session Flow
0:00–0:12The main thread constraint: why it matters on mobile
0:12–0:28Async concepts: threads, queues, structured concurrency — the universal shape
0:28–0:42Three real bugs caused by wrong async patterns
0:42–0:55Discussion: where is async handling fragile in your project?
0:55–1:00Wrap-up
W5
Persistence and local storage
Mobile storage isn't "saving data." It's making promises about what the user will still have when they open the app on a plane.
Discussion + walkthrough
How local storage works on mobile — the options (key-value, SQLite, file system, secure storage), when to use each, and the contract between app and user about what persists. Why offline-first is a persistence strategy. How secure storage differs from regular storage.
How to decide what deserves persistence vs re-fetching
Why offline-first is a data strategy, not just a UX trick
What goes in secure storage and why the distinction matters
Session Flow
0:00–0:12The persistence spectrum: from volatile to durable
0:12–0:28Each option walked through: when to use, what it costs
0:28–0:42Offline-first as a persistence decision
0:42–0:55Discussion: what should survive a cold start and doesn't?
0:55–1:00Wrap-up
W6
Dependency injection
DI isn't a framework feature. It's the discipline of building software where the parts can be replaced without rewriting the whole.
Discussion
A surface-level but practical introduction to DI — what problem it solves, why mobile teams care, how it makes testing and modularity possible. Not a deep dive into any DI framework but the concept itself: constructing objects with dependencies provided from outside.
Key Takeaways
What problem DI solves: decoupling creation from use
Why mobile codebases need DI more than web: lifecycle, testing, modularisation
The basic pattern: pass dependencies in rather than creating them inside
How DI enables testability and why that matters for cross-layer work
Session Flow
0:00–0:12What DI is and what problem it solves — without framework jargon
0:12–0:28Two versions of the same code: tightly coupled vs injected
0:28–0:42Why mobile needs DI: lifecycle, testing, modularisation
0:42–0:55Discussion: where are dependencies hard-wired that shouldn't be?
0:55–1:00Wrap-up
Cross-layer
W7
Versioning lag
Web changes when you deploy. Mobile changes when users update — and they don't. Every API must coexist with versions shipped a year ago.
Discussion
Why versioning is the most underrated cross-layer concept. Every backend change must consider old clients. Most mobile production incidents come from forgetting this.
Key Takeaways
Why mobile versioning is fundamentally different from web
The lifetime of an old app version in production
How to make API changes without breaking old clients
Questions before any API change mobile uses
Session Flow
0:00–0:12Why mobile versioning is different
0:12–0:32Three real incidents from version lag
0:32–0:50Discussion: what version assumptions exist in your project?
0:50–1:00Wrap-up
W8
App store releases
Web deploys revert in minutes. Mobile releases live in binaries for months. The reversibility gap shapes everything.
Discussion
How mobile release reality changes feature design. Feature flags, staged rollouts, why "fix it next sprint" doesn't work when that means "next App Store review."
Key Takeaways
The release reversibility gap
Why feature flags are non-optional on mobile
How staged rollouts change risk
What "MVP" means differently on mobile
Session Flow
0:00–0:15The release reversibility gap
0:15–0:35Three patterns that absorb release risk
0:35–0:50Discussion: what should have shipped behind a flag?
0:50–1:00Wrap-up
W9
Push notifications and deep links
Push and deep links are bridges between your app and the outside world. They look simple and fail in interesting ways.
Demo + walkthrough
How push and deep links work end to end. Failure modes. What the backend must handle correctly.
Key Takeaways
The push delivery stack from server to device
Failure modes that hide in production
How deep linking works across platforms
What the backend must do for reliability
Session Flow
0:00–0:15Push: APNs, FCM, notification service
0:15–0:30Deep links: how they work, where they break
0:30–0:45Live demo: trigger both, trace what happens
0:45–0:55Discussion: what are you treating as mobile-only that isn't?
0:55–1:00Wrap-up
W10
APIs designed for mobile
A good mobile API isn't a smaller web API. It respects bandwidth, battery, latency, and the fact the next request might never happen.
Discussion
How API design changes for mobile. Pagination for flaky networks, payload size, sync patterns for offline. Why "same API as web" is the most common mistake.
Mobile codebases look intimidating because of the platform. The mindset travels: find the navigation, data layer, lifecycle.
Demo + discussion
How to orient in any unfamiliar mobile codebase — native, RN, Flutter. Navigation graph, screen registry, data layer, lifecycle hooks.
Key Takeaways
Five questions to orient any mobile codebase
Where platform-specific code lives vs shared
How to trace a feature across iOS and Android
The 60-minute mobile orientation drill
Session Flow
0:00–0:10The orientation heuristic
0:10–0:35Live demo: orient in unfamiliar mobile codebase
0:35–0:50Discussion: what was confusing?
0:50–1:00Wrap-up
W12
Crash reporting and mobile error handling
A mobile crash isn't a bug — it's a signal. The skill is reading what the device is telling you.
Demo
Reading crash reports, Sentry/Crashlytics, crashes vs handled errors, mobile error boundaries. How to tell if the root cause is mobile, API, or network.
Key Takeaways
How to read any crash report
Crashes vs handled errors
How to locate the root cause layer
What good mobile error handling looks like
Session Flow
0:00–0:12Anatomy of a crash report
0:12–0:28Live demo: open a real crash, trace it
0:28–0:42Crashes vs handled errors
0:42–0:55Cross-layer crashes: where does the cause live?
0:55–1:00Wrap-up
W13
Mobile code review
You can review mobile PRs without being a mobile engineer — by knowing what categories of wrong show up only on real devices.
PR walkthrough
How non-mobile engineers can review mobile changes usefully. Lifecycle correctness, permission handling, deep link safety, version compatibility, battery patterns.
Key Takeaways
Mobile-specific review categories that travel
What lifecycle and permission issues look like in code
How to review across iOS and Android
When to approve, ask, escalate
Session Flow
0:00–0:12Mobile review categories
0:12–0:35Live PR walkthrough across stacks
0:35–0:50Discussion: which categories does your team miss?