Twenty-Three Pull Requests and a Medal
Building our university Computer Science Society's website as a team taught me to agree before building, and to design for where students already look.
- Published
- Read time
- 5 min read

The KNUST Computer Science Society ran a challenge called CUBE: build the society's website. My team entered, built it over a few weeks, and finished first runner-up. The medal was nice. What we learned building it together has been more useful.
Agree on one look before anyone codes
Four people building pages on their own will build four different websites. Before we split the work, we wrote down the society's colours, one bright blue, two greys and white, and where each one belongs. Every page was checked against that note, so the finished site reads as one website, not a collection of pages.
Build for where students already look
The most useful page was barely code. Students do not find study material on official websites. They find it in a Telegram bot full of past questions, in WhatsApp groups that share free Udemy coupons, and in a few YouTube channels everyone recommends. So the resources page points to exactly those places, grouped into six plain categories.
Twenty-three pull requests
Each of us worked on our own copy of the code and sent changes back to one shared version as pull requests. Twenty-three were merged by the end. Small and often worked far better than one big merge at the end: nobody overwrote anyone else's page, and every problem showed up while it was still small.
- Write the look down before splitting the work
- Point people to what they already use instead of rebuilding it
- Merge small and often, so problems stay small
- Check every page on the phones students actually carry
A team ships one website, not four.
We did not win. First runner-up still meant a medal, a live site the society could use, and a way of working with other developers that I still rely on.
