Teaching
ECE1724
Advanced Web Development: React Ecosystem and Modern Frameworks
Winter 2025 · Winter 2026 · Fall 2026
ECE1724 is a graduate-level course in modern full-stack web development for students with prior programming experience but not necessarily previous study of web development. Students work with JavaScript, TypeScript, Node.js, Express.js, SQLite, PostgreSQL, Prisma ORM, React, Tailwind CSS, shadcn/ui, and Next.js.
The course moves progressively from individual application layers toward integrated full-stack development. Connected assignments provide structured practice with the concepts and technologies introduced in class, followed by an open-ended team project in which students make their own architectural, scope, and implementation decisions.
As the course has evolved, I have looked for more ways to move beyond whether an application simply works and give students opportunities to take greater ownership of their systems: making technical decisions, considering alternatives where relevant, verifying results, collaborating effectively, and explaining their work clearly.
Course Design Principles
These principles shape both the technical curriculum and the way I design assignments, projects, assessment, and learning support.
Build Understanding Progressively
Students move from individual application layers and core concepts toward increasingly integrated full-stack development, so that frameworks are introduced in the context of problems they are designed to solve.
Provide Structure While Leaving Room for Judgment
Assignments provide clear requirements and sustained practice, while open-ended project work gives students room to make their own decisions about architecture, scope, implementation, and trade-offs.
Look Beyond Working Output
A system that appears to work is not sufficient evidence of understanding. Project requirements ask students to explain important decisions, consider alternatives where relevant, verify behavior, and take responsibility for the work they submit.
Treat Collaboration and Communication as Engineering Skills
Teamwork, technical explanation, presentation, and discussion are treated as part of software engineering practice rather than as separate professional skills added after implementation.
How the Course Has Evolved
I revise the course after each offering based on student work, student feedback, patterns I observe during the term, and my own reflection on whether the course design is producing the kinds of learning I intended.
Winter 2025
Building the Foundation
The first challenge was designing a practical graduate course for students who could have substantial programming experience but very different levels of prior exposure to modern web development. I wanted the course to be accessible without reducing it to a sequence of tutorials, and structured enough to support a large class while still requiring meaningful technical decision-making.
What I was trying to address
Students could enter the course with strong general programming backgrounds but little experience building complete web applications.
How I designed for it
I organized the curriculum as a progressive sequence from JavaScript and backend fundamentals through databases, React, Next.js, and full-stack integration, without assuming previous study of web development.
What I was trying to address
Learning many new technologies at once can make it difficult for students to understand how individual application layers relate to one another.
How I designed for it
The course introduced technologies incrementally, allowing students to work first with individual layers before bringing them together through more integrated frameworks and applications.
What I was trying to address
A large class required clear and consistent expectations without making every task mechanically prescriptive.
How I designed for it
I developed detailed assignment specifications and automated tests for core requirements, while leaving students responsible for implementation decisions and practical problem-solving.
What I was trying to address
Independent assignments provide useful practice, but they do not fully capture the architectural and collaborative decisions involved in building a larger application.
How I designed for it
I added an open-ended team project with shared technical requirements but freedom to choose the application domain, architecture details, features, and division of work.
This established a pattern that continues to shape the course: structured practice first, followed by increasingly open-ended work in which students take greater ownership of technical decisions.
Winter 2026
Making Key Practices More Sustained
The first offering showed me that some important practices were present in the course but introduced too late or too briefly to become part of students' normal development process. For the second offering, I focused on giving students more sustained practice with static typing, technical communication, and responsible use of generative AI.
What I learned
TypeScript was introduced late in the first offering, giving students limited time to become comfortable using static typing in realistic applications.
How I responded
I moved TypeScript from Lecture 8 to Lecture 3, required it beginning with Assignment 2, and made it mandatory for the team project.
What I learned
Encountering TypeScript only once did not give students enough repetition to develop confidence with typed interfaces, data models, API contracts, and component props.
How I responded
Students used TypeScript across backend, data, frontend, and project work so that static typing became part of their regular development workflow rather than an isolated topic.
What I learned
Building a technically successful application did not necessarily give students enough practice communicating their work — explaining the problem they were addressing, the architecture they designed, the engineering decisions they made, and the results they achieved.
How I responded
I added project presentations and structured peer review so that teams had to explain and justify their work to an audience. I also strengthened support for technical communication by collaborating with Prof. Fiona Coll, lead of ISTEP's Graduate Communication Initiative, to provide targeted guidance for project presentations.
What I learned
Generative AI had become part of real software-development workflows, making it increasingly unrealistic to design the course as though students would not encounter or use it.
How I responded
I introduced the course's first explicit generative AI policy, establishing expectations around acceptable use, attribution, individual understanding, and responsibility for submitted work.
These changes shifted several important skills from one-time exposure toward repeated practice. They also raised a broader question that became central to the next redesign: not simply whether students should use AI or communicate their work, but how the course itself should shape those practices.
Fall 2026
Creating More Opportunities for Judgment and Ownership
For the third offering, I focused more on the learning environment surrounding the existing curriculum. The central question became how to create more opportunities for students to take intellectual and professional ownership of their work: reasoning before using AI, making and explaining technical decisions, verifying results, collaborating effectively, and communicating technical work clearly.
What I learned
An AI policy focused mainly on permitted use and attribution could define boundaries, but it did not necessarily encourage students to preserve their own reasoning or critically evaluate AI-generated work.
How I responded
I redesigned the AI guidance around learning workflows: students begin with independent reasoning, use AI selectively, evaluate its suggestions, make their own decisions, and verify resulting work. Within the permitted uses for an assessment, students are evaluated on their work and reasoning, not on how much or how little AI they use.
What I learned
A polished demonstration or working application does not necessarily show whether students understand the system well enough to reason about technical decisions, limitations, trade-offs, or unexpected questions.
How I responded
I revised project requirements and marking rubrics to emphasize technical reasoning, evidence, evaluation, verification, and explanation. I also added a Q&A period to project presentations, giving teams an additional incentive to understand their work beyond a prepared demo while allowing the rest of the class to observe how others explain decisions and respond to technical questions in real time.
What I learned
Open-ended projects can unintentionally reward feature accumulation, even when additional scope contributes little to the underlying learning goals.
How I responded
I refined the project guidance and rubrics to emphasize coherent scope and well-justified decisions rather than treating a larger number of features or greater technical complexity as inherently better.
What I learned
Effective teamwork depends not only on everyone contributing, but also on ownership and technical decision-making being shared across the team rather than concentrated in a single person.
How I responded
I made expectations around shared ownership more explicit and introduced a confidential mid-project team health check. Git development history continues to provide additional context when individual contribution or understanding needs closer review.
What I learned
Support offered outside the normal flow of the course was not always easy for students to access, even when the content itself was useful.
How I responded
I integrated more communication support into the course itself through detailed presentation guidance on the course website, concise discussion of communication principles during class, and clearer expectations for presentation structure and Q&A.
What I learned
The usefulness of a course discussion space depends not only on its technical capabilities, but also on whether students find it familiar and convenient enough to use regularly.
How I responded
After students expressed a preference for Piazza over GitHub Discussions, I moved course discussion to Piazza within Quercus for Fall 2026. I am treating the change as an opportunity to see whether a more familiar, lower-friction platform supports broader participation and peer-to-peer help.
The redesign reflects a broader shift in how I think about the course. My goal is not only to help students build increasingly sophisticated web applications, but also to create repeated opportunities for them to begin practicing the judgment that comes with owning technical work: deciding, explaining, evaluating, verifying, and collaborating rather than simply producing output.