Megan T.
Valentine
*a and
Rae M.
Robertson-Anderson
*b
aDepartment of Mechanical Engineering, University of California, Santa Barbara, Santa Barbara, CA 93106, USA. E-mail: valentine@engineering.ucsb.edu
bDepartment of Physics and Biophysics, University of San Diego, San Diego, CA 92110, USA. E-mail: randerson@sandiego.edu
First published on 18th June 2025
The past decade has seen unprecedented growth in active matter and autonomous biomaterials research, yielding diverse classes of materials capable of flowing, contracting, bundling, de-mixing, and coalescing. These innovations promise revolutionary applications such as self-healing infrastructure, dynamic prosthetics, and self-sensing tissue implants. However, inconsistencies in metrics, definitions, and analysis algorithms across research groups, as well as the high-dimensionality of experimental data streams, has hindered the identification of performance intersections among such dynamic systems. Progress in this arena demands multi-disciplinary team approaches to discovery, with scaffolded training and cross-pollination of ideas, and requires new methods for learning and collaboration. To address this challenge, we have developed a hackathon platform to train future scientists and engineers in ‘big data’, interdisciplinary collaboration, and community coding; and to design and beta-test high-throughput (HTP) biomaterials analysis software and workflows. We enforce a flat hierarchy, pairing participants ranging from high school students to faculty with varied experiences and skills to collectively contribute to data acquisition and processing, ideation, coding, testing and dissemination. With clearly-defined goals and deliverables, participants achieve success through a series of tutorials, small group coding sessions, facilitated breakouts, and large group report-outs and discussions. These modules facilitate efficient iterative algorithm development and optimization; strengthen community and collaboration skills; and establish teams, benchmarks, and community standards for continued productive work. Our hackathons provide a powerful model for the soft matter community to educate and train students and collaborators in cutting edge data-driven analysis, which is critical for future innovation in complex materials research.
The properties of soft active materials themselves offer unique challenges and opportunities due to their out-of-equilibrium responses and structural and dynamical heterogeneity.4–10 Structural arrangements on molecular to mesoscopic scales occur over a wide range of timescales, arising from intrinsic biomolecular kinetics or responses to external signals, generating incredibly complex patterns and functions that enable, e.g., crawling, morphogenesis, and phase separation. The primary datasets used to characterize such materials are typically microscopy videos that are each tens of GBs in size. The vast number of components and possible interactions in these systems makes it essentially impossible for a single team to fully explore the accessible parameter space, which would also require dozens of TBs of data. Yet, collaboration is challenging because the size and complexity of data limits the ability to easily share original files between groups, and makes processing images in a manageable time frame difficult, often leading to important information being ignored or discarded. Moreover, there is little consensus in metrics, definitions, and analysis algorithms across research groups, further hindering the identification of performance intersections among materials.
To address these needs, we designed a multi-year hackathon platform to enhance skills and professional development within our collaborative team (Fig. 1), while generating accessible tools to enable: (1) sharing and analyzing large, expansive, and disparate datasets; and (2) establishing a common language and metrics for describing soft active materials. We focused on active cytoskeletal composites (ACCs), which are in vitro networks of actin filaments and microtubules, two principal biopolymers comprising the cell cytoskeleton, that are acted on by their respective molecular motor proteins, myosin and kinesin, to undergo contraction, flow and restructuring.4,5,7,9,10 We aimed to uncover intersections between different data sets and methods by arming trainees with approaches to efficiently screen, process and categorize big data. We chose to implement hackathons as scalable, low-risk training platforms to teach researchers how to analyze complex and heterogeneous data to enable decision making while providing them with experience and skills in team coding, user interfaces, and best practices for algorithm development. By having all participants work together to create a single collaborative end product, we aimed to instill a strong sense of belonging and accountability, while providing a shared understanding among our collaboration of how our research fit into the larger MGI community and goals. Our hackathon framework, consisting of tutorials, small group coding sessions, breakouts, and large group discussions, not only advanced software development, but strengthened collaboration skills and team interactions as well as trainee interest and skills in active soft matter research. Below, we describe our approaches, results and lessons learned to enable broader use of hackathon platforms to promote both training and innovation in complex materials science.
A defining feature of hackathons is that participants are provided with an opportunity to work collectively and in a new environment on tasks that they are passionate about, free from usual constraints and interruptions.12 Hackathons aim to equally engage participants of all backgrounds and expertise levels by establishing an open, respectful, and fun environment in which all participants are expected to contribute.21,25 This structure encourages diverse experts to interact outside of their specific domain(s) and allows them to develop solutions and uncover pitfalls with minimal risk.12 Engaging the whole group minimizes the risk of certain participants not contributing and promotes transparency in work allocation and deliverables.26,27 Hackathons are also an excellent training tool, allowing rapid education in areas of emerging knowledge and urgent need.17,21 The classical classroom is completely reframed as an interactive, team-driven social event, with self-directed learning, broad sharing of knowledge, and collaboration at all stages of work.28,29 Teachers become facilitators who can adapt the learning environment to meet student needs on demand. In this role, educators often ask questions and innovate methods outside of their own core training, which is critical to advancing solutions in rapidly developing fields.11,21,30
Hackathons also expose students to design reasoning paradigms and allow them to identify and solve problems in a human-centered context.29,31 While concepts of team building, problem identification, brainstorming, ideation, prototyping, and production are commonly taught in engineering disciplines, such skills are often underdeveloped in physics and materials-centered curricula. The flexible and adaptive nature of hackathons enables iterative refinement as the understanding of both the problem and solution coevolve.31 Such approaches have been reported to provide value throughout project lifetime, enabling the development of skills and pipelines in early stages that are later leveraged to create community-centered tools and methods that are eventually deployed to solve pressing problems.16 The hackathon approach has some similarity to the course-based undergraduate research experience (CURE), in which the traditional classroom is transformed into a collaborative hands-on experience where students work together towards a common discovery goal.32–34 However, in contrast to hackathons, CUREs generally do not provide an immersive multi-day experience, and they tend to engage a narrower set of participants, whereas hackathons enable participants from a broad range of career stages and/or disciplines to collaborate.
To maximize the benefits of hackathons, it is important to identify and address common challenges. Hackathons are resource intensive in terms of physical infrastructure, hardware and software access, and the need for highly engaged facilitators, so site selection and planning are essential.23,26 The short project horizons and focus on solutions can limit design choices and hinder deep thinking about the problem.29,31 Moreover, the flat hierarchy and open access model boosts creativity, but may lead to gaps in required subject matter expertise, and the time-limited team interactions may leave some questions unanswered by the end of the event.11,16,21,31 We demonstrate that through intentional planning, including pre- and post-event activities, these risks can be mitigated, making hackathons an extremely useful tool for active materials research training and innovation.
Our initial attempts at coordination involved having researchers from each group try to measure a specific metric at their own campus, for example the speed of contraction in an actively remodeling ACC, which they would then report and compare. Although trainees were encouraged to collaborate and share codes, the outcomes were inconsistent and difficult to interpret. Different trainees and labs used different approaches ranging from particle-image velocimetry (PIV), to differential dynamic microscopy (DDM), to particle-tracking, all of which require a number of subjective choices and inputs with no unifying guidelines.4,35,36 Upon further investigation, we found gaps in the foundational understanding of the underlying algorithms and assumptions, which made it difficult for teams to understand what methods were best suited for what types of analyses and why. Moreover, even within our relatively small collaboration, we lacked a common language to discuss our approaches to analysis and material performance. For example, terms like ‘error’, ‘noise’ and ‘uncertainty’ have many meanings when applied to large and complex microscopy videos. Our team consisted of physicists, engineers, statisticians, and biologists all of whom had different ideas, tolerances, and approaches for quantifying and handling such effects.
We faced similar challenges in describing the material performance. In general, the quantification of mechanical properties from video-based data is challenging, relying on models and assumptions that our typical active systems violated. Seemingly simple tasks, such as determining if a material was sufficiently ‘active’ and ‘resilient’ to be prioritized for follow-up analyses, were challenging. While we generally agreed that ‘active’ materials displayed athermal directed motion, we lacked workflows and criteria for deciding if and when a material exhibited and maintained activity, or robust definitions of what made one formulation more active than another. In defining ‘resilience’, we struggled to reconcile the concepts of temporal resilience of long-lived percolated networks with elastic resilience of energy absorbing structures. It was clear from these initial attempts that we needed clearer definitions, unifying workflows, and common analysis platforms to enable material design, optimization and analysis across our team. To address these needs and kickstart our collaborative work on unifying our approaches to complex material analysis, we launched a multi-year effort resulting in a robust hackathon platform to enhance training and collaboration within our team.
As is typical for hackathons, copious amounts of coffee, snacks, and food were available throughout the meeting, and the importance of communal and accessible sustenance is reflected in participant responses to the post-survey question about what their favorite aspect of the hackathon was. Most meals were provided on site to foster collaboration and community-building.25 In years 1–2, we provided meals at set times and chose outdoor venues a short walk from the meeting room to provide a new environment as well as fresh air and exercise. In year 3, we aimed to provide more flexibility, and had food delivered to our headquarters at meal times so participants could take a break and eat when it worked best for them. We still encouraged taking meal breaks, eating outside, taking walks, etc., but there were not set times that everyone was forced to adhere to. In all years, the final dinner was off-campus and was a celebration of everyone's hard work. Specific schedules for each hackathon are summarized in Fig. 2.
We took a scaffolded approach to the hackathon design, interweaving technical tutorial-style talks to lay the foundation and situate everyone on a level playing field, breakout groups on related topics, and small group coding challenges that first leveraged existing code and then focused on writing new code to analyze data (Fig. 2). To provide trainees with a broader and more encompassing understanding of DDM and its uses and applications, we invited several faculty, postdocs and graduate students from outside of the collaboration, who were DDM experts, to present tutorials, serve as breakout group leads and participate in coding challenges. Each session was scheduled for 45–90 min depending on the topic and goal, and the presentations and hands-on challenges started with the basics and built up to open-ended questions.
For the ‘hacking’ sessions, during which participants collectively wrote and tested software, we split the trainees into groups of 3–4 and tasked each with a design challenge to address a specific problem, which we had cooperatively identified in the large group discussions on the first morning. We designed groups to ensure a variety of coding expertise and skills in each, such that everyone could meaningfully contribute: from data curation and processing, to coding, to beta-testing and documenting. Each session had 2–3 assigned faculty leads who floated between the different groups to provide guidance, gauge progress and problems, and engage in discussions. This facilitated group design promoted open discussion and ensured that teams were working together productively and with respect. After each discussion or hacking session we organized a report-out, where each participant or group was asked to provide a short update of their learning or results, and facilitators asked follow-up questions, noted synergies and connected groups to additional resources as needed. At the end of the hackathon, we set goals for integrating the methods learned into our research workflows, but did not define ongoing project-based work at this stage.
Roughly one month before the hackathon, we provided participants with a curated set of 10 videos that were representative of the types of material systems we were investigating, and exhibited a variety of dynamical and structural characteristics. We established the coding goal of developing screening algorithms to enable various formulations to be rapidly assessed and optimized according to four performance metrics: contraction, stiffness, resilience, and long-range stress propagation. We challenged each participant to identify parameters and approaches to assess and quantify the given performance metrics in a way that limits subjectivity and streamlines screening. Specifically, we asked them to choose any 4 of the 10 videos to analyze and then answer a series of questions, via an online form, including describing the video, suggesting ways to screen those videos worthy of further analysis, characterizing the data using one or more of the performance metrics, and deciding what results to save. We asked each participant to prepare 3 slides describing their approach and results, and submit them before the hackathon.
On the first morning of the hackathon we presented an overview of the goals of our collaborative research and the immediate aims of the hackathon to orient the participants to our shared goals, including our emphasis on open sharing and collaboration. We then had a series of short presentations during which all participants presented the results of their pre-hackathon work. Based on these kick-off presentations, and the skillsets and interests of the participants, we formed three groups of 3–4 participants to tackle the three most promising of the originally-identified performance metrics (eliminating long-range stress transmission).
The remaining schedule was more flexible than in year 1, with no predetermined tutorials or topical discussions. We instead aimed to foster collaboration, creativity and productivity by allowing coding tasks and goals to emerge more organically, initially guided by the participant presentations, then through interspersed large group discussions and report-outs and faculty facilitators floating between small groups. We scheduled 8 ‘hacks’ that were each ∼90 min and separated by ∼15–30 min breaks and report-outs. We also added an evening session to the first day to make better use of the short time frame and acknowledge that different people are more or less productive at different times of day (Fig. 2). Some groups worked very collaboratively during the hacks while others preferred more independent work, splitting up tasks and reconvening at regular intervals to discuss progress. The format and space accommodated both approaches. If we identified a need for a short tutorial, the facilitators formed a subgroup, led by faculty or more experienced participants, and the group worked through the details at white boards until the issue was resolved. There were times when participants hit a roadblock that they couldn’t overcome in the allotted time, in which case the faculty facilitators worked to find other ways for them to contribute, e.g., beta-testing, literature review, note-taking, data curation.
At the conclusion of the hackathon, the three groups presented their results and their planned next steps, which included validating their codes and making them more user friendly. We collectively established a series of benchmarks to achieve in the following weeks, including integrating the three nascent software packages into a single framework and improving their throughput, requiring collaboration among the different groups. Over the next year, slow but steady progress was made through a series of virtual meetings and continued collaboration. Software codes originally written in a variety of languages (Python, MATLAB, C++) were converted to Python, which the group agreed would be the most accessible to the community. We also submitted an abstract for two participants to present a poster about the code at the APS March Meeting the following spring, providing a fixed date deliverable that spurred progress.39 The presentation also provided valuable feedback from the community.
To facilitate meaningful engagement of participants with varied backgrounds, we identified four participants to act as facilitators and help lead the pre-hackathon work. We focused on packaging the existing codes into a single executable with reasonable and understandable inputs and outputs and an interface that users of all coding levels could execute. We curated a large (∼200 GB) shared dataset, with sufficient diversity and complexity of structures and dynamics, for all participants to work on to ensure consistency and enable comparison. We instructed each participant to download the Python software packages to their individual laptops prior to the hackathon, and on the first day provided them with a thumb drive that contained the curated dataset.
Based on survey feedback from the previous years, we built more structure into the schedule than we had in year 2, with more defined short-term goals, but continued to focus on hands-on hacking rather than formal presentations (Fig. 2). We added a working dinner on the day that participants arrived, to allow everyone to get to know each other, and to provide an overview of the hackathon goals and how they relate to our collaboration goals. We confirmed that everyone had downloaded the data and codes they needed, and then the two trainees who led the development of the unified software package presented a basic tutorial of how to operate the code. This evening introduction session allowed us to start right away the next morning with a hands-on training session, where all participants attempted to run the analysis code on a common small test set of videos, with close guidance from the developers. This exercise was extremely helpful not only to ensure everyone was sufficiently trained to use and develop the software, but it also revealed a number of issues that cropped up only on certain Python distributions and/or operating systems, which the developers were able to immediately address in real-time. We then had the trainee who led data curation describe the rich dataset that all the participants would be working on, explain the material system and common types of observable behavior, and suggest some exemplary videos to use for initial testing. The rest of the meeting was a series of 90-min hacking sessions and 30-min report-outs and group discussions (Fig. 2). Rather than defining goals for each hack, we empowered participants to define their own schedules and benchmarks based on our end goal of producing user-ready HTP software that we could use amongst our collaboration and share with others in the field.
The software we were testing comprised three complementary branches that leveraged distinct image analysis algorithms, so we divided trainees into three groups to beta-test, validate, debug, and enhance each branch. Each team had a mix of coding expertise from novices to those who helped develop the code. Over the course of the two days, what began with a software that screened for three parameters using binary yes/no outputs, evolved into software that reported more than ten continuous parameters that were output in a table and a graphical display. In the several months following the hackathon, a subset of participants worked to refine and optimize the code, BARCODE: Biomaterial Activity Readouts to Categorize, Optimize, Design and Engineer, which is now publicly available to all those interested in HTP screening and characterization of dynamically restructuring soft materials.40–42
![]() | ||
Fig. 3 Summary of program evaluation data. Number of respondents was 12, 13, and 12 in years 1, 2, and 3, respectively. |
A key feature of our hackathons is the shared goal of all participants, who collaborate rather than compete, ensuring everyone has a vested interest and can meaningfully contribute. Participants reported that they enjoyed these aspects of the work, including learning how others solved the problems, getting feedback on their work, and orienting their efforts to align with the common goals (Table 1).
I liked the goal setting…as well as reporting in about my progress and hearing about what other people had worked on. I also enjoyed learning about how people from other groups were approaching problems. | I really enjoyed the collaborative aspect of the workshop. It was great to talk to the other researchers and hear about their work. It was also interesting hearing what problems people were facing and the resulting group discussions to help figure out that problem. |
Group discussions and post-lecture discussions were great. Enjoyed hearing many different perspectives on understanding the same systems. I think every individual's expertise was taken advantage of in a very productive way and it remained an interesting and engaging experience for everyone. | I enjoyed meeting other members of the group and improving collegiality. I appreciated the opportunity to readily exchange information and ideas in person. I felt this interaction allowed me to progress much faster than I otherwise would have in understanding the different research projects in the collaboration, and how I can contribute. |
I really just liked all the feedback, and all our open discussions. I feel like that is where I learned the most when we were brainstorming, and thinking through why things would work and why other methods would not. | The collaborative nature…kept it engaging, and enabled me to make greater progress than I feel like I would have accomplished when working on my own, or even in a smaller group. |
The codes improved a lot. I made use of most of time efficiently without [it] feeling boring. | Learning and improvement of computational skills |
Having time to brainstorm new approaches | Learning from others regarding how they analyze the problem. |
We considered the skill diversity within our group of participants to be a strength – providing avenues for out-of-the-box thinking and solutions that a group of experts may not have considered. In order to ensure that all participants could meaningfully contribute, we aimed to select problems with enough complexity and dimensionality that multiple solutions of varying degrees of technical difficulty were possible.23 An advantage of our hackathons was that nearly all participants had been members of our collaboration for some time. Thus, everyone had a shared knowledge of the active material system, the general structural and dynamic properties the networks displayed, as well as the overall goals of the research, providing an important common grounding among the group.
Prior to the hackathon, we provided participants with a structured schedule; however, we were intentionally flexible in our execution to allow new topics or needs to be introduced and addressed, and to quickly make adjustments as needed to foster productivity. The faculty facilitators, who were actively engaged with the participants throughout the event, played a key role. We defined expectations and goals at the kickoff session of the meeting that served as a guide for decision making during the hackathon, and we worked together to identify cases where flexibility or adaptation were required. Changes were often driven by participants, and decided collaboratively in our large group report-outs. They typically took the form of continuing projects from the previous hack because certain participants and/or groups were still highly focused and making progress. We did not want to slow their momentum and force them to switch focus to start on the originally planned new problem. When a change was needed, we provided rationale and advanced notice so participants could plan accordingly and continue to focus on the most important immediate goals.25 By year 3, we introduced a lot of flexibility into the schedule, including flexible break and meal times so that participants could choose their own time to switch tasks or take a break. While this change worked well for some, allowing them to retain focus and momentum at critical points, others reported finding it hard to take a break if not mandated or if they saw others working.
Overall, the ‘living’ nature of the event is a hallmark of hackathons: the rapidly changing format provides motivation and excitement, and accelerates problem solving.26 It also, however, challenges facilitators, who need to be able to communicate, pivot, and adapt with little advanced planning and often based on ideas or needs that emerge organically from the participants. We also learned the importance of careful balance between structured and open-ended work. Participants enjoyed the extended time to work on problems, but preferred having clear goals for each session. Given the different skill levels, some participants needed help identifying very specific tasks, while others enjoyed the freedom to come up with solutions that address broader goals, as reflected in participant feedback on program design (Table 2).
I really liked the fact that we had so much time to just try to implement and code it up. |
We have a clear goal to work on and to finish coding sessions. |
I thought the focus was suitably narrow to allow ideation and pursuit of an attainable objective. |
Working on a sub part of the screening was nice since that let us dig deep into the code |
I appreciated the ability to test the code on diverse use cases to test code design and screening heuristics. |
Forming groups of 2–4 and giving plenty of time to work with share-outs every ∼2 hours seemed to really work well! |
The diversity of experiences was helpful in getting an understanding of the goals of the group. |
I appreciate you gave me introduction papers to read before…to comprehend more about the lectures. |
The multi-year collaborative nature of our research certainly helped in sustaining our efforts, as we had a dedicated group of PIs committed to working together on research questions in active matter, and we met regularly as a group to advance this work. Despite relatively high trainee turnover from year to year, we found a surprising level of continuity in skills and understanding. We attribute this to the outreach of former participants who upon return to their home campuses became ambassadors of the project, transferring their knowledge within our larger collaboration, thereby helping to build institutional knowledge and maintain momentum, even among team members who did not participate in a given hackathon. To onboard new participants each year, we took care in designing the pre-hackathon work to set expectations and orient all participants to the problems we aimed to tackle, and provided tutorials and resources explaining the approaches that could be used to solve them. This approach allowed newcomers to rapidly get up to speed, while bringing fresh perspectives and enthusiasm that enriched the learning environment and outcomes.
The most intensive post-hackathon work occurred after year 3, led by participants who had developed enough expertise to lead the effort to finalize the software package and disseminate the results. It is common for post-hackathon work to be more successful when the product is more developed and there is clear consensus that the added effort will lead to successful project completion, including the eventual deployment of the software or technology.46 This can lead to a tradeoff between hackathons focused on individual skill development, and those focused on producing a working prototype.47 We found our multi-year, tiered approach, rooted in our collaborative research, provided the right balance of learning and production while allowing our team to meet our growing research goals.
Footnote |
† Electronic supplementary information (ESI) available. See DOI: https://doi.org/10.1039/d5sm00401b |
This journal is © The Royal Society of Chemistry 2025 |