Week 01 — Principles & Practices / Project Management¶
Overview¶
Week 01 was about setting the foundation for how I will work throughout Fab Academy. Beyond tools and setup, the focus was on understanding how to manage time, complexity, documentation, and decisions over the program. This week combined conceptual framing from the global lectures with very hands-on local work around Git, MkDocs, and website development.
Global Class — Principles & Practices¶
The global lecture framed project management as a practice of working within constraints rather than chasing ideal outcomes. A key idea was to work based on the time available each week, not on the perceived size or perfection of the task. This requires continuous triage: deciding what to prioritize, what to postpone, and what to deliberately leave out.
Key ideas that shaped my approach:
- Work based on time available, not on the perceived size of the task
- Perform weekly triage: decide what to prioritize, postpone, or discard
- Accept opportunity cost and set boundaries to protect focus
- Organize tasks so they can run in parallel and do not block each other
- Use spiral development instead of linear development
- Break systems into modules that can be tested independently
- Document as you work — documentation is part of the work, not a final step
Documentation was emphasized as part of the work itself, not as a final reporting task. Cleaning, organizing, and writing are not separate from making—they are integral to it. We were also encouraged to be transparent about the use of AI tools, documenting when and how they are used, including prompts, as part of an honest workflow.
Git was introduced not just as a technical requirement, but as a way to maintain history, manage change, and support decision-making over time through commits, branching, pulling, pushing, and conflict resolution.
Local Class & Recitation¶
The local classes were essential in translating concepts into practice. Hands-on work with Git, GitLab, the terminal, and MkDocs made the abstract ideas concrete very quickly. Being able to try, fail, and correct things live—especially around repository setup and file structure—was extremely valuable.
Topics covered included:
- Command-line navigation
- Git structure and workflow
- Repositories, commits, pushing and pulling
- How Markdown files are rendered into a live website
The hands-on nature of this session made a significant difference. Without it, setting up the workflow would have taken considerably longer.
During a recitation session, we also discussed file size management and image compression. Several tools were mentioned, and after testing different options, I chose Squoosh from a recommendation on the chat as it dramatically reduces file sizes while preserving enough quality for documentation purposes.
This has to become an automatated part of my documentation workflow and flow naturally.
Assignments¶
Final Project — Initial Concept¶
This week I defined and documented the initial concept for my final project, ASFALT, a hardware system focused on improving cooking performance for mobile foodservice operators through a retrofit top-heat approach. The concept, research summary, and initial sketches are documented in the Final Project section and will remain stable as a reference point throughout the program.
Student Agreement¶
I read, signed, and committed the Fab Academy Student Agreement. The process involved copying the agreement into a Markdown file, adding my name, and committing it to my repository using Git. While simple, this step reinforced the importance of treating documentation and version control as part of the formal learning process.
Git & Version Control¶
Git was introduced as the backbone of the documentation workflow.
Key concepts:
- Git maintains a history of changes through commits
- Each commit represents a meaningful change
- Branches allow parallel exploration and merging
- Pulling and pushing synchronize local and remote versions
- Conflicts surface mismatches that must be resolved deliberately
Git Configuration¶
To ensure commits were correctly attributed, I configured Git with my name and email:
Beyond the commands themselves, an important lesson came from a mistake: I initially edited files in one local copy of the repository (opened in Zed) while committing from a different clone in the terminal. This resulted in changes appearing locally but never being detected by Git.
Resolving this required identifying the correct repository, synchronizing files, and committing from a single source of truth. This was a valuable lesson in how easily version control can break down when working across multiple environments—and why clarity and consistency matter.
Personal Website Development¶
I built my personal Fab Academy website using MkDocs and Markdown. This setup allows me to focus on content and structure rather than low-level HTML, while still keeping full control of the site through Git.
I configured a local development server to preview changes before publishing them online. This made it possible to iterate quickly without pushing unfinished work.
As part of personalizing the site, I followed ASFALT brand guidelines by introducing a custom stylesheet. Brand colors and header styling were applied through an additional CSS file, keeping branding decisions explicit, contained, and easy to evolve later.
Documentation Workflow¶
My documentation workflow now follows a clear sequence:
- Edit Markdown files locally in Zed
- Preview changes using MkDocs
- Compress images before adding them to the repository
- Commit changes with meaningful messages
- Push updates to GitLab
This structure creates a reliable feedback loop between thinking, making, documenting, and publishing.
Learnings & Reflections¶
This week fundamentally changed how I think about documentation and time management. Working week by week, with a clear timeline, forces decisions about depth and scope. Any single topic—website design, typography, layout—could easily consume the entire program if left unchecked.
From the start, it becomes necessary to define a level of depth that is “good enough,” conclude it, and move forward. The work is never perfect, and it cannot be. Trimming, prioritizing, and letting go of unnecessary refinements are essential to protect bandwidth and maintain momentum.
I also learned that it is very difficult to go back later in the program to revisit foundational decisions like font sizes or personal bio text. Once decisions are made, it is often better to accept them and continue, rather than reopening early chapters endlessly.
Overall, Week 01 set the tone for a systematic, intentional way of working—one where decisions, constraints, and documentation are treated as first-class elements of the process, not overhead.
References¶
- Fab Academy 2026 Documentation
- Git & GitLab Documentation
- MkDocs Documentation
- Squoosh Image Compression Tool
Use of AI Tools¶
Throughout Week 01, I used ChatGPT as a support for writing, structuring, and refining my documentation, as well as for clarifying technical workflows related to Git, MkDocs, and site configuration. AI was used as a drafting and reflection aid, not as a replacement for hands-on work, decision-making, or implementation.
The role of AI was mainly to:
- Help structure long-form documentation in a clear and readable way
- Polish language and tone to better reflect my intent and personal voice
- Clarify command-line workflows and configuration steps when debugging
- Assist in summarizing lectures, notes, and personal learnings into coherent sections
All technical steps (repository setup, commits, MkDocs configuration, styling, image handling) were executed manually by me.
Example Prompt Used¶
The following is representative of the type of prompts used during this week:
“Help me write the Week 01 documentation for Fab Academy (Project Management, Principles & Practices).
Use a reflective, personal tone rather than a purely technical log.
Include Git setup, MkDocs workflow, local development, branding via custom CSS, image compression, and lessons learned.
Keep it concise, structured, and aligned with Fab Academy documentation standards.”“Let’s move to personalize the site. I want to follow the branding guidelines for Asfalt in file attached and personalize mkdocs. Let me know the changes I need to make in order to align with brand, like font, color palette, style, messaging, tone of voice, etc. Stick to documentation style webpage and keep structure”
Let’s write the whole documentation section together. Add this notes, consider this screeshot to show compressed file, add to website development that brand guidelines were followed with use addition of style sheets, mention solving repo issue as working on different versions on git and zed (lesson leaned), explain that during local classes hands-on work was very useful or super important.
Take style, vocabulary from reports, guidelines, bio and other text I’ve written so far to create my own personal writing and communicating style. It is a personal journey, not just an enginering log.
Learnings, insights, debriefing, reflections are the most important issues I want to communicate and document.
For example, this week take this notes and write summary: Systematic way to document. Notion of working by weeks and with timeline. Webpage editing could take up entire 6 month program if desired. From the start or during the process choose or decide on the depth of each task or topic and adjust time so conclude it. That becomes your bandwidth to work with, Never perfect, there has to be trimming and decision making is important to keep the good and toss the unnecessary. Difficult to come back later on the program to fix font size or about me section. So stick to decision and move forward.
AI-generated text was always reviewed, edited, and adapted to ensure accuracy, consistency with my project narrative, and alignment with Fab Academy requirements.