Skip to main content
​
Day 1
  • Installed Expo locally and created a first test project to explore the tooling.
  • Read the official Expo Router “Core concepts” documentation to understand file-based routing.
  • Created a small local playground app to experiment with basic navigation behavior.
  • Core problem: Understanding Expos file-based routing style without prior Next.js experience to compare it to.
  • It occurred because routes are derived directly from the folder and file structure, which felt very different from traditional route configuration.
  • I identified the issue when I was unsure how screens were picked up from the app/ tree and clarified it by reading the docs and discussing questions with a colleague.
  • Carefully walking through the Expo Router core-concepts documentation and examples.
  • Recreating a minimal route setup in a local test project to see how file names map to screens.
  • Asking a colleague targeted questions to validate my oberservation of how routing and layouts work.
  • Expo Router heavily relies on a clear app/ folder structure, since files and folders define the navigation tree.
  • I understand routing concepts faster when I combine documentation with hands-on experimentation instead of only reading.
  • Early questions to a teammate help avoid building on wrong assumptions.
  • I will always create a small playground project immediately when learning a new routing system.
  • Read official docs, reproduce a minimal example, then validate understanding with a colleague.
  • Expo Router basics - app/ folder represents the route tree, each file is a screen and _layout.tsx files wrap related screens instead of a single central App.tsx.
  • No unresolved technical issues remain the basic routing concepts are clear enough to continue experimenting.
  • Attempt 1: Trying to understand routing purely by reading without touching code the concepts stayed too abstract.
  • Attempt 2: Mapping Expo Router mentally to a classic “manual route config” approach instead of accepting file-based routing as the core concept this caused extra confusion.
  • Deepen understanding of dynamic routes, route groups and nested layouts in Expo Router.
  • Watch or read material specifically focused on _layout.tsx and advanced navigation patterns.
  • Key challenge: Getting used to Expos file-based routing and layout concept without prior Next.js experience.
  • Attempted solutions: Read core documentation, built a small local test project and clarified open questions with a colleague.
  • Open questions: Details of dynamic routes, nested layouts and best practices for structuring larger apps.
​
Day 2
  • Continued studying Expo Router, focusing on _layout files and router notations.
  • Tested different route patterns and layouts in the local project to see how the router behaves in practice.
  • Integrated the existing Spring Boot backend from the “OrariAperti” project and added Docker configuration for it.
  • Core problem: Understanding how _layout files define navigation structure and how route notations map to screens.
  • It occurred because Expo Router uses conventions like _layout.tsx, grouping folders and dynamic segments that are not obvious from filenames alone.
  • I overcame this by translating the documentation examples into concrete experiments inside the local project and observing the results.
  • Re-reading the layout documentation with a focus on how _layout.tsx wraps child routes.
  • Building a small route tree with a root layout and nested screens to see which layout wraps which screen.
  • Setting up Docker for the Spring Boot backend so it can be started consistently for future integration with the app.
  • Each directory in app/ can own its own _layout.tsx and that layout becomes the wrapper for all sibling routes in that directory.
  • Trying router notation in a small sandbox app is much more effective than trying to memorize routing rules.
  • Having a Dockerized backend prepared early simplifies local development and onboarding for others, I myself didn’t need it.
  • For future projects, define the root _layout.tsx early and plan how route groups map to main UX flows.
  • Standard approach for router notation issues: create a minimal directory structure and run the app to see how Expo Router resolves it.
  • No major unresolved problems I still need more experience with complex router notations, but basic layouts and routes work.
  • Attempt 1: Re-reading docs repeatedly without implementing examples, which did not help internalize router notation.
  • Attempt 2: Trying to reason about layouts only in theory without checking which screens they actually wrap in a running app.
  • Investigate advanced routing features: dynamic segments, modals and route groups.
  • Draft an internal guide defining recommended folder patterns for this project, so all team members use the same conventions.
  • Key challenge: Understanding _layout files and router notations in Expo Router.
  • Attempted solutions: In-depth reading of layout docs, hands-on experiments and structuring a test app to observe layout behavior.
  • Open questions: How to structure the final app/ tree for scalability and clarity.
​
Day 3
  • Implemented and tested navigation between screens using buttons wired to Expo Router.
  • Read up on React Native core and reusable components to better understand the building blocks for our UI.
  • Added the logo from the previous project for future use in the current apps design.
  • Core problem: Connecting reusable UI components (like buttons) correctly with navigation so that route changes trigger as expected.
  • It occurred because reusable components add an abstraction layer and navigation logic must be passed down or handled via hooks in a clean way.
  • I solved it by first testing simple navigation with basic buttons, then refactoring the working pattern into more reusable components.
  • Reviewing React Natives core components documentation to understand the standard primitives like Card, Alert and Button.
  • Creating placeholder routing buttons that navigate to different routes and verifying their behavior.
  • Gradually wrapping navigation logic in reusable components instead of abstracting everything from the start.
  • Implementing navigation with very simple placeholder buttons first makes debugging easier before adding styling and logics.
  • Reusing existing assets such as logos early encourages consistent visual identity.
  • Start with basic, direct navigation calls in simple components, then extract reusable variants once the behavior is stable.
  • Store reusable components in a dedicated folder and clearly document their props, including any navigation-related props.
  • Base UI on core React Native components, then wrap them into custom components that share styles and behavior.
  • No major unresolved problems navigation via placeholder buttons is working and can be extended.
  • Attempt: Mixing navigation and presentation logic too tightly, which reduced component reusability.
  • Improve reusable component APIs (props, variants, theming) and documentation.
  • Add more complex navigation flows such as stacks and tabs controlled via _layout.tsx.
  • Key challenge: Connecting reusable components cleanly with Expo Router navigation.
  • Attempted solutions: Built placeholder routing buttons, consulted React Native core component docs and then refactored into reusable components.
​
Day 3
  • Implemented and tested navigation between screens using buttons wired to Expo Router.
  • Read up on React Native core and reusable components to better understand the building blocks for our UI.
  • Added the logo from the previous project for future use in the current apps design.
  • Core problem: Connecting reusable UI components (like buttons) correctly with navigation so that route changes trigger as expected.
  • It occurred because reusable components add an abstraction layer and navigation logic must be passed down or handled via hooks in a clean way.
  • I solved it by first testing simple navigation with basic buttons, then refactoring the working pattern into more reusable components.
  • Reviewing React Natives core components documentation to understand the standard primitives like Card, Alert and Button.
  • Creating placeholder routing buttons that navigate to different routes and verifying their behavior.
  • Gradually wrapping navigation logic in reusable components instead of abstracting everything from the start.
  • Implementing navigation with very simple placeholder buttons first makes debugging easier before adding styling and logics.
  • Reusing existing assets such as logos early encourages consistent visual identity.
  • Start with basic, direct navigation calls in simple components, then extract reusable variants once the behavior is stable.
  • Store reusable components in a dedicated folder and clearly document their props, including any navigation-related props.
  • Base UI on core React Native components, then wrap them into custom components that share styles and behavior.
  • No major unresolved problems navigation via placeholder buttons is working and can be extended.
  • Attempt: Mixing navigation and presentation logic too tightly, which reduced component reusability.
  • Improve reusable component APIs (props, variants, theming) and documentation.
  • Add more complex navigation flows such as stacks and tabs controlled via _layout.tsx.
  • Key challenge: Connecting reusable components cleanly with Expo Router navigation.
  • Attempted solutions: Built placeholder routing buttons, consulted React Native core component docs and then refactored into reusable components.
​
Day 4
  • Started writing the detailed documentation for the upcoming lesson and completed steps 1-8 of the 16-step lesson preparation.
  • Read through the lesson preparation guidelines to ensure alignment with expectations.
  • Clarified several question marks directly with the teacher to make sure the content matches the required structure.
  • Core problem: Interpreting some questions in the lesson preparation template and understanding the expected level of detail.
  • It occurred because certain instructions were open-ended, leaving room for different interpretations.
  • I overcame this by asking the teacher for concrete examples and confirmation before finalizing my answers.
  • Reading the full lesson preparation document once from start to finish before filling it out.
  • Drafting answers for steps 1-8 and then validating unclear parts with the teacher.
  • Refining the wording based on feedback so that the document reflects the actual teaching goals.
  • Clarifying expectations early with the teacher saves time and reduces the risk of rewriting sections later.
  • Using the lesson document as a shared artifact helps communicate goals within the team.
  • I work more effectively on documentation when I can ask questions instead of guessing the intended meaning.
  • Best practice: For lesson plans, skim the whole template first, then fill it in sequentially and clarify ambiguous parts right away.
  • Standard approach: Use consistent terminology between the lesson plan and the example code to avoid confusion.
  • Documentation note: Keep lesson steps numbered and concise so they can later be reused as student-facing instructions.
  • No unresolved issues steps 1-8 are completed and aligned with the teachers expectations.
  • Attempt: Trying to guess certain answers without asking the teacher, which led to uncertainty and possible misalignment.
  • Continue with steps 9-16 while maintaining a feedback loop with the teacher.
  • Start drafting example code or visual material that will be used during the lesson.
  • Key challenge: Understanding and correctly filling in lesson preparation steps 1-8.
  • Attempted solutions: Thoroughly read the template for lesson preparation, drafted answers and clarified uncertainties with the teacher.
  • Open questions: How detailed the practical React Native examples in the later lesson steps should be.
​
Day 5
  • Completed steps 9-16 of the lesson preparation, finalizing the planned documentation.
  • Refined ideas for the React Native tutorial that will be the core of the upcoming lesson.
  • Learned how to create a reasonably structured markdown table and used this in the documentation.
  • Core problem: Staying focused and consistent while finishing the remaining lesson preparation steps.
  • It occurred because the documentation workload was high and required careful wording.
  • I managed it by asking the teacher whenever something was unclear and by breaking the work into smaller, manageable chunks.
  • Working through each remaining step one by one instead of multitasking across the document.
  • Clarifying remaining questions with the teacher to avoid misinterpretations.
  • Experimenting with markdown table syntax until the table looked clean and readable.
  • Breaking down a long documentation task into smaller steps made it easier to maintain quality and focus.
  • Practical experimentation is the fastest way to learn markdown features like tables.
  • Thinking about the React Native tutorial early helps ensure that code examples align with the written lesson goals.
  • For future lesson documents, define the main example or topic (e.g, a React Native feature) early and align all steps with that example.
  • Use markdown tables for structuring recurring information such as topic, goal, activity and duration.
  • Keep markdown tables simple, with a small number of columns and consistent formatting, so they stay readable in different tools.
  • No unresolved problems, all 16 lesson preparation steps are completed and clarified where needed.
  • Attempt: Writing markdown tables from memory without checking syntax, which led to formatting errors.
  • Flesh out the concrete React Native tutorial steps, including the sequence of code examples and potential live-coding.
  • Prepare slides or handouts that reuse the markdown tables and core points from the lesson documentation.
  • Key challenge: Finishing the remaining lesson preparation steps and shaping the React Native tutorial concept.
  • Attempted solutions: Worked sequentially through steps 9-16, asked the teacher for clarification when needed and experimented with markdown tables.
  • Open questions: Final decision on how advanced the React Native example should be for the target audience.
​
Day 6
  • Reworked and refined my existing journal entries (Days 1-3).
  • Transferred and published these journal entries to Mintlify.
  • Improved formatting and consistency to match documentation standards.
  • Core problem: Ensuring that previously written journal entries were properly structured and formatted for Mintlify.
  • It occurred because the original notes were not fully aligned with the documentation format and required adjustments.
  • I resolved it by systematically reviewing each entry and adapting it to the expected structure.
  • Reviewing earlier journal entries for clarity and completeness.
  • Aligning formatting (headings, spacing, structure) with Mintlify requirements.
  • Iteratively updating entries and previewing them to ensure correct rendering.
  • Retrospectively refining documentation improves both clarity and consistency.
  • Writing with the final documentation platform in mind (Mintlify) saves time later.
  • Small formatting differences can significantly affect readability in documentation tools.
  • Always align documentation early with the target platform (e.g, Mintlify).
  • Periodically revisit and refine earlier entries instead of treating them as final.
  • Maintain consistent formatting conventions across all journal entries.
  • No unresolved issues the migration of Days 1-3 to Mintlify was completed successfully.
  • Attempt: Copying entries directly without adjusting formatting, which resulted in inconsistent presentation.
  • Continue refining later journal entries for consistency before publishing.
  • Explore reusable templates for future journal entries to standardize structure.
  • Key challenge: Adapting earlier journal entries to Mintlify formatting standards.
  • Attempted solutions: Reviewed, restructured and incrementally refined entries before publishing.
  • Open questions: None at this stage.
​
Day 7
  • Published the remaining journal entries to Mintlify.
  • Finalized the documentation so all work logs are now centrally available.
  • Clarified the structure of the AVIVA table for the lesson documentation with the teacher.
  • Core problem: Understanding how to correctly structure the AVIVA table for the lesson.
  • It occurred because the required structure needed to reflect the chronological flow of the lesson.
  • I solved it by discussing it with the teacher, which led to adapting the structure into an “AVIVVIVVIVA” format.
  • Asking the teacher directly how the AVIVA table should be structured.
  • Reviewing the lesson flow and aligning it with the adapted AVIVVIVVIVA structure.
  • Updating the table to ensure it reflects the chronological teaching process.
  • Clarifying structural questions early avoids incorrect documentation work.
  • Standard frameworks like AVIVA may need adaptation depending on the lesson flow.
  • Direct communication is often the fastest way to resolve conceptual uncertainties.
  • When working with teaching frameworks, adapt them to fit the actual lesson flow instead of forcing strict structure.
  • Always validate unclear documentation requirements with stakeholders (e.g, teacher).
  • Keep documentation aligned with real chronological processes for better usability.
  • No unresolved problems all journal entries are now published and the AVIVA structure is clarified.
  • Attempt: Trying to structure the AVIVA table independently without clarification, which led to uncertainty.
  • Refine the AVIVVIVVIVA table further based on feedback after first use in the lesson.
  • Create a reusable template for future lesson documentation.
  • Key challenge: Structuring the AVIVA table correctly for the lesson.
  • Attempted solutions: Asked the teacher for clarification and adapted the structure accordingly.
  • Open questions: Whether the adapted AVIVVIVVIVA format will need further refinement after practical use.