Computer Science & Software Engineering

Course Progress 0/0
Week 4 Onboarding Challenge - Ground 0

Onboarding Challenge - Ground 0

18 min read • Assignment

Task-Centered Introduction

Welcome to the Open Coding Society — where you’ll develop professional software engineering skills while building real projects with your classmates.

The Challenge

Starting a new development environment can be overwhelming. You will encounter unfamiliar tools, new workflows, new teammates, and problems that do not always have obvious answers.

This is your first challenge: learn to work in an unfamiliar development environment.

Instead of simply following a set of instructions, you will document your setup process, troubleshoot problems, make decisions, and create solutions that help both you and your teammates succeed.

You are beginning to work as a student developer. Your work will include:

  • Mastering professional development tools

    • VS Code
    • GitHub
    • Git
    • Development and testing workflows

  • Building web-based projects

    • Individual GitHub Pages portfolio
    • Team project sites
    • Project documentatio

  • Developing collaboration practices

    • Issues
    • Kanban boards
    • GitHub workflows
    • Team communication

  • Beginning your course-specific development

    • CSSE: Begin ideation and development of a new game while learning the OCS game engine.
    • CSP: Begin ideation and development of an OCS project or contribute to and extend a nonprofit project.
    • CSA: Begin ideation, design, development, maintenance, and testing of an existing OCS system.
    • CSH: Begin research and development focused on extending OCS intelligence.

  • Documenting your learning journey

    • Setup instructions
    • Troubleshooting notes
    • Decisions and solutions
    • Learning reflections

This class mirrors the experience of professional software engineering onboarding. You are not expected to know everything when you begin. You are expected to learn how to find your way through unfamiliar problems.

The Problem

New developers often feel overwhelmed by unfamiliar tools, workflows, technologies, and expectations. A problem that seems simple can become difficult when you do not yet understand the environment in which you are working.

Your job is not simply to get everything working and perfect it.

Your job is to learn how to get things working and keep improving.

That means learning how to investigate a problem, ask useful questions, find information, test possible solutions, document what you discover, and help the next person who encounters the same problem.

The Goal

By the end of the first onboarding sprint, you will:

  • Build Your Personal Portfolio: Have your individual GitHub Pages site online and validate that your required code runners and development tools are working.
  • Build Working Proficiency: Become comfortable using the essential tools and workflows required for your course.
  • Establish Your Development Workflow: Understand how you will create, test, document, and submit your work.
  • Document Your Progress: Create useful issues, Kanban boards, plans, and technical notes that guide your development.
  • Begin Your Project: Move from onboarding into meaningful development work appropriate to your course.
  • Reflect on Your Learning: Begin identifying what you know, what you do not yet know, how you respond to problems, and how your approach changes as you gain experience.
mindmap
  root((Student Developer))
    🛠️ Develop Skills
      VS Code
      GitHub
      Git
      Development Workflow
    🏗️ Build Projects
      Team Collaboration
      Individual Portfolio
      GitHub Pages
      Course Project
    📝 Document Progress
      Setup Instructions
      Troubleshooting Notes
      Issues
      Plans
      Learning Reflections

Professional software developers use these same tools and workflows when joining new teams, learning unfamiliar systems, and building applications.

Why This Matters

The skills you develop during onboarding form the foundation for your future coursework.

If you learn how to work effectively in an unfamiliar technical environment, you will spend less time fighting your tools and more time solving meaningful problems.

More importantly, you will begin developing an engineering habit that will serve you throughout the year:

Encounter a problem → investigate → experiment → solve → document → reflect → improve.

This onboarding challenge is the beginning of that process.

Activation — You Already Know More Than You Think

You are a learner, a developer, and a teacher.

Every success, error, question, and breakthrough is something you can learn from — and something that may help someone else.

You are not starting from zero.

You have already spent years learning how to learn, solve problems, work with others, and respond when something does not make sense.

What You Already Know

You’ve Used Now You’ll Use It As a Developer
Rubrics Define what “good” looks like
Checklists Build repeatable processes
Assessments Test whether something works
Feedback Improve your work
Teamwork Collaborate on a real project
Creative Problem Solving Find solutions when there is no answer key

And you already know the basic progression of learning:

Remember → Understand → Apply → Analyze → Evaluate → Create

In software development, that might look like:

Know a command → understand what it does → use it → troubleshoot it → choose between solutions → build something new

That’s the transition from student to student developer.

Your Hidden Advantage

You’ve spent more than a decade being a student.

You’ve experienced:

  • Great instructions — and confusing ones
  • Helpful feedback — and feedback that wasn’t
  • Teams that worked — and teams that struggled
  • Assignments that engaged you — and assignments that didn’t

You already know what it feels like to be the learner.

Now you get to use that experience to become a better developer.

The PBL Mindset

Project-based learning changes the question.

Instead of:

“What does the teacher want me to do?”

Start asking:

“What do I need to figure out to move the project forward?”

You will:

Encounter → Investigate → Experiment → Solve → Document → Reflect → Improve

Your Mission

You are the beginner.

That is an advantage.

When something is confusing, capture the confusion.

When something breaks, document the solution.

When you discover a better way, share it.

When your team struggles, look for a better process.

Your struggles are not evidence that you are failing.

They are evidence that you are learning.

And what you learn can become the documentation, tools, and knowledge that help the next student succeed.

Demonstration — See the Tools and Workflow in Action

Follow along: Open your own VS Code workspace and GitHub repository as we work through this demonstration.

So far, we’ve focused on how you think and learn.

Now let’s see the development environment you will use.

The Foundation

You will use these tools repeatedly throughout the year:

Tool What It Does
VS Code Write and edit Markdown, JavaScript, and other project files
VS Code Marketplace Find and install extensions that improve your development environment
Make Automate repetitive development tasks
Git Track changes and build a history of your work
GitHub Store, share, and collaborate on your code
GitHub Actions Automatically build, test, and publish your projects
GitHub Pages Publish your web projects

Watch the Workflow

The important thing is not learning each tool in isolation.

Watch how they work together.

flowchart LR
    A[VS Code<br/>Create & Edit]
    B[Make<br/>Build & Test]
    C[Git<br/>Commit Changes]
    D[GitHub<br/>Push & Sync]
    E[GitHub Actions<br/>Automate]
    F[GitHub Pages<br/>Publish]

    A --> B --> C --> D --> E --> F

What You’ll See

During the demonstration, we will:

  1. Open VS Code and review the key extensions.
  2. Explore this notebook and the Markdown used to create it.
  3. Make a change to a file.
  4. Build or test the change using Make.
  5. Commit the change using Git through VS Code.
  6. Push the commit to GitHub.
  7. Watch GitHub Actions run automatically.
  8. Verify the published result on GitHub Pages.

From Tools to Software Development

These tools support the Software Development Lifecycle (SDLC).

As you progress, the simple onboarding loop will grow into a larger engineering workflow:

flowchart TD
    A[Plan<br/>Issues & Backlog]
    B[Develop<br/>Code & Build]
    C[Test<br/>Unit & System Tests]
    D[Version<br/>Commit & Push]
    E[Collaborate<br/>Review & Merge]
    F[Deploy<br/>Publish]
    G[Reflect<br/>Issues & Replan]

    A --> B --> C --> D --> E --> F --> G
    G --> A

Development Practices

The onboarding challenge is the entry point to a the set of development practices.

Practice Purpose
Tools & Equipment The development environment used to build, test, and deploy software.
GitHub Pages The framework for a web project — pages, layouts, Markdown, HTML, JavaScript, and how everything connects.
Agile Methodologies How teams organize work, make decisions, and select project teams. A key focus of Agile is to use short cycles and iterate often
Sprint Framework How work is organized into short, focused development cycles with checkpoints.

Onboarding Objectives - Ground 0

Check your starting position.

You have spent Weeks 0–1 setting up your development environment, working through guides, solving problems, and beginning to explore ideas according to your skill level.

Now, as you enter Weeks 2–3, make sure you are ready to move your mind from:

Onboarding → Project Development

Section Ready?
1. Understand the Challenge ☐
2. My Development Environment ☐
3. My GitHub Workflow ☐
4. Forming the Team ☐
5. Beginning the Project ☐

1. Understand the Challenge

  • I understand that the goal was not simply to install tools, but to learn how to work through an unfamiliar development environment.
  • I can identify at least one problem I encountered and explain how I solved or investigated it.
  • I have documented something that could help another student.
  • I have a story about how forming a team, positives and challenges.
  • I have a story about starting a team project, positives and challenges.
  • I can explain the Onboarding Objectives in my own words.

2. My Development Environment

  • I can open my development environment and begin working without waiting for someone else.
  • I can edit and preview the files I will use in my course.
  • I can use Git/GitHub to commit and push my work.
  • I know where to find the tool setup and troubleshooting guides.
  • I know how to ask for help when I am stuck.
  • I have a working strategy for my personal computer and development environment.

3. My GitHub Workflow

  • I can locate my GitHub repository.
  • I can create an issues in my GitHub repository location.
  • I can commit a change in GitHub.
  • I can create or edit a file in VSCode.
  • I can commint and sync changes from VSCode to GitHub.
  • I know about GitHub Actions and can determine if my site is working.
  • I know how to load my GitHub Pages portfolio site in my browser.

4. Forming the Team

Before Forming the Team

  • I have completed or reviewed the team formation process.
  • I have read an article on selecting effective development teams.
  • I have identified my persona, skills, interests, and strengths in OCS.
  • I understand the expectation for diversity of skills, interests, and perspectives when forming teams.
  • I have considered which teammates I may work well with.
  • I have sat in proximity to potential teammates.

Establishing the Team

  • I know my team members’ names.
  • We have discussed our skills, interests, and perspectives.
  • We have established a team communication channel.
  • I have shared my preferred contact method with my teammates.
  • We have established a team Agile manifesto and communication protocols.

Beginning to Operate as a Team

  • We have identified the coding challenges required for our course.
  • We have created team and individual GitHub repositories.
  • We have created team and individual GitHub issues, kanban, and milestones.
  • We have begun team decision-making processes such as stand-ups, pin-ups, and burndowns.
  • We have practiced Live Share, debugging, or pair programming.
  • We have established a process for discussing problems and resolving issues.
  • We have established our team contribution workflows: fork, branch, pull request, or direct collaboration as appropriate.
  • We have identified how we will accept feedback and take action between checkpoints.

5. Beginning the Project

  • I have participated in project ideation.
  • I can describe at least one problem or project idea our team is considering.
  • I have contributed an idea, question, research finding, or technical consideration.
  • I have created or contributed to a GitHub issue related to our work.
  • We have established our first project direction.
  • I understand what tasks I am expected to accomplish before the next sprint checkpoint.
  • We have identified what the team needs to accomplish before the next checkpoint.
  • I know that presenting evidence is part of my responsibility as I work.

Ground 0 Team Activities

Team Formation

Understand → Introduce → Explore → Form

Read, discuss, and use the team-formation process to create groups based on skills, interests, perspectives, and project needs, rather than friendship alone.

Team Initialization

Organize → Connect → Decide → Build

Establish the team’s communication, GitHub workflow, coding practices, decision-making processes, and initial project direction.

Team Practice

Communicate → Collaborate → Solve → Document

Begin practicing the behaviors expected throughout the sprint:

  • Daily checkpoints
  • Issue tracking
  • Pair programming
  • Live debugging
  • Peer support
  • Decision documentation
  • Evidence collection
  • Integration and Test policies
  • Preparing for Checkpoints and Demos

Technical & Learning Evaluation

This checklist looks beyond whether you completed a task.

Technical development includes using tools, building solutions, solving problems, learning from mistakes, and becoming more independent.

Your evaluation should show not only what you completed, but how your technical ability changed during the sprint.

Evaluation Matrix

Supply a GitHub Issue with your self-evaluation scores and one summary for each section.

Rank each area individually. Write one reflection for each section.

You do not need to write a separate response for every row.

Tools & Development Environment

ID Area Self Rank Peer Teacher
T01 Development Environment 0 — —
T02 VS Code 0 — —
T03 Git / GitHub 0 — —
T04 Portfolio / GitHub Pages 0 — —

Summary:
Describe how your ability to use your development environment changed during the sprint. Include a specific setup problem, tool, workflow, or technical process that you learned to manage.

Development & Creation

ID Area Self Rank Peer Teacher
T05 Tools & Equipment Hacks 0 — —
T06 Portfolio / Blogging Hacks 0 — —
T07 Theme / Style / Layout 0 — —
T08 JavaScript / Coding Challenges 0 — —
T09 AI Orchestration 0 — —

Summary:
Describe something you built, modified, customized, or extended during the sprint. Explain a tool, technique, coding challenge, design decision, or AI orchestration process that helped you create or improve your work.

Technical Awareness & Communication

ID Area Self Rank Peer Teacher
T10 Tech / Cyber Growth 0 — —
T11 Learning Through Mistakes 0 — —
T12 Tech / Cyber Talk 0 — —

Summary:
Describe how your technical understanding and communication developed during the sprint. Include a specific example of something you learned, a mistake that changed your understanding, or a technical idea you can now explain more clearly.

Ranking Guidelines

Rank each area based on the technical ability you demonstrated during the sprint.

0 means you have not entered a rank yet.

Start with 1 and select the level that best represents your demonstrated ability.

Rank Description
0 Not Entered — No self-assessment has been entered yet.
1 Explore — I have encountered or experimented with this technology or skill.
2 Understand — I can explain it and perform basic tasks with support.
3 Apply — I can use it independently in my project work.
4 Analyze / Evaluate — I can troubleshoot problems, compare approaches, and improve my solution.
5 Create / Extend — I can independently customize, extend, or create solutions using the skill.

Peer / Teacher Calibration: − = below self-assessment · = = consistent with self-assessment · + = above self-assessment

Before the Evaluation

  • I reviewed my Ground 0 Checklist.
  • I reviewed the technical evidence collected during the sprint.
  • I completed my self-ranking before receiving peer or teacher feedback.
  • I can support my rankings with examples from my work.
  • I identified at least one technical area where I want to improve.

Peer Perspective

With your team:

  • I reviewed technical work or evidence from a teammate.
  • I identified a technical strength a teammate demonstrated.
  • I identified a constructive opportunity for a teammate to improve.
  • My feedback is based on technical evidence or observed work rather than personal preference.

Teacher Perspective

The teacher will use working code, repositories, commits, issues, demonstrations, documentation, troubleshooting, and discussions to evaluate technical growth.

Compare the Perspectives

After the peer and teacher evaluations are complete:

  • I compared my self-ranking with my peer ranking.
  • I compared my self-ranking with my teacher ranking.
  • I identified an area where the perspectives agreed.
  • I identified an area where the perspectives differed.
  • I considered why the perspectives may have differed.
  • I identified one specific technical action for my next sprint.

Retrospective Question

What can I do now as a developer that I could not do at the beginning of this sprint?

Strongest Technical Evidence

The technical evidence I am most proud of:

TBD

The biggest technical problem I solved:

TBD

The technical skill I most need to improve:

TBD

My next technical learning goal:

TBD

Professional Evaluation

This checklist and its summaries look beyond technical tasks.

Professional development includes how you work, communicate, collaborate, respond to problems, and contribute to a team.

Your performance will be considered from three perspectives:

Self → Peer → Teacher

Evaluation Matrix

Supply a GitHub Issue with your self-evaluation scores and one summary for each section.

Rank each area individually. Write one reflection for each section.

You do not need to write a separate response for every row.

Core Behaviors

ID Area Self Rank Peer Teacher
P01 Attendance / Tardy 0 — —
P02 Work Habits 0 — —
P03 Integrity 0 — —

Summary:
Describe how you used your class time, responded to expectations, and demonstrated responsibility during the sprint. Include a specific example of a success, difficulty, or change you made.

Collaboration

ID Area Self Rank Peer Teacher
P04 Communication 0 — —
P05 Help Seeking 0 — —
P06 Mentoring / Advocacy 0 — —

Summary:
Describe how you communicated, sought help, helped others, and participated in your team. Include a specific interaction or example.

Professional Skills

ID Area Self Rank Peer Teacher
P07 Timeliness 0 — —
P08 Persistence 0 — —
P09 Organization 0 — —
P10 Engagement 0 — —

Summary:
Describe how you managed your time, persisted through difficulty, stayed organized, and remained engaged. Include a specific example of how you responded when the work became difficult or frustrating.

Ranking Guidelines

Rank each area based on the behavior you demonstrated during the sprint.

0 means you have not entered a rank yet.

Start with 1 and select the level that best represents your demonstrated behavior.

Rank Description
0 Not Entered — No self-assessment has been entered yet.
1 Beginning — I am beginning to recognize and practice this behavior.
2 Developing — I demonstrate this behavior sometimes, usually with reminders or support.
3 Consistent — I regularly demonstrate this behavior independently.
4 Strong — I consistently demonstrate this behavior and adjust when circumstances change.
5 Model — I consistently demonstrate this behavior and help others develop it.

Peer / Teacher Calibration: − = below self-assessment · = = consistent with self-assessment · + = above self-assessment

Before the Evaluation

  • I reviewed my Ground 0 Checklist.
  • I reviewed the evidence collected during the sprint.
  • I completed my self-ranking before receiving peer or teacher feedback.
  • I can support my rankings with examples from my sprint.
  • I identified at least one area where I want to improve.

Peer Perspective

With your team:

  • I provided useful feedback to a teammate.
  • I identified a strength that a teammate contributed to the project.
  • I identified a constructive opportunity for a teammate to improve.
  • My feedback is based on observed behavior or evidence rather than personal preference.

Teacher Perspective

The teacher will use project evidence, observations, discussions, documentation, and team interactions to evaluate growth.

Compare the Perspectives

After the peer and teacher evaluations are complete:

  • I compared my self-ranking with my peer ranking.
  • I compared my self-ranking with my teacher ranking.
  • I identified an area where the perspectives agreed.
  • I identified an area where the perspectives differed.
  • I considered why the perspectives may have differed.
  • I identified one specific action for my next sprint.

Retrospective Question

What did I learn about myself as a developer and teammate that I could not have learned from a grade alone?

Next Sprint Commitment

One professional behavior I will improve:

TBD

One technical skill I will improve:

TBD

One way I will contribute more effectively to my team:

TBD

Evidence I will collect during the next sprint:

TBD

Review – “Becoming proficient in Scrum Agile Workflow”

At the end of the sprint, teams consolidate their growth and show how they’ve applied technical, collaborative, and design skills.

flowchart TD
    subgraph SR ["Sprint Review Cycle"]
        A[Team Capability Review] --> B[Peer to Peer Presentation]
        B --> C[Receive Feedback]
        C --> D[Refinement & Iteration]
        D --> E[Teacher Close-Out]
        E --> F[Individual Mastery Review]
        F --> G[Set Goals for Next Sprint]
        G --> A
    end
    
    F --> H[Personal Growth]
HOMEWORK DELIVERY
STEP 1
STEP 2
✉ Export your solutions, then commit to submit...

Submit Failed — Enter Manually

Submit Assignment

Need to update a submission later? Open the submissions dashboard.

Lesson Chat — click to open

No messages yet.

Course Timeline