Supervised On-Site Development Work — Phase 1 (Weeks 1–5)

What Phase 1 Is and Why It Matters

The first five weeks of your externship placement are the most important transition of your training. You move from a classroom setting where mistakes are learning opportunities into a professional environment where your work affects real products, real clients, and real teammates. Phase 1 is supervised closely for a reason: your mentor is there to catch errors before they cause problems and to model how experienced developers actually work day to day.

Your goal during Phase 1 is not to impress anyone with heroics. Your goal is to be reliable, communicative, and teachable. Employers consistently report that attitude and consistency matter more than raw technical skill at the entry level. Show up prepared, ask clear questions, complete what you commit to, and document everything.

Working Inside a Professional Development Workflow

Most software teams organize work in short cycles called sprints — typically one or two weeks long. At the start of a sprint, tasks (called tickets) are assigned from a backlog in a project-management tool such as Jira, Trello, or Asana. Each ticket describes what needs to be done, who owns it, and what "done" looks like (the acceptance criteria).

Read every ticket carefully before you write a single line of code. If the requirements are unclear, ask your mentor during the daily stand-up — the brief morning meeting where each team member answers three questions: What did I do yesterday? What will I do today? Is anything blocking me? Keep your stand-up answers short and specific. "I finished the contact-form validation and will start the API integration today" is better than "I'm still working on stuff."

You are expected to complete at least two assigned tasks per week. For each task, log the ticket number or title, the date and hours spent, the technologies you used (e.g., HTML, CSS, Python, Git), and the outcome — did you finish it, hand it off, or leave it in progress? This log is your professional record and is reviewed at the Phase 1 check-in.

Version Control Is Not Optional

Every piece of code you write at placement must move through the employer's version-control system — typically Git, with repositories hosted on GitHub or GitLab. Follow the team's branching convention exactly. Common conventions include naming branches after the ticket number (`feature/PROJ-42-add-login-form`) or using a `git flow` model with `main`, `develop`, and `feature` branches.

Write clear, present-tense commit messages: `Add client-side validation to contact form` rather than `stuff` or `changes`. Commit small, logical units of work rather than large batches. If you are unsure whether your branch is ready to merge, ask your mentor — never push directly to `main` or `production` unless explicitly told to do so.

Receiving and Acting on Code Review

At least once per week your mentor or a team member will review your code and give written or verbal feedback. Code review is not personal criticism. It is the standard quality-control process used on every professional team. Read each comment carefully, understand the reasoning before you make changes, and then revise the deliverable.

In your work log, document what feedback you received, what you changed, and — crucially — why you made that change. This shows that you understood the feedback rather than just mechanically editing lines. Patterns in the feedback you receive (e.g., consistent notes about variable naming or missing error handling) tell you exactly what to study next.

Attending Meetings and Taking Structured Notes

Attend at least one team or client meeting every two weeks. Before the meeting, review the agenda if one is shared. During the meeting, take notes using a simple structure:

• Decisions made — what was agreed upon
• Action items — who will do what by when
• Open questions — items that still need a decision

By the end of the week, share a brief written summary of those notes with your program coordinator. This is not a transcript; it is a concise professional summary of one to three paragraphs. Practicing this skill builds habits that matter throughout a developer's career.

Confidentiality and Digital Safety

Everything you see at your placement — client data, source code, internal tools, business processes, and employee information — is confidential. Do not share code, screenshots, or business details on personal social media, public repositories, or any platform not authorized by the employer. Ask your mentor before using any third-party tool or browser extension on an employer-issued workstation, because unapproved software can create security vulnerabilities.

Use only the credentials issued to you. Do not share passwords, and lock your workstation whenever you step away — this is a basic workplace security practice equivalent to locking a door. If you notice a security concern (an open SSH port, an unencrypted file with credentials, suspicious network activity), report it to your supervisor immediately rather than attempting to investigate or fix it yourself.

What the Phase 1 Check-In Requires

At the end of Week 5, your program coordinator will review your complete work log at the Phase 1 check-in meeting. Every shift must have an entry. Blank days without a recorded reason will flag a concern. Your mentor will also complete a mid-placement rubric scored on two sub-scales — technical skill and professionalism — and you must score 70 or above on those combined sub-scales to continue to Phase 2. If your score is close to the threshold, the coordinator and mentor will work with you on a focused improvement plan before Phase 2 begins.