Overview
Last updated
Last updated
Table of Contents
At the Marcy Lab School, training software engineers is just one of our ambitions. Our hope is that you become innovators and leaders.
Civic Tech Hackathon (CTH) is a three-week-long culmination of our Leadership & Development and Software Engineering curricula, resulting in more than just another technical project. CTH is an opportunity for you and your peers to come together to solve real-world problems facing your communities.
The final day of Civic Tech Hackathon will be Demo Day, where you will present your solution to an audience of friends, families, staff, mentors, volunteers, employers, funders, and members of the Marcy Lab School community at large!
The Civic Tech Hackathon comes at the end of the third quarter of the Software Engineering Fellowship. In the Leadership & Development curriculum, you will have explored your personal and racial identities to better understand yourselves as individuals, community members, and technologists. You will have also spent time investigating how systems of power like racism, sexism, and classism can shape your own lives and the lives of your families and communities.
Simultaneously, by the close of Quarter 3, you will have built a strong foundation in JavaScript, problem-solving, and interface design. You will also have just finished the two most technically challenging technical units of the year: React and Backend. Throughout, you will have built projects to help you reinforce your learnings. The projects built during CTH will be your first full-stack projects!
CTH also represents a milestone moment for how you work. You began the year by working on your projects individually, before moving on to paired projects. During CTH, you will work in groups of 3 or 4, which will push you to higher levels of collaboration, communication, and project management than ever before.
During Civic Tech Hackathon, you will:
Draw from the content and skills developed in the Leadership & Development Curriculum to generate ideas you will build out in code
Utilize all the technical units of the curriculum
Test leadership skills developed in individual and group coaching
Practice teamwork, communication, and Agile project management
For you, we hope that the Civic Tech Hackathon will leave you feeling challenged, gratified, capable, and inspired.
Like college students studying for their final exams, your dedication to your project, combined with your discpline and work ethic, may result in some all nighters and long weekends as you strive to create the best product possible. We hope this leaves you feeling challenged and gratified.
Like members on a hackathon team, your planning, collaboration, and communication skills will be tested as you navigate a tight timeline with requirements to meet. We hope this leaves you feeling capable.
Like founders of a startup with dreams to change the world, your creativity and storytelling will be put the test as you build a product that meets a real need in your community. We hope this leaves you feeling inspired.
Throughout the Software Engineering Fellowship, you have developed these skills and mindsets. Now it is time to put them to the test. To succeed during CTH, we believe you must demonstrate:
Collaboration: tap into your strengths and recognize the strengths of others to work effectively towards a common goal.
Compromise: sacrifice your own ambitions to ensure that deadlines are met.
Self-Efficacy: confidently take initiative to adapt and innovate to meet goals.
Professionalism: demonstrate strong work habits to act in the interests of the school and the greater Marcy community.
Communication: convey information, ideas, facts, and perspectives clearly and effectively in your speaking and writing
Below you can see a sample schedule for a typical week during Civic Tech Hackathon. As you can see, there is quite a lot of time for project work time!
Here are some key details to note:
Sprints will kick off on Thursdays
End-of-sprint demos and retrospectives on Wednesdays
Two code challenges per week
Daily mindful morning and stand up
Daily stand down
Two manager meetings per week
(Scrum Masters only) Scrum Master workshops
Lots of work time!
Below, you can learn more about each event.
These whole-group meetings will ensure you remain grounded and connected to your classmates! Share your wins, challenges, and the things you learn as you embark on this journey!
During each week-long sprint, you will have multiple touch points with your support staff whose aim is to ensure that you and your team are moving in the right direction and at the right pace.
Should our team expect to work on Fridays, Saturdays, and Sundays? YES!
This is it! This is your final exam and your most important portfolio project to date. The time and effort you put into these three weeks may have a greater impact on your future career than any other three weeks in your entire life!
Collaborate with your team to find times over the weekends to communicate and get work done! By working on weekends you can get up to 6 days of extra work done over the course of these three weeks of CTH! That is almost an entire week of extra time, so take advantage of it!
When building a fullstack project on a team over the course of multiple weeks, it is essential that everyone is aligned on what to prioritize.
Rather than aiming to build the entire application in one go, we've broken down CTH into 4 distinct sprints, each with their own objectives and priorities:
0 - Planning
• Get final approval on the proposal. • Complete the Product Spec Sheet, ERD, and Mockups • Set up your GitHub organization, repository, and Scrumboard
1 - First Feature
• Database, Model, and Controllers work together to Read and Create a primary resource (post, event, etc...) • Adapters are built for key endpoints, frontend page routing is established, and key components are built (forms, buttons, content lists) • Integration testing of frontend and backend is complete.
2 - MVP Complete
• Fullstack functionality on two user-created resources. • Full CRUD on at least one user-created resource • Styling and page layout is beginning to take shape
3 - Polish + Present!
• Ironing out bugs for a full demo • Styling is polished and consistent • Presentations are practiced and ready to present • Project is Deployed
These are the high-level priorities of each sprint but it will be up to each group to determine how to divide the work to meet these objectives.
Here are some tips:
Divide your group into frontend and server/database. You can always switch after a sprint to gain exposure to the full stack.
Decide early what data will be transferred between the frontend and server. Then, work quickly to build adapters and endpoints to establish that connection.
In the first sprint, focus on substance, not style. This applies most to the frontend. Build your pages and routing first. Then the forms and data containers. Finally, hook them up to your adapters to just get them working.
In addition to the fullstack web application that you build, you will need to complete these deliverables. Each of these deliverables will help ensure that every group completes their project on time and meets our standards of excellence.
A well designed Entity Relationship Diagram (ERD) can quickly communicate the data that is most important to your application. It will serve your team as a source-of-truth for any questions about the data needed to work with a particular type of resource.
Here are the requirements for an ERD:
Every entity/table has a clear and descriptive table name.
Clearly shows the relationship between entities (One-to-Many, One-to-One, etc.) and relationships must be in the right direction.
Join tables are shown when Many-to-Many relationships are needed.
Every table list all critical attribute/column names.
Primary Keys and Foreign Keys must be labeled and clearly distinguished from other attributes/columns.
Every attribute/column has a data type.
Diagram must be neatly structured with as few overlapping or intersecting lines as possible.
ERD reflects the same project and all features outlined in the project proposal.
The wireframe should clearly show the various frontend views of your application and how users can navigate between them. Like the endpoint, it will serve your team as a source-of-truth for the design, layout, and expected functionality of your frontend application.
Here are the requirements for a wireframe:
Wireframes must show a landing page, one or two pages for log-in and sign-up, plus an additional page for every other front-end client route in the application.
Wirefremes must have a navigation feature: either a menu, header, or sidebar.
Every page must be labeled with its client-side path (/profile, /, /newsfeed, /user/:id, etc.).
The only text that is visible is text which denotes action or hierarchy (headings and button labels, but body text is not needed)
Entire wireframe is neatly structured and visually accessible with no overlapping pages.
Mockup reflects the same project and all features outlined in the project proposal.
A Product Specifications Sheet communicates the user stories for an application and the technical details required to implement them, such as:
The page and URL path for a feature
Essential frontend components (forms, buttons, links, etc...),
What follows a user interaction (submitting a form, clicking a button, etc...)
Backend endpoints used to create, read, update, or delete data.
If filled out thoroughly, a product spec sheet can quickly be translated into tickets for a scrum board.
Here are the requirements for a product spec sheet:
The What, Why, and Who sections clearly and concisely describe the application and audience.
"Must-Haves" product requirements are essential to meeting the needs of the intended audience
"Nice-to-Haves" can reasonably be excluded from the application while still meeting the needs of the intended audience
Technical requirements are decomposed for every "Must-Haves" product requirement.
Technical requirements include:
The name of the page that the feature is included on and the URL path for the page
A description of any essential frontend components that the user will interact with (forms, buttons, links, containers for data, etc...)
An explanation of what happens when a user interacts with a form / button / link
An explanation of any interactions with the backend including endpoints to fetch from and if authentication or authorization is required."
The ERD and Mockup are linked at the bottom
The repository is the most important artifact for your technical audience. The code inside will demonstrate your technical prowess.
The README is the first impression of your application that your technical audience will experience so make sure that your README is clean, professional, and provides clear instructions for working with your application.
Here are the requirements for your GitHub Repository:
The README is complete with mission statement, team members, usage, and technologies used
The README includes links to the proposal and scrum board.
The repository has a scrum board linked under Projects. The scrum board has descriptive tickets, assignees, and clear organization.
The deployment link is added to the About section.
And finally, the presentation and project demo will serve as your elevator pitch! You will only have a few minutes to show off your work during Demo Day so make the most out of it!
Observe the professionalism and polish of the slides here! Each member has their moment to shine and share their contributions to the project. The demo video walks the user through the essential user-stories in a natural manner.
Example:
Example:
Head over to the to see more details about the requirements for your project and other minor deliverables.
